Некоторые владельцы наших приложений говорят, что некоторым процессам требуется вдвое больше времени, чем следовало бы.
У этого мы чесали голову.
Мы не можем понять, почему некоторые операции на сервере 1 занимают вдвое больше времени, чем на сервере 2.
Сервер 1: IBM x3850 M2 (RHEL 4 Nahant Update 8)
Сервер 1 в основном простаивает с точки зрения ввода-вывода. S1 и S2 оба находятся на дисках SAS в Raid 5. Сервер 1 имеет 4 диска, Сервер 2 имеет 4 диска. Выход Iostat с сервера 1
Linux [имя хоста удалено] 2.6.9-89.ELsmp # 1 SMP Mon Apr 20 10:34:33 EDT 2009 i686 i686 i386 GNU / Linux
Выход / proc / cpuinfo
Выход / proc / meminfo
Сервер 2: IBM x3650 (RHEL 4 Nahant Update 8)
Сервер 2 является более активным из двух серверов. Вывод iostat выглядит так, как будто из-за многопутевости SAN подключено множество устройств. Операции dd и tar выполнялись в локальном хранилище. Выход Iostat с сервера 2
Linux [имя хоста удалено] 2.6.9-78.0.13.ELsmp # 1 SMP, среда, 7 января, 17:52:47 EST 2009 i686 i686 i386 GNU / Linux
Выход / proc / cpuinfo
Выход / proc / meminfo
Как и ожидалось, операция записи файла размером 1 ГБ на Сервере 1 выполняется быстрее.
[server1]$ time dd if=/dev/zero of=bigfile bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
real 0m15.032s
user 0m0.961s
sys 0m11.389s
По сравнению с Сервером 2, это похоже на проверку:
[server2]$ time dd if=/dev/zero of=bigfile bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
real 0m27.519s
user 0m0.531s
sys 0m8.612s
Однако архивирование того же файла на сервере 1 занимает в два раза больше времени «пользователя» и немного больше времени в реальном времени.
[server1]$ time tar -czf server1.tgz bigfile
real 0m27.696s
user 0m20.977s
sys 0m5.294s
[server2]$ time tar -czf server2.tgz bigfile
real 0m23.300s
user 0m10.378s
sys 0m3.603s
Производительность массовых операций ввода-вывода гораздо больше зависит от скорости жесткого диска и текущей нагрузки ввода-вывода, а не от процессора.
Это именно тот тип проблем, для решения которых идеально подходит такой инструмент, как collectl. Определение времени, необходимого для запуска dd или tar, - хорошее начало, но что происходит между ними? Стабильны ли ваши ставки ввода-вывода или они достигают спадов и срывов? Есть множество вещей, которые могут пойти не так от начала до конца.
Поскольку у вас есть система с заведомо «хорошим» профилем производительности, вы лучше всех можете решить эту проблему. Запускайте тесты вместе с collectl и наблюдайте за своим процессором, памятью, сетью и дисками (все на одной линии, что позволяет легко отслеживать тенденции во времени). Вы также можете посмотреть такие вещи, как nfs, tcp, сокеты и несколько других вещей, но я подозреваю, что это не относится к этому случаю.
Теперь повторите тест на коробке, зная, что у него низкая производительность, и посмотрите, что изменилось. Ответ будет там. Это может быть нехватка памяти, слишком много прерываний на процессоре (collectl тоже может это показать) или большое время ожидания ввода-вывода. Что бы это ни было, вы можете идентифицировать это, но затем вы должны выяснить, в чем заключается основная причина. Могли быть сильно фрагменты или даже плохой диск. Может с контроллером что-то не так. Это вам предстоит выяснить.
Надеюсь это поможет...
-отметка