Назад | Перейти на главную страницу

Высокая загрузка ЦП 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% всего ЦП на граф пламени) мы имеем следующие удивительные случаи использования времени:

В основном, за пределами этих двух замечательных выбросов, все время выполнения тратится внутри двух вызовов libc, poll_nocancel и read_nocancel, исходящих как из цикла прослушивания apache, так и из исходящего трафика плагина WebLogic, которые, среди прочего, приводят к вызовам swapgs и readtsc.

Базовое оборудование кажется прекрасным, параметры ядра Linux кажутся прекрасными, но кажется, что фактические инструкции в секунду, выполняемые на этом сервере, очень медленные. Есть какие-нибудь советы по дальнейшему анализу с помощью инструмента perf? У меня нет доступа к серверу, поэтому я могу только предлагать команды для запуска другим.

Это ваше изображение пламени в статическом формате, обрезанное для удаления тонких глубоких стеков:

Да, многие образцы на CPU связаны с системными вызовами. Много poll () и результирующий read_tsc (), немного read () и, очевидно, некоторые накладные расходы на системные вызовы с учетом времени, проведенного в system_call_after_swapgs ().

Теперь это становится поиском ошибок производительности и неэффективности в все уровни вашей инфраструктуры. Неполный список идей:

Гипервизор

Относительно TSC на VMware см. КБ 65186

Проблема с производительностью, когда TSC неправильно определены как несинхронизированные (65186)

Симптомы Во время загрузки vmkernel регистрирует сообщение, содержащее фразу «TSC отключен как эталонный таймер: несколько тактовых доменов» или «TSC отключен как эталонный таймер: расходящиеся NUMA TSC».

Впоследствии виртуальные машины показывают необычно низкую производительность при выполнении инструкции rdtsc.

Причина На большинстве современных x86-совместимых машин аппаратное обеспечение гарантирует, что регистры TSC (счетчик отметок времени) всех логических процессоров синхронизируются во время загрузки и всегда остаются синхронизированными друг с другом, если не изменяются программным обеспечением, поэтому TSC можно рассматривать как единый глобальный эталонный таймер. ESXi лучше всего работает на машинах с такими синхронизированными TSC. ESXi также поддерживает машины с несинхронизированными TSC, но со значительным снижением производительности. В частности, выполнение инструкции rdtsc на виртуальной машине может быть примерно в 100 раз медленнее, если на хосте есть несинхронизированные TSC.

На некоторых современных машинах ESXi неправильно определяет TSC хоста как несинхронизированные из-за разницы в интерпретации определенных полей таблицы ACPI, предоставляемых встроенным ПО. В настоящее время этой проблеме подвержено большинство машин серии HPE Superdome.

Решение На данный момент нет решения по этой проблеме.

Примечание об обходном пути: не применяйте этот параметр на машине, на которой действительно нет синхронизированных TSC. Если вы это сделаете, машина в конечном итоге выйдет из строя, когда TSC разойдутся слишком далеко друг от друга, и перед аварией могут возникнуть сбивающие с толку симптомы.

Если хост определенно имеет синхронизированные TSC, вы можете заставить vmkernel использовать TSC в качестве глобального эталонного таймера со следующей опцией загрузки: 

esxcli system settings kernel set
 --setting=timerForceTSC --value=TRUE

В качестве альтернативы принудительному обходному пути TSC рассмотрите возможность тестирования хоста на альтернативном гипервизоре. Например, KVM, Hyper-V или голый металл. В любом случае, устранение этой проблемы должно быть очевидным, поскольку на функции TSC затрачивается в 100 раз меньше времени.

заявка

wl_ssl_conn_recv находится в стеке 80% времени. Это должна быть функция WebLogic, поскольку я не нахожу ее в исходном коде httpd.

Часть времени, затрачиваемого на это, в конечном итоге связано с poll () и TSC, поэтому сначала проверка синхронизированного TSC может быть более быстрой победой. Тем не менее, загляните в настройка производительности WebLogic.

HTTPS-разговоры

Также проанализируйте, как выглядят разговоры по протоколу в сети. А именно, как работает https. Попробуйте захват и анализ пакетов, посмотрите, как выглядит время ответа. Оцените скорость соединений: 30 в секунду немного отличается от 300.

Может быть, есть эффективность в реализации HTTP / 2, но я не знаю, как это сделать в WebLogic.

Патчи безопасности

Значительная часть вашего процессорного времени связана с системными вызовами. Оцените, какие исправления и меры защиты вы включили Призрак / Meltdown и MDS. Известно, что они имеют относительно высокую производительность при тяжелых рабочих нагрузках системных вызовов. Протестируйте различные уровни смягчения и сделайте оценку рисков на основе ваших общих мер безопасности.

Планирование мощности

Может быть, 4 CPU просто недостаточно, по крайней мере, как эта система сейчас настроена. Использование оборудования для решения проблемы с большим количеством экземпляров или большего количества процессоров может быть неэффективным, но, по крайней мере, вы можете поддерживать отзывчивость, настраивая другие вещи.