http://iakov.davydov.name/blog/tag/apache/Iakov Davydov blog blog posts with tag intersection apache2008-12-28T01:00:20ZIakovdjango-atompubhttp://iakov.davydov.name/blog/2008/12/28/stress-test/Стресс-тест2008-12-28T01:00:20Z2008-12-28T00:19:32Z<p>Напомню, что недавно я столкнулся с тем, что в какой-то момент сервер затыкался и переставал отдавать данные наружу. Перезагрузка <a href="http://httpd.apache.org/">Apache</a>, как правило, помогала.
</p>
<p>Мои наблюдения показали, что дело было в расходе оперативной памяти. <a href="http://iakov.davydov.name/blog/2008/12/27/lighttpd/">Постфактум</a> я попытался удостовериться, что правильно диагностировал проблему.
</p>
<p>Сначала решил попробовать <a href="http://www.hpl.hp.com/research/linux/httperf/">httperf</a> от <a href="http://hp.com"><span class="caps">HP</span></a>, но нагрузка, которую он создаёт, слишком далека от реальной (вероятно, можно что-то сделать, чтобы приблизить условия к боевым, но сходу ничего не придумалось).
</p>
<p>Решил сделать свой небольшой стресс-тест:
</p>
<pre><code>#!/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 <span class="amp">&</span>
done
done
</code></pre><p>Этот скрипт на каждый <span class="caps">URL</span>, переданный ему в качестве параметра, создаёт <code>COUNT</code> <a href="http://www.gnu.org/software/wget/">Wget’ов</a>, рекурсивно выкачивающих сайт. Никакой статистики скрипт не отдаёт, но можно в живую понаблюдать за расходом памяти, например, при помощи <a href="http://htop.sourceforge.net/">htop</a>.
</p>
<p>На моём сервере крутится <a href="http://www.xkcd.ru">архив переводов</a> (два экземпляра), этот блог и несколько редко используемых legacy <a href="http://php.net"><span class="caps">PHP</span></a> скриптов. На всё это отводится 294 Mb.
</p>
<p>Для тестирования я передавал скрипту 3 <span class="caps">URL</span>’а: архив, блог и один из <span class="caps">PHP</span> скриптов. Итого 15 Wget’ов. Помимо этого я периодически при помощи <a href="http://mozilla.org">Firefox’а</a> проверял, откликается ли сервер.
</p>
<p>Итак, что же показал тест? При работе Apache через 5 минут свободная память заканчивалась, и начинал расти своп. На запросы сервер отвечал, но иногда с огромной задержкой. В том случае, если в качестве сервера выступал <a href="http://lighttpd.net">lighty</a>, максимум, которого мне удалось достичь — это 142 Mb.
</p>
<p>В общем, ничего удивительного. Насколько я понимаю, высокое потребление памяти<br />
<a href="http://www.modpython.org/">mod_python</a> — это общеизвестный факт. И, наверняка, есть масса способов уменьшить потребление памяти в Apache. С другой стороны, мне нужно лишь небольшое подмножество функций Apache, так что переход на lighttpd — это неплохо: там и конфигурация чуть более очевидная, и ресурсов ему нужно меньше, и со статикой он работает лучше.
</p>http://iakov.davydov.name/blog/2008/12/27/lighttpd/lighttpd2008-12-27T18:40:22Z2008-12-27T18:28:28Z<p>За некоторое время <a href="http://mysql.com">MySQL</a> и <a href="http://httpd.apache.org/">Apache 2</a> съедали всю доступную память. Решил вопрос радикально: установил <a href="http://www.lighttpd.net/">lighttpd</a> с <a href="http://www.fastcgi.com/drupal/">FastCGI</a>.
</p>
<p>Потребление памяти радикально уменьшилось. Посмотрим, что будет под нагрузкой. В <a href="http://hostingfu.com/article/nginx-vs-lighttpd-for-a-small-vps">статье</a> пишут, что lighty течёт.
</p>
<p>Документация по настройке <a href="http://djangoproject.com">django</a>+lighttpd есть, но она не подробная и не актуальная.
</p>
<p>mod_rewrite у lighttpd не так крут, но мне его хватило.
</p>http://iakov.davydov.name/blog/2008/10/07/archive-update/Обновление архива2008-10-07T19:56:55Z2008-10-07T19:26:29Z<p>Сегодня был свободный час, так что я обновил <a href="http://xkcd.myths.ru">архив переводов xkcd</a>.
</p>
<p>Список изменений:
</p>
<ul>
<li>
По умолчанию теперь показывается последний переведённый комикс.
</li>
<li>
Как побочный эффект, теперь записи в <span class="caps">RSS</span> сортирются по дате публикации. Вероятно, пользователи некоторых <span class="caps">RSS</span>-читалок это заметят.
</li>
<li>
Кстати, <span class="caps">RSS</span> фид теперь указывает на <a href="http://xkcd.myths.ru">правильный адрес архива</a>.
</li>
<li>
Убрана дурацкая <a href="http://ru.wikipedia.org/wiki/xkcd">ссылка на википедию</a> из меню навигации.
</li>
<li>
Теперь старые ссылки на неопубликованные переводы (вида <code>http://xkcd.myths.ru/777/1223398281/</code>) продолжают работать после публикации перевода.
</li>
</ul>
<p>Время простоя, как всегда, маленькое. На этот раз несколько секунд (с момента изменения таблицы до перезапуска Apache).
</p>