Процессы php-cgi пожирают память размножаясь в геометрической прогрессии и не хотят умирать по истечении лимита FcgidMaxRequestsPerProcess , после чего php-cgi активно начинает сваливать всё в swap и система начинает выдавать " 502 Bad Gateway ".

Чтобы ограничить число форкнутых php-cgi процессов , не достаточно установить FcgidMaxRequestsPerProcess , после обработки которых процессы должны загибаться, но не всегда они делают это добровольно.

Ситуация до боли знакомая когда php-cgi процессы (чилды ) плодятся выедая память, а умирать их ну никак не заставишь - жить хотят с.ки!:) Напоминает проблему с перенаселением земли "пиплами" - неправда ли?;)

Урегулировать извечные дисбаланс между предками и чилдами можно путем ограничения числа php-cgi чилдов, времени их жизни (геноцид ) и контроля активности их размножения (контрацепция ).

Ограничение числа php-cgi процессов для mod_fcgid

Приведённые ниже директивы играют наверное самую главную роль в ограничении числа php-cgi процессов и в большинстве случаев приведённые здесь значения по умолчанию являются ущербными для серверов с оперативной памятью ниже 5-10 ГБ:

• FcgidMaxProcesses 1000 - максимальное количество процессов, которые могут быть активны одновременно;
• FcgidMaxProcessesPerClass 100 - максимальное количество процессов в одном классе (сегменте ), т.е. максимальное количество процессов которое разрешено порождать через один и тот же враппер (wrapper - обвертку );
• FcgidMinProcessesPerClass 3 - минимальное количество процессов в одном классе (сегменте ), т.е. минимальное количество процессов запускаемые через один и тот же враппер (wrapper - обвертку ), которое будет доступно после завершения всех запросов;
• FcgidMaxRequestsPerProcess 0 - FastCGI должен "сыграть в ящик" после выполнения этого количества запросов.

Какое число php-cgi процессов будет самым оптимальным? Для определения оптимального числа php-cgi процессов нужно {pub}Зарегистрироваться на нашем сайте!:) {/pub}{reg}принимать во внимание общий объем оперативной памяти и размер памяти выделяемый для РНР в memory_limit (php.ini ), который может быть поглощен каждым из php-cgi процессов при выполнении РНР скрипта. Так например если у нас есть 512 МБ, 150-200 из которых отведено под саму ОС, ещё 50-100 под сервер БД, почтовый МТА и т.д., а memory_limit=64 , то в таком случае на наши 200-250 МБ оперативки мы без особого ущерба можем запустить одновременно 3-4 php-cgi процесса.{/reg}

Настройки тайм-аута жизни php-cgi процессов

При активном размножении php-cgi чилдов, поедая РАМу они могут жить чуть ли не вечно, а это чревато катаклизмами. Ниже есть перечень ГМО-директив, которые помогут урезать срок жизни для php-cgi процессов и своевременно освободить занимаемые ими ресурсы:

• FcgidIOTimeout 40 - время (в сек. ) в течении которого модуль mod_fcgid будет пытаться выполнить скрипт.
• FcgidProcessLifeTime 3600 - если процесс существует дольше этого времени (в секундах ), то он должен будет помечен для уничтожения во время следующего сканирования процессов, интервал которого задается в директиве FcgidIdleScanInterval ;
• FcgidIdleTimeout 300 - если число процессов превышает FcgidMinProcessesPerClass , то процесс, который не обрабатывает запросы за это время (в сек.), во время следующего сканирования процессов, интервал которого задается в директиве FcgidIdleScanInterval , будет отмечен для убивания;
• FcgidIdleScanInterval 120 - интервал, через который mod_fcgid модуль будет искать процессы превысившие лимиты FcgidIdleTimeout или FcgidProcessLifeTime .
• FcgidBusyTimeout 300 - если процесс занят обработкой запросов свыше этого времени (в сек. ), то во время следующего сканирования, интервал которого задается в FcgidBusyScanInterval , такой процесс будет отмечен для убивания;
• FcgidBusyScanInterval 120 - интервал, через который выполняется сканирование и поиск занятых процессов превысивших лимит FcgidBusyTimeout ;
• FcgidErrorScanInterval 3 - интервал (в сек. ), через который модуль mod_fcgid будет убивать процессы ожидающие завершения, в т.ч. и те которые превысили FcgidIdleTimeout or FcgidProcessLifeTime . Убивание происходит путем отправки процессу сигнала SIGTERM , а если процесс продолжает быть активным, то он убивается сигналом SIGKILL .

Нужно принимать во внимание, что процесс превысивший FcgidIdleTimeout или FcgidBusyTimeout может прожить + ещё время FcgidIdleScanInterval или FcgidBusyScanInterval , через которое он будет отмечен для уничтожения.

ScanInterval-ы лучше устанавливать с разницей в несколько сек., например если FcgidIdleScanInterval 120 , то FcgidBusyScanInterval 117 - т.е. чтобы сканирование процессов не происходило в одно и тоже время.

Активность порождения php-cgi процессов

Если ничего из вышеприведённого не помогло, что удивительно, то можно ещё попробовать пошаманить с активностью порождения php-cgi процессов...

Помимо лимитов на количество запросов, процессов php-cgi и времени их жизни, есть ещё такая штука как активность порождения дочерних процессов, которую можно урегулировать такими директивами как FcgidSpawnScore , FcgidTerminationScore , FcgidTimeScore и FcgidSpawnScoreUpLimit , перевод которых с буржуйского думаю я дал правильный (указаны значения по умолчанию ):FcgidSpawnScoreUpLimit , никакие дочерние процессы приложения не будут порождены, а все запросы на порождение должны будут ожидать, пока существующий процесс не освободится или пока оценка (Score ) не упадает ниже этого предела.

Если мой перевод описания и понимание указанных выше параметров верное, то для понижения активности порождения php-cgi процессов следует понизить значение директивы FcgidSpawnScoreUpLimit или увеличить значения FcgidSpawnScore и FcgidTerminationScore .

Итоги

Надеюсь я перечислил и детально разжевал большую часть директив модуля mod_fcgid, которые помогут ограничить число php-cgi и время их жизни , а также понизить потребление ресурсов. Ниже приводиться полная конфигурация mod_fcgid для успешно рабочего сервера с процессором 2500 Мгц и оперативной памятью 512 Мб:

Олег Головский

17 дек 2010

У нас вы можете скачать бесплатно .
Данный материал предоставлен сайтом исключительно в ознакомительных целях. Администрация не несет ответственности за его содержимое.

В этой статье я опишу принципиальные различия Apache и Nginx, архитектуру фронтэнд-бэкэнд, установку Apache в качестве бэкэнда и Nginx в качестве фронтэнда. А также опишу технологию, позволяющую ускорить работу веб-сервера: gzip_static+yuicompressor.

Nginx – сервер легкий; он запускает указанное число процессов (обычно число процессов = числу ядер), и каждый процесс в цикле принимает новые соединения, обрабатывает текущие. Такая модель позволяет с низкими затратами ресурсов обслуживать большое количество клиентов. Однако, при такой модели, нельзя выполнять длительные операции при обработке запроса (например mod_php), т.к. это по сути повесит сервер. При каждом цикле внутри процесса по сути выполняются две операции: считать блок данных откуда-то, записать куда-то. Откуда-то и куда-то – это соединение с клиентом, соединение с другим веб-сервером или FastCGI-процессом, файловая система, буфер в памяти. Модель работы настраивается двумя основными параметрами:
worker_processes – число запускаемых процессов. Обычно устанавливают равным числу ядер процессора.
worker_connections – максимальное число соединений, обрабатываемых одним процессом. Напрямую зависит от максимального числа открытых файловых дескрипторов в системе (1024 по умолчанию в Linux).

Apache – сервер тяжелый (следует заметить, что при желании его можно достаточно облегчить, однако это не изменит его архитектуры); он имеет две основных модели работы – prefork и worker.
При использовании модели prefork Apache создает новый процесс для обработки каждого запроса, и этот процесс выполняет всю работу: принимает запрос, генерирует контент, отдает пользователю. Настраивается эта модель следующими параметрами:

MinSpareServers – минимальное число висящих без дела процессов. Нужно это для того, чтобы при поступлении запроса быстрее начать его обрабатывать. Веб-сервер будет запускать дополнительные процессы, чтобы их было указанное количество.
MaxSpareServers – максимальное число висящих без дела процессов. Это нужно, чтобы не занимать лишнюю память. Веб-сервер будет убивать лишние процессы.
MaxClients – максимальное число параллельно обслуживаемых клиентов. Веб-сервер не запустит более указанного количества процессов.
MaxRequestsPerChild – максимальное число запросов, которые обработает процесс, после чего веб-сервер убьет его. Опять же, для экономии памяти, т.к. память в процессах будет постепенно «утекать».

Эта модель была единственной, которую поддерживал Apache 1.3. Она стабильная, не требует от системы многопоточности, но потребляет много ресурсов и немного проигрывает по скорости модели worker.
При использовании модели worker Apache создает несколько процессов, по несколько потоков в каждом. При этом каждый запрос полностью обрабатывается в отдельном потоке. Чуть менее стабильна, чем prefork, т.к. крах потока может привести к краху всего процесса, но работает немного быстрее, потребляя меньше ресурсов. Настраивается эта модель следующими параметрами:

StartServers – задает число запускаемых процессов при старте веб-сервера.
MinSpareThreads – минимальное число потоков, висящих без дела, в каждом процессе.
MaxSpareThreads – максимальное число потоков, висящих без дела, в каждом процессе.
ThreadsPerChild – задает число потоков, запускаемых каждым процессом при старте процесса.
MaxClients – максимальное число параллельно обслуживаемых клиентов. В данном случае задает общее число потоков во всех процессах.
MaxRequestsPerChild – максимальное число запросов, которые обработает процесс, после чего веб-сервер убьет его.

Фронтэнд-бэкэнд

Основная проблема Apache – на каждый запрос выделен отдельный процесс (как минимум – поток), который к тому же увешан различными модулями и потребляет немало ресурсов. Вдобавок, этот процесс будет висеть в памяти до тех пор, пока не отдаст весь контент клиенту. Если у клиента узкий канал, а контент достаточно объемный, то это может занять длительное время. Например, сервер сгенерирует контент за 0,1 сек, а отдавать клиенту его будет 10 сек, все это время занимая системные ресурсы.
Для решения этой проблемы используется архитектура фронтэнд-бэкэнд. Суть ее в том, что запрос клиента приходит на легкий сервер, с архитектурой типа Nginx (фронтэнд), который перенаправляет (проксирует) запрос на тяжелый сервер (бэкэнд). Бэкэнд формирует контент, очень быстро его отдает фронтэнду и освобождает системные ресурсы. Фронтэнд кладет результат работы бэкэнда в свой буфер и может долго и упорно отдавать его (результат) клиенту, потребляя при этом намного меньше ресурсов, чем бэкэнд. Дополнительно фронтэнд может самостоятельно обрабатывать запросы статических файлов (css, js, картинки и т.д.), управлять доступом, проверять авторизацию и т.д.

Настройка связки Nginx (фронтэнд) + Apache (бэкэнд)

Предполагается, что Nginx и Apache у вас уже установлены. Необходимо настроить сервера так, чтобы они слушали разные порты. При этом, если оба сервера установлены на одной машине, бэкэнд лучше вешать только на loopback-интерфейс (127.0.0.1). В Nginx это настраивается директивой listen:

В Apache это настраивается директивой Listen:

Listen 127.0.0.1:81

Далее нужно указать Nginx проксировать запросы на бэкэнд. Это делается директивой proxy_pass 127.0.0.1:81;. Это вся минимальная конфигурация. Однако выше мы говорили, что отдачу статических файлов лучше тоже поручить Nginx. Допустим, что у нас типичный сайт на PHP. Тогда нам нужно проксировать на Apache только запросы к.php файлам, обрабатывая все остальное на Nginx (если ваш сайт использует mod_rewrite, то реврайты тоже можно делать на Nginx, а.htaccess файлы просто выкинуть). Также необходимо учесть, что запрос клиента приходит на Nginx, а запрос к Apache делает уже Nginx, поэтому https-заголовка Host не будет, а адрес клиента (REMOTE_ADDR) Apache определит как 127.0.0.1. Заголовок Host подставить несложно, а вот REMOTE_ADDR Apache определяет сам. Решается эта проблема при помощи mod_rpaf для Apache. Работает он следующим образом: Nginx знает IP клиента и добавляет некий https-заголовок (например X-Real-IP), в который прописывает этот IP. mod_rpaf получает этот заголовок и прописывает его содержимое в переменную REMOTE_ADDR Apache. Таким образом, php-скрипты, выполняемые Apache будут видеть реальный IP клиента.
Теперь конфигурация усложнится. Сначала позаботьтесь, чтобы и в Nginx, и в Apache существовал один и тот же виртуальный хост, с одинаковым корнем. Пример для Nginx:

server {
listen 80;
server_name сайт;
root /var/www/сайт/;
}

Пример для Apache:

ServerName сайт

Теперь задаем настройки для вышеописанной схемы:
Nginx:
server {
listen 80;
server_name сайт;
location / {
root /var/www/сайт/;
index index.php;
}
location ~ \.php($|\/) {
proxy_pass https://127.0.0.1:81;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
}
}

Apache:

# настройки mod_rpaf
RPAFenable On
RPAFproxy_ips 127.0.0.1
RPAFheader X-Real-IP

DocumentRoot "/var/www/сайт/"
ServerName сайт

Регулярное выражение \.php($|\/) описывает две ситуации: запрос к *.php и запрос к *.php/foo/bar. Второй вариант необходим для работы многих CMS..com/index.php (т.к. мы определили index-файл) и также будет проксирован на Apache.

Ускоряемся: gzip_static+yuicompressor

Gzip в Web это хорошо. Текстовые файлы отлично сжимаются, трафик экономится, и контент быстрее доставляется пользователю. Nginx умеет сжимать на лету, так что тут проблем нет. Однако на сжатие файла тратится определенное время, в том числе процессорное. И тут на помощь приходит директива Nginx gzip_static. Суть ее работы в следующем: если при запросе файла Nginx находит файл с таким же именем и дополнительным расширением ".gz", например, style.css и style.css.gz, то вместо того, чтобы сжимать style.css, Nginx прочитает с диска уже сжатый style.css.gz и отдаст его под видом сжатого style.css.
Настройки Nginx будут выглядеть так:

https {
...
gzip_static on;
gzip on;
gzip_comp_level 9;
gzip_types application/x-javascript text/css;
...

Прекрасно, мы один раз будем генерировать.gz файл, чтобы Nginx много раз его отдал. А дополнительно мы будем сжимать css и js при помощи YUI Compressor. Эта утилита максимально минимизирует css и js файлы, удаляя пробелы, сокращая наименования и т.д.
А заставить все это сжиматься автоматически, да еще и обновляться автоматически можно при помощи cron и небольшого скрипта. Пропишите в cron для запуска раз в сутки следующую команду:

/usr/bin/find /var/www -mmin 1500 -iname "*.js" -or -iname "*.css" | xargs -i -n 1 -P 2 packfile.sh

в параметре -P 2 укажите число ядер вашего процессора, не забудьте прописать полный путь к packfile.sh и изменить /var/www на ваш веб-каталог.
В файл packfile.sh пропишите.

Зачем браузеру нужно несколько процессов? Многопроцессная архитектура повышает безопасность и стабильность: если где-то произойдёт сбой, то он не утянет разом за собой всё остальное.

На самом деле приём со множеством процессов уже давно используют другие браузеры, причём значительно более агрессивно, чем Firefox. К примеру, Chrome и все обозреватели на базе Chromium (современная Opera, Яндекс.Браузер и прочие) и вовсе могут показывать в диспетчере задач десятки процессов в памяти, если у вас загружено много вкладок.

В этом есть один серьёзный негативный момент: множество процессов могут сильно нагружать слабенький компьютер, а если вы привыкли работать с большим числом вкладок или у вас установлено много расширений, то «напрячься» может уже и ПК с относительно актуальными характеристиками.

Firefox создаёт меньше процессов, чем Chrome?

Как мы уже сказали, Mozilla подошла к вопросу с несколькими процессами куда более осторожно, чем та же Google.

Изначально разработчики сделали для Firefox лишь один дополнительный процесс, куда выводились плагины (не путать с расширениями), – plugin-container.exe. Таким образом, у Firefox впервые появилось 2 процесса.

Однако время шло и требовало от компании всё же не уступать конкурентам в плане стабильности и безопасности. В итоге в этом году была завершена давно тестировавшаяся полноценная многопроцессная архитектура Firefox.

Преимущество по меньшему потреблению памяти Firefox не теряет, даже если использует свою многопроцессность на максимум (8 CP – 8 процессов для обработки контента)

Часть пользователей стабильных версий Firefox впервые смогли оценить многопроцессность уже этим летом начиная с Firefox 54. Окончательным же этапом здесь стал осенний выход Firefox 57, который больше не поддерживал . Часть из этих расширений прежде могла блокировать многопроцессный режим, заставляя Firefox использовать лишь один процесс.

Впрочем, с процессами у Firefox дела обстоят все равно не так, как у Chrome. Если детище Google запускает в отдельных процессах буквально всё и вся (каждую вкладку, каждое расширение), то Firefox разбивает различные элементы на группы. В итоге процессов получается совсем не так много, как у главного конкурента.

Отсюда заметно меньшее потребление памяти и в некоторых случаях меньшая нагрузка на CPU. Ведь огромное число процессов в Chromium-браузерах может грузить даже не самый слабый процессор. А вот Mozilla в итоге пришла к компромиссному и, на наш взгляд, наиболее разумному решению.

Вдобавок Firefox использует иной механизм вкладок по требованию в отличие от того, что применяется в Chrome и браузерах на основе Chromium.

Если эти веб-обозреватели автоматически последовательно загружают в фоне вкладки с предыдущей сессии, то «огненный лис» делает это лишь при явном обращении (клике) по вкладке, тем самым, не создавая лишних процессов, когда в них нет необходимости. Это также способствует меньшему потреблению ресурсов.

Как уменьшить число процессов Firefox?

В отличие Google, Mozilla практически позволяет пользователю самому регулировать, сколько процессов в памяти использовать браузеру.

Видите, как в диспетчере задач висят несколько процессов firefox.exe (или firefox.exe *32 в случае использования 32-разрядных версий) и хотите их убрать/отключить – не проблема. Откройте настройки, прокрутите вниз раздел «основное», дойдя до подраздела «производительность»:

Если вы снимете флажок с параметра «Использовать рекомендуемые настройки производительности», то перед вами появится настройка числа процессов обработки контента.

На выбор предлагаются варианты от 1 до 7 процессов (если памяти у вас более 8 ГБ, то процессов может предлагаться и больше, чем 7):

На этом моменте стоит сделать несколько важных уточнений.

Во-первых, речь идёт о процессах для обработки контента. Если вы укажете здесь, например, всего 1 процесс, то общее число процессов в памяти уменьшится, однако лишь одну копию firefox.exe вы все равно не получите, т. к. помимо контента Firefox выводит в отдельные процессы ещё и обработку интерфейса.

Во-вторых, уменьшение числа процессов имеет смысл на компьютерах с небольшим объёмом «оперативки» и крайне слабым железом. В свою очередь, на более-менее приемлемом железе многопроцессность не ухудшит производительность, а, наоборот, будет способствовать ей, пусть и ценой увеличенного потребления памяти.

Есть ли выгода от уменьшения числа процессов?

Если говорить о нашем собственном примере, то для ПК с 8 ГБ ОЗУ изначально было предложено 4 процесса по обработке контента. При этом в памяти при открытии большого числа вкладок могло отображаться до 7 процессов.

Когда мы установили число процессов контента равным 1, перезапустили браузер и заново прокликали по всем вкладкам, чтобы они загрузились, в памяти предсказуемо осталось только 4 процесса.

Из них 3 предназначены для самого браузера и 1 процесс как раз для обработки контента, причём последний легко отличить, т. к. при открытии приличного числа вкладок он начинает забирать себе памяти значительно больше остальных:

В Firefox при этом у нас было открыто 15 различных сайтов. В изначальном режиме (7 процессов) суммарное потребление памяти составило около 1,5 ГБ. Когда же процессов осталось лишь четыре, то в сумме они забирали около 1,4 ГБ (см. скриншоты выше).

Мы повторяли эксперимент несколько раз, каждый из них «выигрыш» оперативной памяти составлял всего 100-150 МБ. При этом стоит учитывать, что производительность браузера от перехода на 1 процесс для контента могла быть снижена. Таким образом, смысл уменьшения числа процессов, как видите, весьма невелик.

Несколько часов назад вышла 48 версия браузера Mozilla Firefox. Относительно предыдущей, 47 версии в ней есть не только то, что можно описать как «мелкие изменения, которые кроются под капотом». Впервые официально в релизной версии Firefox начинает появляться многопроцессность, которая у части пользователей включена по умолчанию.

Electrolysis

Для современного браузера многопроцессность - это признак хорошего тона. Все браузеры обладают вкладками, а каждая из вкладок в многопоточном режиме является отдельным изолированным процессом. Достоинства такого подхода - не только в дополнительных мерах безопасности и исключении ряда атак. В отдельные процессы можно уводить вкладки, дополнения и расширения, к примеру, Adobe Flash Player. Если один из процессов завершится с ошибкой, работу можно продолжить без перезапуска всего браузера. Исключаются разнообразные утечки памяти, растёт производительность за счёт распараллеливания задач нескольким ядрам процессора. Если одна из вкладок потребляет много ресурсов, интерфейс не повиснет, а продолжит отзываться.

Многопроцессностью обладают почти все популярные браузеры: Google Chrome, Internet Explorer, Microsoft Edge, Apple Safari. Mozilla Firefox догоняет их. Electrolysis или e10s - это технология многопоточного режима в Firefox. В первых версиях процессов два: один для браузерных вкладок, второй для интерфейса. В следующих версиях процессов на контент будет несколько.

В 48 версии Electrolysis впервые включают в релизной версии. Но не у всех, а только у одного процента пользователей. Если в Mozilla будут довольны результатами теста, то за десять дней долю поднимут до приблизительно половины пользователей.

Многопроцессность можно включить самостоятельного. Чтобы убедиться, какая версия попалась, достаточно набрать в адресной строке about:support и поискать строчку Multiprocess Windows.

Не все расширения совместимы с Electrolysis. Можно посмотреть списки самых популярных дополнений на сайте Are We e10s Yet , где указан их статус совместимости в режиме многопоточного Firefox. Можно сразу включить Electrolysis и выключить его позже, если важные дополнения ломаются.

Нужный параметр в about:config (ввести в адресную строку и нажать «Ввод») - browser.tabs.remote.autostart . Значение параметра нужно установить на true двойным щелчком.

После перезапуска браузера Electrolysis может заработать. Иногда его включению будет мешать какое-то дополенение.

Чтобы обойти это ограничение, создайте в about:config новую булеву постоянную browser.tabs.remote.force-enable и присвойте ей значение true .

Теперь Electrolysis заработает в принудительном режиме многопроцессности. (Обратите внимание, что подобное может отразиться на производительности некоторых дополнений.) В about:support напротив Multiprocess Windows появится 1/1 (Enabled by user).

Обязательность подписи расширений

Electrolysis можно включить или отключить через about:config . А вот способа отключить обязательность подписи устанавливаемого расширения больше нет. Опция исчезла, как и было задумано.

В итоге обязательные неотключаемые подписи появились только в текущей, 48 версии. Электронную подпись расширения получают на addons.mozilla.org (AMO) вне зависимости, будет ли расширение опубликовано на AMO или нет. Цель требования получать обязательную подпись на AMO - безопасность пользователей. Система фильтрует вредоносные расширения в режиме чёрного списка.

Прочие изменения

В Firefox 49 исчезла поддержка Android 2.3 (Gingerbread), версий OS X 10.6 (Snow Leopard), 10.7 (Lion) и 10.8 (Mountain Lion). Эти операционные системы вышли 4-6 лет назад.

Что дальше?

Firefox Hello - это инструмент для сотрудничества и общения в формате аудио- и видеочата, созданный на технологии WebRTC. Сервис встроен в Firefox с 34 версии. В 49 версии Hello может исчезнуть. На баг-трекере обсуждается удаление Hello из браузера уже в следующей версии. Причина удаления - смена приоритетов разработки. В ночной сборке Nightly 51 и ранней версии Aurora 50 сервис Hello уже исчез. На момент написания поста Beta 49 пока недоступна.

Ранее из Firefox удалили темы оформления и группы вкладок из-за малоиспользуемости. Поддержка малопопулярных функций замедляла выпуск новых версий. Возможно, Hello хотят убрать по той же причине.

Firefox продолжит избавляться от поддержки старых систем. В 49 версии набор инструкций центрального процессора SSE2 будет обязательным для работы Firefox под Windows. Речь идёт об отказе от процессоров до эпохи Pentium 4 и Ahtlon 64.

Вообще, если вы можете не поднимать Apache , не делайте этого. Задумайтесь, может ли нужные вам задачи выполнять lighttpd или thttpd . Эти веб-серверы могут оказаться весьма кстати в ситуациях, где системных ресурсов на всех не хватает, а работать должно. Ещё раз повторюсь: речь идёт о тех ситуациях, когда функциональности этих продуктов будет достаточно для выполнения поставленных задач (кстати, lighttpd умеет работать с PHP ). В тех ситуациях, где без Apache ну просто никак не обойтись, всё равно обычно можно освободить немало системных ресурсов, перенаправив запросы к статическому контенту (JavaScript, графика) от Apache к легковесному HTTP-серверу. Наибольшей проблемой Apache является его большой аппетит к оперативной памяти. В этой статье я рассмотрю методы, помогающие ускорить работу и снизить объёмы занимаемой им памяти:

обработке меньшего числа параллельных запросов;

циркуляция процессов;

использование не слишком «долгих» KeepAlive;

уменьшение таймаута;

уменьшение интенсивности логирования;

отключение разрешения имён хостов;

отключение использования .htaccess .

Загрузка меньшего количества модулей

Первым делом необходимо избавиться загрузки от ненужных модулей. Просмотрите конфиг-файлы и определите, какие модули у вас загружаются. Все ли загружаемые модули вам нужны? Найдите то, что не используется и отключите нафиг, этим вы сэкономите какое-то количество памяти.

Обработка меньшего числа параллельных запросов

Чем большему количеству процессов Apache разрешено запускаться одновременно, тем больше одновременных запросов он сможет обработать. Увеличивая это число, вы тем самым увеличиваете и объём памяти, отдаваемой под Apache . Воспользовавшись top, можно увидеть, что каждый процесс Apache занимает совсем немножко памяти, поскольку используются разделяемые библиотеки. В Debian 5 с Apache 2 по умолчанию используется такая конфигурация:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 20 MaxRequestsPerChild 0

Директива StartServers определяет количество процессов сервера, запускаемых изначально, сразу после его старта. Директивы MinSpareServers и MaxSpareServers определяют минимальное и максимальное количество дочерних «запасных» процессов Apache . Такие процессы находятся в состоянии ожидания входящих запросов и не выгружаются, что даёт возможность ускорить реакцию сервера на новые запросы. Директива MaxClients определяет максимальное количество параллельных запросов, одновременно обрабатываемых сервером. Когда количество одновременных соединений превысит это количество, новые соединения будут поставлены в очередь на обработку. Фактически, директива MaxClients и определяет максимально-допустимое число дочерних процессов Apache ,запущенных одновременно. Директива MaxRequestsPerChild определяет количество запросов, которое должен обработать дочерний процесс Apache , прежде чем завершить своё существование. Если значение этой директивы установлено равным нулю, то процесс не будет «истекать».

Для своего домашнего сервера, с соответствующими нуждами, я исправил конфигурацию на следующую:

StartServers 1 MinSpareServers 1 MaxSpareServers 1 MaxClients 5 MaxRequestsPerChild 300

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

Циркуляция процессов

Как можно было заметить, я изменил значение директивы MaxRequestsPerChild . Ограничив таким образом время жизни дочерних процессов количеством обработанных запросов, можно избежать случайных утечек памяти, вызванных криво-написанными скриптами.

Использование не слишком «долгих» KeepAlive

KeepAlive — это метод поддержки постоянного соединения между клиентом и сервером. Изначально протокол HTTP разрабатывался как не ориентированный на постоянные соединения. То есть, когда веб-страница отправляется клиенту, все её части (картинки, фреймы, JavaScript) передаются с использованием различных, отдельно устанавливаемых соединений. С появлением KeepAlive , у браузеров появилась возможность запрашивать постоянное соединение и, установив его, загружать данные, используя одно установленное соединение. Такой способ даёт неслабый прирост производительности. Однако Apache по умолчанию использует слишком большой таймаут перед закрытием соединения, равный 15-ти секундам. Это значит, что после того, как был отдан весь контент клиенту, запросившему KeepAlive , дочерний процесс ещё 15 секунд будет находиться в ожидании входящих запросов. Многовато, однако. Лучше уменьшить этот таймаут до 2-3 секунд.

KeepAliveTimeout 2

Уменьшение таймаута

Как вариант, можно уменьшить значение директивы TimeOut , которая определяет время ожидания завершения отдельных запросов. По умолчанию её значение равно 300 , быть может, в вашем случае будет иметь смысл это значение уменьшить/увеличить. Я лично пока оставил как есть.

Уменьшение интенсивности логирования

На пути к увеличению производительности сервера можно попробовать снизить интенсивность ведения протоколов. Модули, такие как mod_rewrite , могут писать в лог отладочную информацию, и если она вам не нужна — отключайте её вывод.

Отключение разрешения имён хостов

На мой взгляд, нет никакой необходимости в том, чтобы выполнять обратное преобразование IP-адресов в имена хостов. Если они уж так сильно вам необходимы при анализе логов, то можно определять их на стадии анализа, а не в процессе работы сервера. За разрешение имён хостов отвечает директива HostnameLookups , которая, вообще-то, по умолчанию и установлена в Off , однако проверьте это, если действительно считаете необходимым отключить преобразование.

HostnameLookups Off

Отключение использования.htaccess

Обработка файлов .htaccess выполняется Apache каждый раз при запросе данных. Мало того, что Apache должен загрузить этот файл, так ещё немало времени и ресурсов уходит на его обработку. Взгляните на ваш веб-сервер и пересмотрите необходимость в использовании файлов .htaccess . Если вам нужны различные настройки для разных каталогов, может быть реально будет их вынести в основной файл конфигурации сервера? А отключить обработку .htaccess можно директивой в конфигурации сервера.