у нас есть NFS поверх XFS и drbd, который обеспечивает ужасную производительность (около 1 МБ / с чтение / запись, как показано в iostat / iotop), свойства тома xfs следующие:
meta-data=/dev/drbd0 isize=256 agcount=4, agsize=52427198 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=209708791, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=16384, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
и у нас есть Dell Box с контроллером SAS1068E и 2 дисками WD 1 ТБ. В настоящее время том смонтирован со свойствами:
rw,noatime,nodiratime,attr2,nobarrier,logbufs=8,noquota
Файловая система содержит множество небольших файлов размером около 50-100k, они разбросаны по дереву каталогов.
Мы пробовали поиграть с ReadAhead Values (в настоящее время отключены) и параметрами монтирования xfs, но пока ничего не получилось.
Мы заметили в iotop, что kdmflush - это процесс, вызывающий iowait. Есть ли предложения по улучшению производительности этой установки?
Короткий ответ заключается в том, что ваша дисковая система совершенно не соответствует тому, что вы пытаетесь сделать.
Скорость 1 МБ / с довольно типична для производительности произвольного ввода-вывода на RAID1 на дисках SATA. EG, см. Калькулятор iops anr raid от wmarow. Вот. Помещение двух дисков Barracuda ES.2 SATA в RAID10 (фактически то же самое, что и RAID1), установка 100% записи с 0% попаданием в кэш записи дает расчетную пропускную способность 0,57 МБ / с. Реальная производительность может отличаться, но не будет сильно отличаться.
Тот факт, что вы идентифицируете kdmflush как ответственный процесс ядра, подтверждает это - если ваша дисковая система не может справиться с нагрузкой, это приведет к тому, что в iowait будет больше времени на этот процесс. kdmflush - это процесс очистки устройства-сопоставителя, который обрабатывает отложенную работу из-за загрузки в другом месте.
Есть несколько способов улучшить это - получить больше дисков, получить диски лучшего качества или включить кэширование записи на контроллере.
Если вы включите кэширование записи, вам также захочется получить BBU. Однако BBU может не подходить для встроенного SAS1068E, поэтому вам, возможно, придется приобрести контроллер PCI-e.
Я увидел ужасную производительность с DRBD, когда на контроллерах RAID, которые я использовал (я полагаю, 3ware 9550) не был включен кэш записи. Загрузка DRBD будет в основном случайным вводом-выводом, поэтому кэширование записи будет иметь значительное влияние на производительность.
SAS1068E - это очень низкий уровень, и он также может быть причиной проблемы. Если у вас есть больше дисков или диски лучшего качества, я бы посоветовал приобрести и лучший контроллер.
Быстрый поиск в Google показывает так же низкая производительность с той же моделью RAID-контроллера, который вы используете.
Используйте сеть более 10 Мбит / с для репликации DRBD. Ввод-вывод вашего диска на устройстве DRBD ограничен скоростью сети (если вы не используете протокол, отличный от C, что вы делаете, если вы хотеть ваши данные станут поврежденными и бесполезными). Чтобы проверить, что проблема связана с вашей сетью, отключите первичный от вторичного, и ваша скорость ввода-вывода, вероятно, резко возрастет.
1 МБ / с звучит знакомо. Предположительно, ваша проблема меньше в XFS и больше в слое DRBD. Если блочная репликация на DRBD по какой-то причине происходит медленно, вполне разумно, что kdmflush вызывает много IOWAIT. Эта скорость звучит так, будто сетевое соединение между двумя хостами DRBD не согласовывается должным образом.
Опять же, предположение, но эта скорость очень похожа на TCP-соединение без корректной работы TCP Windows. Это должно быть довольно очевидно при трассировке сети, так как трафик будет выглядеть как пакет, подтверждение, пакет, подтверждение, пакет, подтверждение, а не множество пакетов и одно подтверждение.
Если iotop запускается на клиенте, монтирующем общий ресурс NFS, а не на самом сервере NFS, обратите внимание на это соединение, а также на соединение DRBD.