У меня есть достойный выделенный хост CentOS 6.5 (CentOS 6.5 / E3-1230 3.2Ghz Quad Core + HT / 16GB / Software Raid 1 SATA II /WD2503ABYX/ ext4) с ядром CentOS по умолчанию и "elevator = deadline" в grub.
Операции записи ввода-вывода вызывают резкий скачок загрузки ЦП. Читает нормально. Например,
dd if=/dev/zero of=test bs=1048576 count=2048
приводит к тому, что загрузка ЦП хоста становится выше 3 или 4. При нормальной работе оно остается ниже 0,40, но при более интенсивных операциях ввода-вывода все останавливается.
mpstat 1 во время этих dd тесты показывает ио подожди на 20-25%.
Вот схема диска:
Disk /dev/sda: 251.1 GB, 251059544064 bytes
255 heads, 63 sectors/track, 30522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c6673
Device Boot Start End Blocks Id System
/dev/sda1 * 1 26 204800 fd Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2 26 548 4194304 fd Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sda3 548 30523 240775168 fd Linux raid autodetect
Disk /dev/sdb: 251.1 GB, 251059544064 bytes
255 heads, 63 sectors/track, 30522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00095c99
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 26 204800 fd Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2 26 548 4194304 fd Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sdb3 548 30523 240775168 fd Linux raid autodetect
Disk /dev/md2: 246.6 GB, 246552588288 bytes
2 heads, 4 sectors/track, 60193503 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/md1: 4293 MB, 4293910528 bytes
2 heads, 4 sectors/track, 1048318 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg_main-LogVol00: 246.5 GB, 246549577728 bytes
255 heads, 63 sectors/track, 29974 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/md0: 209 MB, 209702912 bytes
2 heads, 4 sectors/track, 51197 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Проблема (высокая загрузка ЦП) начала происходить где-то в конце декабря прошлого года, что заставляет меня думать, что это связано с программным обеспечением (подсистема диска была проверена людьми в DC).
Какие тесты мне следует провести дальше, чтобы попытаться выявить проблему?
PS: Я не ищу советов по увеличению производительности. Сервер недостаточно загружен. Я просто хочу уменьшить нагрузку на ЦП во время записи на диск.
ОБНОВЛЕНИЕ: вопрос переработан, чтобы лучше описать проблему.
ОБНОВЛЕНИЕ: НАЙДЕНО РЕШЕНИЕ Я наконец обнаружил, в чем проблема, когда наткнулся на эта почта.
root> modprobe vhost_net
root> echo vhost_net > /etc/modules
По какой-то причине интерфейсы virtio раньше не загружали драйвер. Теперь все хорошо.
В CentOS dirty_ratio установлен на 20%.
Это означает, что при записи файла
dd if=/dev/zero of=test bs=1048576 count=2048
Фактически записывает данные в память как обратную запись (до 3,2 ГБ) и выполняет не фактически записать это на диск.
Это медленнее (но не реалистичный тест производительности) на виртуальной машине, потому что вы, вероятно, назначили гораздо меньшее выделение памяти самой виртуальной машине (скажем, 2G), и это приводит к dirty_writeback обеспечивает только ~ 400 МБ обратной записи до того, как содержимое будет принудительно записано на диск.
Если вы запустите эту команду, запустите sync, вы заметите, что для возврата к синхронизации требуется много времени.
Вместо этого вам нужно запустить свою команду, выполнив следующие действия, чтобы получить лучшее представление о фактической пропускной способности.
dd if=/dev/zero of=test oflag=sync bs=1048576 count=2048