Источник: pcmag.ru.
Автор: Екатерина Иванникова
Несколько лет назад я с интересом прочитала статью, в которой авторы рассматривали влияние отдельных неисправных компонентов на производительность системы в целом [1]. В своем исследовании они показывали, что неисправность отдельного аппаратного или программного компонента не обязательно сразу же приводила к его полному выходу из строя, т. е. реализации так называемой модели “fail-stop”. Система в течение некоторого, иногда достаточно длительного времени могла продолжать функционировать в режиме сниженной производительности. Эту модель авторы назвали “fail-stutter”. Анализируя влияние такого поведения системы на ее управляемость, доступность и надежность, авторы, в частности, пришли к выводу, что неожиданное снижение производительности может быть ранним указанием на возникшую неисправность.
Я вспомнила об этой статье, когда недавно работала над одной проблемой. Наш заказчик обратился с просьбой проанализировать метрики производительности компьютерной системы — сервера HP rx6600 под управлением операционной системы HP-UX 11.31. На нем было установлено ПО HP GlancePlus/UX Pak, позволяющее осуществлять мониторинг большого количества метрик системы, и, несомненно, хорошо знакомое системным администраторам, работающим с OC HP-UX. Заказчик предоставил данные за несколько дней, в течение которых сервер работал под рабочей нагрузкой, затем был остановлен и позже снова запущен в работу.
Анализируя метрики системы, я обратила внимание на необычно высокий, примерно 10-11%, уровень утилизации процессоров, обусловленной обработкой прерываний. На рисунке 1 график изменения значений этой метрики (GBL_CPU_INTERRUPT_UTIL) показан оранжевым цветом.
Рисунок 1.
Сравнив этот график с графиками значений метрик интенсивности дискового (GBL_DISK_PHYS_READ_RATE, GBL_DISK_PHYS_WRITE_RATE) и сетевого (GBL_NET_IN_PACKET_RATE, GBL_NET_OUT_PACKET_RATE) ввода-вывода, приведенных на рисунках 2 и 3, я убедилась в том, что утилизация процессоров обработкой прерываний не зависела от уровня реальной нагрузки на систему. Она оставалась практически неизменной и при максимальном, и при минимальном вводе-выводе.
Рисунок 2.
Рисунок 3.
Следующим шагом стало определение конкретного процессора, ответственного за высокий общий уровень утилизации обработкой прерываний. Из рисунка 4 видно, что им оказался процессор с номером 14, уровень утилизации которого постоянно превышал 80%. Необходимо отметить, что данная модель сервера имеет процессоры Itanium Montvale, поддерживающие технологию Hyper-Threading. Когда опция использования этой технологии не активирована, как в данной системе, процессоры нумеруются через один: 0,2, и так далее до 14. При активации опции Hyper-Threading в системе появляются дополнительные логические процессоры 1, 3, … 15.
В ОС HP-UX имеется утилита intctl, позволяющая определить, прерывания от каких периферийных устройств обрабатывает каждый из процессоров. В данном случае интересующий меня процессор с номером 14 обрабатывал прерывания от сетевой карты и контроллера USB.
# intctl -p
cpu cpu cpu cpu class hw path drv IF intr intr card
ID path state cell name cell ID type description
==================================================================================================
0 120 ENABLED N/A tty 0/0/1/2 asio0 N/A 1 L PCI Serial (103c1048)
0 120 ENABLED N/A OO 0/0/2/0 UsbOhci N/A 1 L USB OHCI Interface
0 120 ENABLED N/A lan 0/4/2/0 iether N/A 1 L HP AB352-60003 PCI/PCI-X 1000Base-T Dual-port Core
0 120 ENABLED N/A tty 250/1 asio0 N/A 1 L Built-in RS232C
2 121 ENABLED N/A lan 0/3/0/0/0/1 iether N/A 1 L HP AD337-60001 PCIe 1000Base-T Dual-port Adapter
4 122 ENABLED N/A lan 0/3/0/0/0/0 iether N/A 1 L HP AD337-60001 PCIe 1000Base-T Dual-port Adapter
6 123 ENABLED N/A fc 0/5/1/0 fcd N/A 1 L HP AB378-60101 4Gb Single Port PCI/PCI-X Fibre Channel Adapter (FC Port 1)
8 124 ENABLED N/A escsi_ctlr 0/4/1/0 sasd N/A 1 L HP PCI/PCI-X SAS MPT Adapter
8 124 ENABLED N/A lan 0/4/2/1 iether N/A 1 L HP AB352-60003 PCI/PCI-X 1000Base-T Dual-port Core
10 125 ENABLED N/A fc 0/2/1/0 fcd N/A 1 L HP AB378-60101 4Gb Single Port PCI/PCI-X Fibre Channel Adapter (FC Port 1)
10 125 ENABLED N/A acpi_node 250/2 acpi_node N/A 1 L Acpi Hardware
12 126 ENABLED N/A OO 0/0/2/2 UsbEhci N/A 1 L USB EHCI Interface
12 126 ENABLED N/A lan 0/7/0/0/0/1 iether N/A 1 L HP AD337-60001 PCIe 1000Base-T Dual-port Adapter
14 127 ENABLED N/A OO 0/0/2/1 UsbOhci N/A 1 L USB OHCI Interface
14 127 ENABLED N/A lan 0/7/0/0/0/0 iether N/A 1 L HP AD337-60001 PCIe 1000Base-T Dual-port Adapter
С этими данными я обратилась в техническую поддержку HP. После обсуждения ситуации с инженером технической поддержки было принято решение по очереди перенести прерывания от сетевой карты и контроллера USB на другой процессор, одновременно контролируя уровень утилизации задействованных процессоров. Перенос прерываний осуществлялся при помощи той же утилиты intctl, для контроля утилизации использовалась утилита glance. После того, как инженер заказчика выполнил эти действия, стало ясно, что избыточная утилизация процессора обработкой прерываний вызывается контроллером USB. Была произведена замена контроллера, и общий уровень утилизации процессоров обработкой прерываний снизился до нормального значения, менее 1%.
Функционируя с неисправным контроллером, сервер лишился 10% своей вычислительной мощности, так как один из восьми процессоров был почти полностью занят обработкой избыточных прерываний. Анализ метрик производительности позволил своевременно выявить и устранить неисправность, до того, как она смогла повлиять на надежность работы системы.
В заключение я бы хотела поблагодарить инженера критической поддержки HP Сергея Блатова за помощь в работе над описанной проблемой.
Литература:
1. R. H. Arpaci-Dusseau, A. C. Arpaci-Dusseau “Fail-Stutter Fault Tolerance”, 2001, http://www.cs.wisc.edu/wind/Publications/fail-stutter.ps
