Высокая загрузка ЦП apache / httpd при небольшой нагрузке, 'perf record' указывает на vmware / hardware
Запуск Apache 2.4 на ядре RHEL7 3.10.0-1062, 4-процессорный экземпляр VMWare, выполнение очень простого обратного проксирования на бэкэнд WebLogic с использованием подключаемого модуля прокси WebLogic. Сервер передает только 1 МБайт / сек с парой сотен пользователей, прослушивая SSL, а также сообщая SSL с WebLogic. Конфигурация Apache очень проста, всего пара строк RewriteRule или других типичных приемников производительности. Статистика VMWare не показывает чрезмерной нагрузки, но также показывает загрузку гостевого ЦП на уровне 100%.
В Linux POV сервер работает со 100% загрузкой ЦП и очередью выполнения более 16, а Apache использует все время ЦП. Выполнение 'perf record -a -g' на минуту и создание графа пламени показывает, что в процессе httpd (с использованием 97% всего ЦП для каждого графа пламени) у нас есть эти удивительные варианты использования времени:
- ktime_get_ts64 -> read_tsc - 20,5% из всех образцов ЦП, похоже, просто выполняет инструкцию rdtsc
- system_call_after_swapgs - 13,24% всех образцов ЦП, похоже, ссылается на довольно краткий код на https://git.kernel.org/pub/scm/linux /kernel/git/stable/linux.git/tree/arch/x86/kernel/entry_64.S?h=linux-3.10.y#n625
В основном за пределами этих двух замечательных выбросов все время выполнения тратится внутри двух вызовов libc , poll_nocancel и read_nocancel, поступающие как из цикла прослушивания apache, так и из исходящего трафика подключаемого модуля WebLogic, которые, среди прочего, приводят к этим вызовам swapgs и readtsc.
Базовое оборудование в порядке, параметры ядра Linux кажутся прекрасными, но похоже на настоящие инструкции в секунду выполняется на этом сервере очень медленно. Есть какие-нибудь советы по дальнейшему анализу с помощью инструмента perf? У меня нет доступа к серверу, поэтому я могу только предлагать команды для запуска другим пользователям.
Этот ваш флэмеграфик в статическом формате, обрезанный для удаления тощих глубоких стеков:
Да, большая часть образцов на CPU связана с системными вызовами. Много функций pol() и, как следствие, read_tsc(), немного read(), и, видимо, немного накладных расходов на системные вызовы, учитывая время, проведенное в system_call_after_swapgs().
Теперь это становится поиском ошибок производительности и неэффективности во всех слоях вашей инфраструктуры. Недостаточный список идей:
Гипервизор
Что касается TSC на VMware, см. KB 65186
Проблема производительности, когда TSC неправильно определены как несинхронизированные (65186)
Симптомы Во время загрузки, vmkernel записывает в журнал сообщения, содержащие фраза "TSC отключен в качестве эталонного таймера: несколько часовых доменов" или "TSC отключен как опорный таймер: расходящиеся NUMA TSC".
Впоследствии виртуальные машины показывают необычайно низкую производительность, когда выполнение команды rdtsc.
Причина На самом современном x86-совместимом машины, оборудование гарантирует, что TSC (счетчик временных меток) регистрирует всех логических процессоров синхронизируются во время загрузки и всегда остаются в синхронизируются друг с другом, если только не изменены программным обеспечением, так что TSC могут быть рассматривается как единый глобальный эталонный таймер. ESXi работает лучше всего машины с такими синхронизированными TSC. ESXi также имеет поддержку машины с несинхронизированными TSC, но со значительной производительностью наказание. В частности, выполнение команды rdtsc в виртуальном машина может быть в 100 раз медленнее, если у хоста есть несинхронизированные TSCs.
На нескольких текущих машинах ESXi некорректно определяет TSCs хоста как будучи несинхронизированным из-за разницы в интерпретации некоторые поля таблицы ACPI, предоставляемые прошивкой. В настоящее время большинство HPE Эта проблема затрагивает машины серии Superdome.
Резолюция На данный момент этот вопрос не решен.
Обходной путь Примечание: Не применяйте эту настройку на машине, у которой на самом деле нет синхронизированные ТСК. Если вы это сделаете, машина в конце концов выйдет из строя, когда ТСК слишком далеко отклоняются друг от друга, и могут быть запутанные симптомы. до падения.
Если хост определенно синхронизировал TSC, вы можете принудительно заставить vmkernel использовать TSC в качестве глобального эталонного таймера со следующими параметрами Опция загрузки:
esxcli system settings kernel set
--setting=timerForceTSC --value=TRUE
В качестве альтернативы силовому обходному пути TSC рассмотрим тестирование хоста на альтернативном гипервизоре. Например, KVM, Hyper-V или "голый металл". В любом случае, смягчение этой проблемы должно быть очевидным при 100-кратном сокращении времени, затрачиваемого на функции TSC.
Application
wl_ssl_conn_recv находится в стеке 80% времени. Это должна быть функция WebLogic, так как в исходных кодах httpd я этого не нахожу.
Часть времени, которое она потратила, в конечном счете, связана с функциями poll() и TSC, поэтому проверка синхронизированного TSC вначале может быть более быстрой победой. Тем не менее, посмотрите настройка производительности WebLogic.
Разговоры HTTPS
Также проанализируйте, как выглядят разговоры протоколов по сети. А именно, как работает https. Попробуйте перехват и анализ пакетов, посмотрите, как выглядит время отклика. Количественно определите скорость соединений, 30 в секунду это немного отличается от 300.
Может быть, есть эффективность в реализации HTTP/2, но я не знаю, как это сделать в WebLogic.
Патчи безопасности
Значительная часть вашего времени работы на процессоре связана с системным вызовом. Оцените, какие патчи и улучшения вы включили для Spectre/Meltdown и MDS. Известно, что эти патчи имеют относительно высокую производительность при больших нагрузках syscall. Протестируйте различные уровни снижения риска и сделайте оценку риска на основе общего контроля безопасности.
Планирование пропускной способности
Может быть, 4-х процессоров просто недостаточно, по крайней мере, как эта система настраивается в настоящее время. Подбрасывание аппаратного обеспечения к проблеме с большим количеством экземпляров или большим количеством процессоров может быть неэффективным, но, по крайней мере, вы можете сохранять способность реагировать на проблемы, одновременно подстраивая под себя другие вещи.