我们已经在托管公司的VM上运行服务器，并且刚刚注册了专用主机（AMD Opteron 3250、4核，8GB RAM，2 x 1TB的软件RAID，ext3）。

在运行性能测试时，我们注意到某些SQLite转换（插入，删除和/或更新的组合）所花的时间比我的2010 MacBook Pro长10倍至15倍。

经过大量的搜索和阅读之后，我们来看一下安装选项：

    data=ordered,barrier=1

我们做了一些实验，并获得了最佳性能

    data=writeback,barrier=0

我已经阅读了这些内容，并了解了它们在做什么的基础知识，但是对于这样的跑步对我们来说是否是一个好主意，我没有一个很好的感觉。

问题

对于托管服务，上述配置是否明智？

如果发生断电或硬崩溃，那么最终可能会导致数据丢失或文件损坏。如果我们每15分钟对数据库快照一次，这可能会减轻这种情况，但是在拍摄快照时可能不会同步数据库。我们应如何（能够？）确保此类快照的完整性？

我们还应该考虑其他选择吗？

谢谢

初步建议
如果您无法承受任何数据丢失的损失（我的意思是一旦用户输入了新数据，如果在接下来的几秒钟内不会丢失这些数据）并且由于您没有UPS之类的东西，那么我将不会消除写入障碍，我也不会切换回写回。

删除写屏障
如果删除写屏障，则在崩溃或断电的情况下，文件系统将需要执行fsck来修复磁盘结构（请注意，即使启用barrier，大多数日记文件系统甚至仍会执行fsck尽管该日志的重放本来就足够了）。删除写屏障时，建议尽可能删除所有磁盘缓存（在硬件上），这有助于最大程度地降低风险。但是，您应该基准化此类更改的影响。您可以尝试使用此命令（如果您的硬件支持）hdparm -W0 /dev/<your HDD>。
请注意，ext3对元数据更改使用2个障碍，而当使用mount选项时，ext4仅使用1个障碍journal_async_commit。

尽管Ted T'so解释了为什么在ext3的早期发生了一些数据损坏（默认情况下，在内核3.1之前，屏障是默认关闭的），但是日志的放置方式除非发生日志日志换行（日志是循环日志）数据以安全顺序写入磁盘-首先记录日志，其次是数据-即使硬盘支持对写入进行重新排序。
基本上，不幸的是日志日志换行时会发生系统崩溃或断电。但是，您需要保留data=ordered。尝试data=ordered,barrier=0另外进行基准测试。

如果您有能力丢失几秒钟的数据，则可以激活这两个选项data=writeback,barrier=0，然后尝试使用该commit=<nrsec>参数。在此处检查手册以获取此参数。基本上，您要花几秒钟的时间，这是ext3文件系统将同步其数据和元数据的时间。
您也可以尝试使用一些关于脏页（需要写入磁盘的内核可调参数）的内核可调参数进行基准测试，这里有一篇很好的文章介绍了有关这些可调参数的所有内容以及如何使用它们。

有关障碍的摘要
您应该对可调参数的更多组合进行基准测试：

1. 使用data=writeback,barrier=0会同hdparm -W0 /dev/<your HDD>
2. 采用 data=ordered,barrier=0
3. 使用data=writeback,barrier=0结合其他安装选项commit=<nrsec>，并尝试nrsec不同的值
4. 使用选项3.，然后在内核级别尝试对脏页进行进一步的可调。
5. 使用安全的data=ordered,barrier=1，但尝试其他可调参数：尤其是文件系统升降器（CFQ，Deadline或Noop）及其各自的可调参数。

考虑转移到ext4并对其进行基准测试
如上所述，对于ext4来说，其写入所需的障碍要少于ext3。此外，ext4支持扩展区，该扩展区可能会为大型文件带来更好的性能。因此，它是一个解决方案值得探讨，特别是因为它很容易从一个ext3到ext4迁移而无需重新安装：正式文件 ; 我是在一个系统上执行此操作的，但是使用的是Debian指南。从内核2.6.32开始，Ext4确实很稳定，因此可以安全地用于生产中。

最后的考虑
这个答案远未完成，但是它为您提供了足够的材料来开始调查。这在很大程度上取决于需求（在用户或系统级别），因此很难直接给出答案，对此感到遗憾。

注意：下面可能有一些错误。我一直在学习很多这样的东西，所以要加点盐。这很长，但是您可以阅读我们正在使用的参数，然后跳到最后的结论。

您可以在许多层上担心SQLite的写入性能：

我们查看了以粗体突出显示的内容。具体参数是

• 磁盘写缓存。现代磁盘具有RAM缓存，该缓存用于优化相对于旋转磁盘的磁盘写入。启用此功能后，数据可以按无序块进行写入，因此如果发生崩溃，最终可能会得到部分写入的文件。使用hdparm -W / dev / ...检查设置，然后使用hdparm -W1 / dev / ...进行设置（将其打开，并使用-W0将其关闭）。
• 障碍=（0 | 1）。在线上有很多评论说“如果barrier = 0，那么就没有启用磁盘写缓存”。您可以在http://lwn.net/Articles/283161/找到有关障碍的讨论。
• 数据=（期刊|有序|写回）。请查看http://www.linuxtopia.org/HowToGuides/ext3JournalingFilesystem.html，以获取这些选项的说明。
• commit = N。告诉ext3每N秒同步所有数据和元数据（默认为5）。
• SQLite编译指示同步= ON | 关 启用时，SQLite将确保在继续之前将事务“写入磁盘”。禁用此设置实质上会使其他设置变得无关紧要。
• SQLite编译指示cache_size。控制SQLite将用于其内存中缓存的内存量。我尝试了两种大小：一种使整个数据库适合高速缓存，另一种使高速缓存占最大数据库大小的一半。

在ext3文档中阅读有关ext3选项的更多信息。

我对这些参数的许多组合进行了性能测试。该ID是一个方案编号，如下所述。

我从在方案1上使用默认配置在计算机上开始运行。方案2是我认为最“安全”的方案，然后在适当/有提示时尝试了各种组合。使用我最终使用的地图，这可能最容易理解：

我编写了一个测试脚本，该脚本运行了许多事务，包括插入，更新和删除，所有事务都在仅具有INTEGER，仅具有TEXT（带有id列）或混合的表上进行。我在上面的每个配置上都运行了多次：

最下面的两个场景是＃6和＃17，它们具有“ pragma sync = off”，因此不足为奇，它们是最快的。接下来的三个簇是＃7，＃11和＃19。这三个在上面的“配置图”上以蓝色突出显示。基本上，配置是打开磁盘写缓存，barrier = 0，并且数据设置为“ journal”以外的其他值。在5秒（＃7）和60秒（＃11）之间更改提交似乎没有什么区别。在这些测试中，data = ordered和data = writeback之间似乎没有多少区别，这让我感到惊讶。

在混合版本测试中峰。在此测试中，有一堆场景显然更慢。这些都是data = journal的。否则，其他情况之间就没有太大关系了。

我进行了另一个时序测试，该测试对不同类型的组合进行了插入，更新和删除的更异构混合。这些花费了更长的时间，这就是为什么我没有在上面的情节中包括它：

在这里，您可以看到回写配置（＃19）比订购的配置（＃7和＃11）慢一些。我希望回写会稍微快一点，但是可能取决于您的写模式，或者也许我对ext3的阅读还不够：-)

各种场景在某种程度上代表了我们的应用程序完成的操作。在选择方案的清单之后，我们使用一些自动化测试套件进行了时序测试。它们与上面的结果一致。

结论

• 该承诺的参数似乎没有多大的区别，所以我们要离开，在5秒。
• 我们将启用磁盘写缓存，barrier = 0和data = ordered。我在网上阅读了一些东西，认为这是一个错误的设置，而另一些东西似乎认为，在许多情况下，这应该是默认设置。我想最重要的是，您要做出明智的决定，知道要进行哪些权衡。
• 我们不会在SQLite中使用同步编译指示。
• 如我们期望的那样，设置SQLite cache_size杂注以使数据库适合某些操作，从而提高内存性能。
• 上面的配置意味着我们要承担更多的风险。我们将使用SQLite备份API来最大程度地减少部分写入时发生磁盘故障的危险：每N分钟拍摄一次快照，并保留最后一个M。我在运行性能测试时测试了此API，这使我们充满信心。
• 如果我们仍然想要更多，我们可以考虑使用内核，但是我们没有去那里就改进了很多。

感谢@Huygens提供的各种提示和指示。