Синхронизирующие очень медленные записи. Ubuntu 10.10, 32 бита, ext4

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

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

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

Как примечание стороны быстрый Google activemq и синхронного io дал следующее:

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

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

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

Асинхронные записи обычно пишутся в RAM и соглашения ОС с передачей его к диску позже (позже обычно являющийся простыми секундами или меньше (я полагаю, что ZFS является 5x/second, или каждые 5 секунд)). Времена поиска на диске измеряются в мс, в то время как RAM ищет, времена измеряются в нс. Вот в чем разница 1000x.

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

Используйте асинхронные записи во все другие времена.

Синхронные записи являются медленными, почему мы буферизуем все. Смотрите на IOPS на Википедию, и Вы будете видеть, что типичный жесткий диск на 7 200 об/мин имеет 75-100 IOPS. Теперь смотрите на технические спецификации MacBook Pro, и он имеет жесткий диск на 5 400 об/мин. Это - 75%-я производительность в лучшем случае, таким образом, Вы смотрите на 50-75 IOPS в лучшем случае для ноутбука.

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

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

На размещенном VM (в VirtualBox) рабочий сервер Ubuntu 11.10 64 бита также с помощью 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 бита, использующие ext3 следующие результаты:

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

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

Наиболее вероятная причина, по которой вы видите такое снижение производительности, заключается в том, что вы используете «-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 , чтобы узнать больше)

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