У меня серьезные проблемы с сервером на базе xen, он находится в гостевом разделе. Это паравиртуализированная CentOS 5.5. Я не уверен, связано ли это с аппаратным или программным обеспечением или между ними (драйверы).
Основная информация
Обновлена прошивка контроллера (это было сделано на последнем этапе)
Smart Array 6i in Slot 0
Hardware Revision: Rev B
Firmware Version: 2.84
Обновленное ядро
Linux domU 2.6.18-194.32.1.el5xen #1 SMP Wed Jan 5 19:32:33 EST 2011 i686 i686 i386 GNU/Linux
Проблема в скорости записи на диск.
Базовая производительность
Следующие числа берутся сверху при копировании большого файла по сети.
Если я скопирую файл в другой раз, скорость уменьшится относительно средней загрузки. Так что во второй раз это вдвое меньше скорости в первый раз.
После этого ему нужно время, чтобы остыть. Средняя нагрузка медленно уменьшается, пока снова не станет пригодной для использования. ls / занимает около 30 секунд.
top - 13:26:44 up 13 days, 21:44, 2 users, load average: 7.03, 5.08, 3.15
Tasks: 134 total, 2 running, 132 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.1%sy, 0.0%ni, 25.3%id, 74.5%wa, 0.0%hi, 0.0%si, 0.1%st
Mem: 1048752k total, 1041460k used, 7292k free, 3116k buffers
Swap: 2129912k total, 40k used, 2129872k free, 904740k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1506 root 10 -5 0 0 0 S 0.3 0.0 0:03.94 cifsd
1 root 15 0 2172 644 556 S 0.0 0.1 0:00.08 init
При этом загрузка хоста составляет ~ 0,5 в среднем и стабильна во времени. ~ 50% ждать
Серверное оборудование - двойной xeon, 3 ГБ оперативной памяти, 170 ГБ scsi 320 10k об / мин, и не должно иметь никаких проблем с копированием файлов по сети.
disk = [ "tap:aio:/vm/domU.img,xvda,w" ]
Я тоже получаю это в журнале
INFO: task syslogd:1350 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syslogd D 00062E4F 2208 1350 1 1353 1312 (NOTLB)
c0ef0ed0 00000286 6e71a411 00062e4f c0ef0f18 00000009 c0f20000 6e738bfd
00062e4f 0001e7ec c0f2010c c181a724 c1abd200 00000000 ffffffff c0ef0ecc
c041a180 00000000 c0ef0ed8 c03d6a50 00000000 00000000 c03d6a00 00000000
Call Trace:
[<c041a180>] __wake_up+0x2a/0x3d
[<ee06a1ea>] log_wait_commit+0x80/0xc7 [jbd]
[<c043128b>] autoremove_wake_function+0x0/0x2d
[<ee065661>] journal_stop+0x195/0x1ba [jbd]
[<c0490a32>] __writeback_single_inode+0x1a3/0x2af
[<c04568ea>] do_writepages+0x2b/0x32
[<c045239b>] __filemap_fdatawrite_range+0x66/0x72
[<c04910ce>] sync_inode+0x19/0x24
[<ee09b007>] ext3_sync_file+0xaf/0xc4 [ext3]
[<c047426f>] do_fsync+0x41/0x83
[<c04742ce>] __do_fsync+0x1d/0x2b
[<c0405413>] syscall_call+0x7/0xb
=======================
Я попытался отключить irqbalanced, как было предложено Вот но, похоже, это не имеет никакого значения.
Обновления:
domU# cat /sys/block/xvda/queue/scheduler
[noop] anticipatory deadline cfq
При копировании файлов с / на диск нагрузка остается <4. Последующее копирование приводит к увеличению нагрузки. Копирование файлов по сети вызывает загрузку> 4 при первом запуске, последующее копирование приводит к тому, что сервер почти полностью останавливается, требуя времени для охлаждения, он никогда не отключается, просто дайте ему 10-15 минут, чтобы восстановиться. Но на самом деле сервер так себя вести не может.
Сетевой трафик сам по себе не вызывает никаких проблем с запуском iperf, например, не дает никакого измеримого эффекта. Сообщаемая пропускная способность> 1 Гбит.
Производительность записи на dom0 в порядке
dom0# dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 34.9725 seconds, 30.7 MB/s
Производительность записи на domU низкая
domU# dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 622.163 seconds, 1.7 MB/s
Это потеря производительности ~ 95%.
Производительность чтения в порядке
dom0# hdparm -tT /dev/cciss/c0d0p1
/dev/cciss/c0d0p1:
Timing cached reads: 3352 MB in 2.00 seconds = 1676.70 MB/sec
Timing buffered disk reads: 100 MB in 2.59 seconds = 38.57 MB/sec
domU# hdparm -tT /dev/xvda
/dev/xvda:
Timing cached reads: 3144 MB in 2.00 seconds = 1571.51 MB/sec
Timing buffered disk reads: 120 MB in 3.03 seconds = 39.67 MB/sec
Обновить:
Похоже, что это все-таки связано с оборудованием. Но он не появлялся, пока не запустил xen. Аккумулятор не заряжался нормально, это приводило к отключению кеша. Это в сочетании с интенсивным вводом-выводом виртуальной машины привело к большому времени ожидания.
Теперь сразу после обновления прошивки ничего не изменилось, но с момента обновления прошивки аккумулятор теперь заряжается правильно. И после того, как аккумулятор полностью заряжен, скорости записи теперь приемлемы, для небольших файлов они превышают скорость dom0, не имея ни малейшего представления о том, почему это происходит.
domU# dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 39.1087 seconds, 27.5 MB/s
Я бы винил в этом старую xen-версию, используемую на вашем хосте (CentOS 5.5). Я действительно могу порекомендовать использовать SLES 10 или 11. В 11 встроен XEN 4.x.
У меня нет проблем с производительностью с моими CentOS 5 DomU, работающими на SLES 10 Dom0s.