在运行性能测试时,我们注意到一些sqlite转换(插入,删除和/或更新的组合)比我的2010 MacBook Pro花了10倍到15倍的时间.
经过大量的谷歌搜索和阅读后,我们看看了挂载选项,它们是：
data=ordered,barrier=1
我们做了一些实验,并获得了最好的表现
data=writeback,barrier=0
我已经阅读了这些内容,并了解了他们正在做的事情的基础知识,但我对我们这样运行是否一个好主意没有很好的理解/感觉？
问题
以上配置是否适合考虑托管服务？
如果我们停电或发生硬故障,那么我们最终可能会丢失数据或文件损坏.如果我们每15分钟拍摄一次数据库快照,则可能会缓解这种情况,但在拍摄快照时可能无法同步数据库.应该(可以吗？)我们如何确保这种快照的完整性？
我们应该考虑其他选择吗？
谢谢
如果你不能丢失任何数据(我的意思是一旦用户输入新数据,如果在未来的几秒内不能丢失),并且因为你没有类似UPS的东西,那么我不会删除写屏障,也不会我切换回写.
消除写障碍
如果你删除写屏障,那么在崩溃或掉电的情况下,文件系统将需要执行fsck来修复磁盘结构(请注意,即使屏障打开,大多数日记文件系统仍然会执行fsck,即使重播期刊应该已经足够了).删除写屏障时,建议尽可能删除任何磁盘缓存(在硬件上),这有助于将风险降至最低.您应该对这种变化的影响进行基准测试.您可以尝试此命令(如果您的硬件支持它)hdparm -W0 / dev /<您的HDD>.
请注意,ext3在元数据更改时使用2个障碍,而在使用mount选项journal_async_commit时,ext4仅使用一个障碍.
虽然Ted T’so explained为什么在ext3的早期发生了一些数据损坏(默认情况下屏障为until Kernel 3.1),但是日志的放置方式除非发生日志日志换行(日志是循环日志),否则数据会写入磁盘一个安全的订单 – 第一个日志,数据第二 – 即使硬盘支持重新排序写入.
基本上,当日志日志换行时发生系统崩溃或断电是不吉利的.但是,您需要保持data = ordered.尝试使用data = ordered,barrier = 0进行基准测试.
如果您能够承受丢失几秒钟的数据,您可以激活两个选项data = writeback,barrier = 0但是然后尝试使用commit =< nrsec>参数也是如此.检查此参数here的手册.基本上,您给出一个秒数,这是ext3文件系统同步其数据和元数据的时间段.
您可以尝试尝试使用一些关于脏页(需要写入磁盘的内核)的内核可调参数进行调整和基准测试,这里有一个good article解释了有关这些可调参数的所有内容以及如何使用它们.
有关障碍的摘要
您应该对可调参数的几个组合进行基准测试：
>使用data = writeback,barrier = 0与hdparm -W0 / dev /<你的硬盘>
>使用data = ordered,barrier = 0
>使用data = writeback,barrier = 0和其他挂载选项commit =< nrsec>并为nrsec尝试不同的值
>使用选项3.并在内核级别尝试进一步调整脏页面.
>使用safe data = ordered,barrier = 1,但尝试其他可调参数：尤其是filesystem elevator(CFQ,Deadline或Noop)及其respecitve可调参数.
考虑转向ext4并对其进行基准测试
因为所述ext4对于写入需要比ext3更小的屏障.此外,ext4支持扩展区,对于大型文件可能会带来更好的性能.所以这是一个值得探索的解决方案,特别是因为它很容易从ext3迁移到ext4而无需重新安装：official documentation;我在一个系统上做了这个,但使用了这个Debian guide. Ext4从内核2.6.32开始就非常稳定,因此在生产中使用是安全的.
最后的考虑这个答案远非完整,但它为您提供了足够的材料来开始调查.这很大程度上取决于需求(在用户或系统级别),很难有一个直截了当的答案,抱歉.
