Archive

Archive for October, 2010

Отключение yum-updatesd в CentOS

October 12th, 2010

По умолчанию в системе присутствует сервис yum-updatesd, который проверяет наличие обновлений и информирует через email, syslog или dbus. Иногда он занимает довольно много CPU, а пользы на сервере от него не много. Отключаем:

chkconfig yum-updatesd off
/etc/init.d/yum-updatesd stop

linux ,

Переходим с prefork на mpm-worker на Apache с mod_php (CentOS)

October 11th, 2010

Итак, допустим вы решили перейти на worker MPM в Apache чтобы повысить производительность. Имеем CentOS с Apache и PHP установленные из репозитория Remi.
Сначала устанавливаем новый тредобезопасный модуль PHP:

yum --enablerepo=remi install php-zts

Возможно придется обновить PHP до последней версии.

Затем в /etc/sysconfig/httpd раскомментируем строчку:

HTTPD=/usr/sbin/httpd.worker

Убедимся, что в конфиге апача присутствуют примерно такие настройки:

<IfModule worker.c>
StartServers       1
MaxClients         50
MinSpareThreads     15
MaxSpareThreads     35
ThreadsPerChild     25
MaxRequestsPerChild  2000
</IfModule>

Где:
StartServers – сколько процессов стартует при запуске
MinSpareThreads/MaxSpareThreads – сервер будет держать количество свободных потоков (про запас) в этих рамках. Свободные потоки – это сумма потоков во всех процессах
MaxClients – максимально количество одновременных клиентов. Т.е. максимальное количество потоков во всех процессах.
ThreadsPerChild – сколько потоков может создавать каждый процесс. Т.о. если мы разделим MaxClients на ThreadsPerChild, то получим сколько максимум процессов будет создано при максимальной загрузке.
ServerLimit – сколько макс. процессов может быть. Естественно, это число должно быть не меньше MaxClients/ThreadsPerChild – числа процессов при максимальной нагрузке.
MaxRequestsPerChild – через сколько запросов уничтожается процесс.

Если используется Zend или IonCube надо поправить пути к ним (обычно в php.ini), заменив на тредобезопасные варианты.

Рестартуем апач:

/etc/init.d/httpd restart

И получаем результат:

ps auxww |grep http
root     19552  0.0  0.5  31020 11300 ?        Ss   20:50   0:00 /usr/sbin/httpd.worker
apache   19555  150 39.2 1125872 813092 ?      Sl   20:50  17:17 /usr/sbin/httpd.worker

linux ,

Олимпиада для unix администраторов

October 9th, 2010

В ближайший понедельник 11 октября 2010 года стартуют игры первого тура Олимпиады для unix администраторов. Огранизатор Яндекс проводит первую Олимпиаду для системных администраторов —
специалистов в области Open Source и Unix. Участники олимпиады соревнуются в умении быстро и правильно отвечать на вопросы, с которыми ежедневно сталкиваются системные администраторы Яндекса.
Офф. сайт олимпиады.

Uncategorized

Оптимизация использования памяти для Apache

October 6th, 2010

Памяти никогда много не бывает. И по мере роста трафика сервер может начать свопиться, а это очень плохо. Посмотрим что же можно сделать:

  • Во-первых, сначала надо убедиться, что перед апачем установлен nginx (ну или лайти) и он отдает напрямую всю статику: графику, видео, js, css, какие-либо архивы и прочее. Для контроля очень удобно воспользоваться встроенными возможностями апача просмотра статуса:
    <Location /server-status>
            SetHandler server-status
    </Location>
    ExtendedStatus On
  • Обязательно нужно внимательно пройтись по конфигу апача и закомментировать загрузку неиспользуемых модулей
  • Так же нужно проконтролировать, чтобы максимальное одновременное количество клиентов апача не превышало объема установленной на сервере памяти. Просто делим общее количество памяти на количество занимаемое одним процессом апача за минусом памяти под mysql и прочее. Иначе система уйдет в своп и катастрофически деградирует.
    StartServers       3
    MinSpareServers    3
    MaxSpareServers   5
    ServerLimit      12
    MaxClients       12
  • Так же можно поставить MaxRequestsPerChild поменьше (~500) чтобы форки апача почаще перезапускались и освобождали память.
  • Если используется Eaccelerator, то надо проверить что eaccelerator.shm_size не очень большое, = “64” вполне подойдет
  • Если ничего не помогает, то нужно попытаться определить какой из виртуалхостов самый прожорливый. Можно просто по очереди тестировать сайты на сервере при помощи loadimpact и наблюдать за нагрузкой. Скорее всего найдется код создающий максимальную нагрузку по памяти. Далее можно пойти путем оптимизации кода либо попрбовать перенести именно этот виртуалхост на php в режиме fast cgi.
  • Так же нужно не забывать про возможность просто взять более мощный сервер. Благо, например, у Hetzner за смешные деньги можно арендовать сервер с 8 и более ГБ памяти. Часто это может оказаться самым “дешовым” решением.

Apache ,