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

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

Сначала решил попробовать httperf от HP, но нагрузка, которую он создаёт, слишком далека от реальной (вероятно, можно что-то сделать, чтобы приблизить условия к боевым, но сходу ничего не придумалось).

Решил сделать свой небольшой стресс-тест:

#!/bin/sh
COUNT=5
for site in $@; do
  for num in `seq $COUNT`; do
    out=`mktemp -d -p .`
    wget --append-output=log --no-verbose --mirror -P $out $site &
  done
done

Этот скрипт на каждый URL, переданный ему в качестве параметра, создаёт COUNT Wget’ов, рекурсивно выкачивающих сайт. Никакой статистики скрипт не отдаёт, но можно в живую понаблюдать за расходом памяти, например, при помощи htop.

На моём сервере крутится архив переводов (два экземпляра), этот блог и несколько редко используемых legacy PHP скриптов. На всё это отводится 294 Mb.

Для тестирования я передавал скрипту 3 URL’а: архив, блог и один из PHP скриптов. Итого 15 Wget’ов. Помимо этого я периодически при помощи Firefox’а проверял, откликается ли сервер.

Итак, что же показал тест? При работе Apache через 5 минут свободная память заканчивалась, и начинал расти своп. На запросы сервер отвечал, но иногда с огромной задержкой. В том случае, если в качестве сервера выступал lighty, максимум, которого мне удалось достичь — это 142 Mb.

В общем, ничего удивительного. Насколько я понимаю, высокое потребление памяти
mod_python — это общеизвестный факт. И, наверняка, есть масса способов уменьшить потребление памяти в Apache. С другой стороны, мне нужно лишь небольшое подмножество функций Apache, так что переход на lighttpd — это неплохо: там и конфигурация чуть более очевидная, и ресурсов ему нужно меньше, и со статикой он работает лучше.