同步写入非常慢。Ubuntu 10.10，32位，ext4

我在Macbook Pro上运行ActiveMQ，该Macbook Pro运行带有ext4分区的32位Ubuntu 10.10。

Linux iker-laptop 2.6.35-23-generic-pae #40-Ubuntu SMP Wed Nov 17 22:32:51 UTC 2010 i686 GNU/Linux

如果我在ActiveMQ中启用持久性，则性能将急剧下降。我已经在其他机器上测试了相同的东西，并且相差2个数量级。

有一个带有activeMQ的工具可以测试HD，结果如下：

iker@iker-laptop:~/apps/apache-activemq-5.4.1$ java -classpath lib/kahadb-5.4.1.jar org.apache.kahadb.util.DiskBenchmark 

Benchmarking: /home/iker/apps/apache-activemq-5.4.1/disk-benchmark.dat
Writes: 
  146171 writes of size 4096 written in 11.074 seconds.
  13199.477 writes/second.
  51.560455 megs/second.

Sync Writes: 
  197 writes of size 4096 written in 10.006 seconds.
  19.688187 writes/second.
  0.07690698 megs/second.

Reads: 
  5589861 reads of size 4096 read in 10.001 seconds.
  558930.2 writes/second.
  2183.321 megs/second.

同步写入的性能为s ** t。必须配置有些错误，但这是我注意到高清性能问题的唯一应用程序。

hdparm抛出期望值：

iker@iker-laptop:~$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   6282 MB in  2.00 seconds = 3141.73 MB/sec
 Timing buffered disk reads:  240 MB in  3.00 seconds =  79.88 MB/sec

同步IO的主要限制因素不是硬盘驱动器的吞吐量，而是从发出写入到将其提交到磁盘所花费的时间。在这方面，与硬盘驱动器最相关的性能指标将是硬盘驱动器的搜寻时间，而不是理想情况下的吞吐量。

如果您可以将基准测试（应用程序）与标准版（应用程序）兼容，那么除了对您不利的硬件之外，内核也是如此，我想您可能会看到一个小的改进（尽管可能与进行异步IO无关）在实时IO调度类下运行。默认情况下，将在“尽力而为”类下安排应用程序，这可能还会增加您的写入等待时间。使用实时调度类需要您自担风险，因为它在访问磁盘时会对其他应用程序的性能产生不利影响。

总的来说，我并不认为您看到的同步写入性能有什么可怕的错误。通常，与异步IO相比，同步IO的性能将更差。

附带说明一下，ActiveMQ和同步IO的快速搜索结果如下：

出于性能原因，即使您正在使用持久性消息，您也可能希望尽快将消息流式传输到代理

cfq I / O调度程序在这些类型的测试中往往表现得很差。除了前面提到的ionice建议之外，您可能还想尝试切换到截止日期I / O调度程序（通过使用root 引导elevator=deadline或通过for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; doneroot身份进行操作）。

同步写入必须先返回确认已提交的确认（无论提交是成功还是错误），然后才能返回自身。这是设计使然，并且由于旋转的金属磁盘具有较高的延迟时间，因此固有地使同步写入慢得多（在磁盘ram高速缓存上不计算在内）。

异步写入通常会写入RAM，而操作系统会在以后将其提交到磁盘（后来通常只有几秒钟或更短的时间（我相信ZFS是5x /秒，或每5秒））。磁盘查找时间以毫秒为单位，而RAM查找时间以ns为单位。相差1000倍。

如果在继续操作之前将数据永久存储绝对至关重要，并且可能会发生断电的1秒延迟是绝对不可接受的，请使用同步写入。

在所有其他时间使用异步写入。

您看到此性能下降的最可能原因是因为您在日志文件系统中使用了“ -o sync”，并且启用了隔离栅（这是ext4的默认设置）。

在这里，决定如何进行改进变得非常困难。

它主要归结为您对硬件的信任程度。

来自mount（8）：“写入屏障强制对日志提交进行正确的磁盘顺序，使易失性磁盘写入缓存可以安全使用，但会降低性能。ext3文件系统默认情况下不启用写入屏障。请确保启用屏障，除非您的磁盘以某种方式由电池供电。否则，在断电的情况下，文件系统会遭受损坏。”

因此，要么接受“ -o sync”性能差的事实，要么为控制器和真正好的SAS磁盘购买电池支持的高速缓存，然后使用“ -o sync，nobarrier”关闭障碍。

如果您当前使用的是适当的企业级FC或iSCSI存储后端，那么我想您也可以安全地使用后者。

总而言之，ActiveMQ 5.4默认情况下使用KahaDB存储后端，并且该后端也有其自己的事务日志，因此即使在文件系统级别上关闭日志记录也可能对您有用，但是绝对可以确定您使用“ enableJournalDiskSyncs”后端选项，如果您还没有的话，可能还希望将其放在单独的块设备上。

（有关更多信息，请参见http://activemq.apache.org/kahadb.html）

同步写入速度很慢，这就是我们缓冲所有内容的原因。在Wikipedia上查看IOPS，您将看到典型的7,200 rpm硬盘具有75-100 IOPS。现在，看看Macbook Pro的技术规格，它具有5400 rpm的HDD。最好的性能是75％，因此您希望笔记本电脑的IOPS最好为50-75。

MQ可能会编写一个数据分类帐和一个会计分类帐，这将使您达到ActiveMQ基准测试中看到的20 IOPS。

您有两个选择，在tmpfs上进行测试（即内存文件系统），或使用SSD。通常，使用同步写入的服务器将具有可容纳15,000 rpm磁盘的重要SAS / SCSI RAID阵列。将额外的磁盘添加到阵列以提高性能，而不是增加容量。

在还使用ext4运行64位Ubuntu 11.10服务器的托管VM（在VirtualBox中）上，我们获得了以下结果：

Sync Writes:
 288 writes of size 4096 written in 10.034 seconds.
 28.702412 writes/second.
 0.112118796 megs/second.

在使用ext3运行Redhat 5.7 64位的物理服务器上，获得以下结果：

Sync Writes:
  54987 writes of size 4096 written in 10.001 seconds.
  5498.1504 writes/second.
  21.47715 megs/second.

我想知道OP是否也在VM中运行此程序，或者ext3和ext4之间是否存在问题。我理解托管环境和非托管环境之间可能会有差异，但是并没想到会有如此大的差异。

使用更大的块大小。您是否可能将同步/异步IO与直接/缓冲IO混淆了？