Недавно мы заменили веб-сервер RHEL 5.6 на RHEL 6.1. Для обеих сред использовался (стандартный) поставляемый Redhat Apache httpd (то есть yum install httpd). Сервер обслуживает содержимое PHP и занят (обслуживает примерно 2500-4000 запросов страниц в минуту). Технические характеристики обоих серверов идентичны с точки зрения памяти, хранилища и сетевого подключения. То, что мы наблюдаем, - это значительно более высокие средние значения нагрузки в блоке RHEL 6.1, где средняя загрузка (время от времени) возрастает до более чем 40 (все процессы httpd), что приводит к существенному снижению производительности сайта. Мы наблюдали за средой RHEL 5.6, и средняя загрузка не превышает примерно 5 одновременных httpd. Как мы можем исследовать эту проблему? Имейте в виду, что это производственная среда, но мы можем сравнить «яблоки с яблоками», переключаясь между серверами 5.6 и 6.1.
Обновление с 5.6 до 6.1 - большой шаг - вы, вероятно, используете разные версии apache, php и, возможно, также кеш байт-кода.
Если вы используете кеш байт-кода (который, я считаю, вам следует использовать с той нагрузкой, которую вы описываете), вы должны убедиться, что он работает (я знаю, что apc изменил некоторый синтаксис конфигурации между версиями, например). Какой из них вы в таком случае используете?
У вас должны быть некоторые показатели, объясняющие, какое время процессора тратится - будь то IOWait, системное время или время пользователя. То же самое и с использованием памяти и т. Д. Как все это выглядит?
Я снова порекомендую какой-нибудь инструмент для мониторинга, например, Munin.
Ваши 2500-4000 запросов в минуту переводятся в 40-60 запросов в секунду. Такая загрузка вряд ли требует настройки на уровне ядра, но, скорее всего, что-то не так с настройкой Apache или PHP. Некоторые типичные причины включают
TimeOut значения в httpd.confKeepAlive on и / или долго KeepAliveTimeOut значения в httpd.conf (может привести к дополнительным процессам httpd)memcached настройка (если используется)Вам нужно выяснить, чем отличается ваш старый сервер. Вы копировали значения конфигурации со старого сервера на новый? Был ли старый сервер настроен много лет назад, и вы забыли что-то важное?
Что показывает страница статуса сервера Apache?
Если ничего не помогает, вы всегда можете использовать PHP XDebug модуль. Это означает, что вы выполняете загрузку страниц на своем сервере и позволяете XDebug генерировать для вас отчет, совместимый с Valgrind. Затем вы можете проанализировать этот файл с помощью KCacheGrind или какой-нибудь другой анализатор и посмотрите, на что расходуется драгоценное время процессора. Это может дать вам представление о том, что не так.
Возможно, вы сможете сравнить результат sysctl -A на обеих системах? Возможно, вы настроили ядро RHEL5. Я также обнаружил, что oprofile помогает определить, на что ядро и процессы тратят время.
Изменить: я предполагаю, что apache и php настроены одинаково.
Вопрос: одинаковы ли обе конфигурации apache, т.е. используете ли вы вызовы потоков или процессов для каждого запроса?
Если вы используете вызовы процессов, то процесс создается для каждого запроса (с несколькими оставшимися позади) и, следовательно, с более высоким коэффициентом загрузки.
Если вы используете вызовы потоков, то некоторое количество запросов будет обрабатываться потоками в пределах гораздо меньшего числа процессов.
Таким образом, не могло быть ничего плохого.
Хотя многое зависит от того, что на самом деле делает PHP, IMHO средняя загрузка кажется довольно высокой даже на старой машине, но, очевидно, насущной проблемой является разница в поведении между старым и новым.
Вы уверены, что конфиги такие же? Вы проверили журналы ошибок apache, чтобы узнать, есть ли у него какие-либо проблемы с какой-либо из директив обработки? Вы проверили разрешения для каталога eaccelerator?
Коробка использует внешние ресурсы (например, DNS, базу данных)? Если да, то находится ли он в той же сети, что и старый? Похоже ли время RTT на других серверах?
Можете ли вы легко понизить версию коробки до RH5.6? Если да, то решает ли это проблему?
Вы видите изменение пропускной способности или времени ответа на запрос (% D)?
У работника более низкие требования к памяти
На самом деле разница не так уж велика - поскольку большая часть памяти находится в сегментах TXT, отмеченных как COW. На самом деле, некоторые тесты показать, что предварительная вилка более масштабируема, чем рабочие потоки в Linux.