LINUX.ORG.RU
ФорумAdmin

Настройки Apache при пиковой нагрузке

 


0

3

На одном из сайтов посещаемость выросла до 40тыс. посетителей в сутки, и начались проблемы :( В пик посещаемости страницы грузятся очень долго (30-60 sec). Сайт на самописной CMS: PHP/MySQL, mod_rewrite активно используется.

У меня VPS (CentOS 6.2, Plesk, Apache 2.2, RAM 3Gb).

Попробовал увеличить MaxClients до 100 - стала забиваться память (0k free): http://i.imgur.com/6zmgXDW.png

Сейчас снизил MaxClients до 60, но в логе появилась ошибка:

server reached MaxClients setting, consider raising the MaxClients setting

Из того что вычитал по форумам - советуют nginx поставить перед Apache, но в Plesk такого не предлагается, а самому поставить опыта не хватает.

Собственно вопрос - что бы такого подкрутить чтоб Apache меньше памяти жрал, и вообще какие есть рекоммендации по оптимизации настроек Apache при большом количестве запросов?

40 тыс. в сутки — это не нагрузка даже для Apache.

Что-то другое тормозит. PHP-скрипты, видимо, тяжёлые слишком.

KRoN73 ★★★★★ ()

В пик посещаемости страницы грузятся очень долго (30-60 sec).

Тут только настройками апача не решить проблему. Рекомендую выкинуть apache вообще и использовать nginx без апача. Ничего особо страшного в настройке без plesk, но перед выкладыванием на хостинг потренируйся на своей машине. Нет, конечно, можно потыкать mod_cache, но зачем?

http://blog.yourlabs.org/post/46416407809/drupal-7-with-nginx-and-uwsgi-php-e... — пример настройки с url rewrite, оно подойдёт далеко не для одного друпала.

anonymous ()

ТС nginx частично решит твои проблемы, ибо тут скорее всего проблемные скрипты или база. Надо профилирование делать на синтетической нагрузке.

MikeDM ★★★★★ ()

Спасибо всем за ответы!

На PHP скрипты и базу я бы подумал в последнюю очередь, т.к. все писал сам и, по моим представлениям, у меня в коде ничего лишнего не должно быть. Но поскольку сразу несколько человек указали именно на скрипты, думаю придется сделать ревизию кода.

Дело в том, что сайт у меня сезонный. Пик посещаемости приходится на Октябрь. И каждый год количество посетителей в сезон возрастает раза в 2-3 по сравнению с предыдущим годом. В прошлом году на пике было порядка 50 тыс. посетителей в сутки (в пиковые часы 5 тыс. посещений в час), и сайт этот пик как-то пережил на этом же VPS, тогда проблем я не замечал. Не совсем понимаю что изменилось. В коде сайта изменения были, но незначительные. Возможно автоматические обновления Plesk внесли свои коррективы?

В какой-то момент после очередного обновления Plesk, error_log начал забиваться строками типа:

[apc-warning] Unable to allocate memory for pool. in ...
Эту проблему решил апгрейдом APC... и последующим его отключением, т.к. с ним Apache жрал еще больше памяти.

На что еще подумать не знаю.

Надо профилирование делать на синтетической нагрузке.

Могу только догадываться что это означает :) но видимо эта процедура потребует значительного времени и некоторых специфических знаний, которых у меня катастрофически не хватает.

angrybird ()

однозначно nginx, apache при этом можно не убирать.

xtraeft ★★☆☆ ()
Последнее исправление: xtraeft (всего исправлений: 1)
Ответ на: комментарий от no-dashi

@ no-dashi

При увеличении MaxClients свободная память быстро кончается, это вроде не есть гуд?

angrybird ()
Ответ на: комментарий от angrybird

логи настроить. или виртуалхосты каждый на отдельного пользователя и смотреть кто сколько жрёт, например, в атопе

xsektorx ★★★ ()
Ответ на: комментарий от xsektorx

@xsektorx

до 10-30 снизь. мне как-то помогло. или до нуля вообще

Это такая шутка, да? Если MaxRequestsPerChild сделать нулем, то это наоборот снимает ограничения.

angrybird ()
Ответ на: комментарий от angrybird

а, точно. ну тогда попробуй на единицу, если 30 не поможет. и пали логи ещё

xsektorx ★★★ ()

Сайт на самописной CMS

this

leave ★★★★★ ()

Включи apc ( или любой другой акселератор ).

[apc-warning] Unable to allocate memory for pool. in ...

Проблема известная, как лечится легко гуглиться.

Сейчас снизил MaxClients до 60

Если скрипты будут выполняться быстро, то при такой посещаемости должно хватить 30-35. По ситуации можно увеличивать.

Так же в момент проблемы рекомендую посмотреть, как себя чуствует база.Обратить внимание на запросы выполняющиеся дольше 3 секунд. Наглядно можно мониторить через mytop.

gillion ()
Ответ на: комментарий от gillion

И да MaxRequestsPerChild смысла делать маленьким нет, если не было замечено залипание в работе, утечки памяти в скриптах. Только ненужный оверхед будет.

gillion ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.