Синхронизация пишет очень медленно. Ubuntu 10.10, 32 бита, ext4

Я использую ActiveMQ на моем Macbook Pro с Ubuntu 10.10, 32 бита с разделом ext4.

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.

Производительность для Sync Writes s ** t. Там должно быть что-то неправильно настроено, но это единственное приложение, где я заметил проблему с производительностью HD.

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

Основным ограничивающим фактором для синхронного ввода-вывода является не пропускная способность вашего жесткого диска, а время, которое требуется с момента записи и его фиксации на диск. В этом отношении наиболее подходящим показателем производительности для жесткого диска будет время поиска жесткого диска, а не его пропускная способность в идеальных условиях.

В дополнение к аппаратному обеспечению, работающему против вас, так же, как и ядро, я полагаю, вы могли бы увидеть небольшое улучшение (хотя, вероятно, далеко не то, что вы получите от выполнения асинхронного ввода-вывода), если вы можете использовать тест (приложение) для работать под классом планирования ввода-вывода в реальном времени. По умолчанию приложения будут запланированы в классе максимальных усилий, что, вероятно, также увеличит время ожидания ваших записей. Используйте класс планирования в реальном времени на свой страх и риск, так как он будет иметь негативное влияние на производительность других приложений при доступе к диску.

В общем, я не думаю, что есть что-то ужасно неправильное в производительности синхронной записи, которую вы видите. Синхронный ввод-вывод обычно работает ужасно по сравнению с асинхронным вводом-выводом.

В качестве дополнительного примечания быстрый Google ActiveMQ и синхронный IO дал следующее :

Из соображений производительности вы можете захотеть передавать сообщения брокеру как можно быстрее, даже если вы используете постоянные сообщения

Планировщик ввода / вывода cfq имеет тенденцию работать ужасно в подобных тестах. В дополнение к предложению ionice ранее, вы можете попробовать переключиться на планировщик ввода-вывода крайнего срока (либо загрузкой, elevator=deadlineлибо выполнением for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; doneс правами root).

Синхронная запись должна получить подтверждение того, что запись была зафиксирована (была ли фиксация успешной или ошибочной), прежде чем она сможет вернуть себя. Это сделано специально и по своей сути делает синхронную запись намного медленнее из-за большого времени ожидания, связанного с вращающимся металлическим диском (кэш-память на диске не учитывается).

Асинхронные записи обычно записываются в ОЗУ, и ОС занимается их последующей записью на диск (позже, обычно это всего лишь секунды или меньше (я считаю, что ZFS составляет 5x / секунду или каждые 5 секунд)). Время поиска диска измеряется в мс, а время поиска ОЗУ - нс. Это разница в 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 )

Синхронная запись идет медленно, поэтому мы все буферизируем. Взгляните на IOPS в Википедии, и вы увидите, что типичный жесткий диск на 7200 об / мин имеет 75-100 IOPS. Теперь взглянем на технические характеристики Macbook Pro , и он имеет жесткий диск на 5400 об / мин. Это 75% производительности в лучшем случае, поэтому вы смотрите на 50-75 IOPS в лучшем случае для ноутбука.

MQ, возможно, записывает регистр данных и бухгалтерский регистр, который приводит вас к 20 IOPS, которые вы видите в тесте ActiveMQ.

У вас есть два варианта: протестировать tmpfs , то есть файловую систему в памяти, или использовать SSD. Обычно серверы, использующие синхронную запись, имеют значительный массив SAS / SCSI RAID с 15 000 об / мин дисков. Дополнительные диски добавляются в массив для повышения производительности, а не для увеличения емкости.

На размещенной виртуальной машине (в VirtualBox) с 64-битным сервером Ubuntu 11.10, также использующим ext4, мы получили следующие результаты:

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

На физическом сервере под управлением Redhat 5.7 64 bit с использованием ext3 были получены следующие результаты:

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

Интересно, работал ли OP на виртуальной машине, или существует проблема между ext3 и ext4. Я ценю, что между размещенной и не размещенной средой может быть разница, однако я не ожидал такой большой разницы.

Используйте больший размер блока. Возможно, вы путаете синхронный / асинхронный ввод-вывод с прямым / буферизованным вводом-выводом?