После последнего апгрейда ОС на нашем VPS стало возможным провести изменения для улучшения производительности (это сейчас наглядно видно по ускорившейся реакции сайта). Ничего экстраординарного не предпринято (сведения прямо скажем тот ещё баян), но по умолчанию юникс-системы не используют этих настроек, поэтому я думаю полученный в процессе нашей возни с drupal.ru опыт может быть интересен хостящимся на VPS и выделенных серверах на Linux (впрочем большей частью рекомендации будут применимо и к другим юниксам).

Собственно, идея проста - если после MySQL и PHP со всеми кешами осталась свободная память - надо её задействовать. В линуксе впрочем память не простаивает, всё что свободно - отдаётся под файловый кеш, что здорово помогает ускорить работу системы. Но в ряде случаев это стоит указать явно, размещая часть файловых систем в памяти, ведь различных временных быстроменяющихся данных в работе PHP, MySQL и других компонентов набегает немало. Здесь в помощь приходят memcache и файловые системы в памяти, такие как tmpfs. А также разумеется сначала стоит смотреть в настройки каждой программы - например в MySQL много опций, позволяющих оптимизировать работу с памятью. Но мы ниже рассмотрим внешнюю сторону - работу файловой системы.

Традиционно временные файлы в юниксе принято сохранять в /tmp (а также в /var/tmp), но это не единственные места где программы могут захотеть создать свои временные файлы. Однако /tmp наиболее популярное место, поэтому стоит вынести его в память и быть уверенным, что операции со временными файлами будут происходить быстрее (при условии, что памяти на это достаточно).

Здесь мы монтируем фс в памяти поверх уже рабочей /tmp - новые файлы будут создаваться в tmpfs (которую мы ограничили размером 1Г), а уже используемые другими процессами файлы - останутся на диске. Конечно можно размонтировать /tmp и после смонтировать на неё tmpfs, но на работающей машине это не всегда просто, т.к. процессы вроде mysql могут держать открытые файлы в /tmp, а останавливать ту же mysql может быть недопустимо. Подробнее о возможностях и реализации tmpfs можно процесть например в этой статье. Удобство tmpfs в том, что отведённая под раздел память расходуется не сразу после монтирования, а выделяется по мере реального использования. Максимального размера в 1Гб достаточно для большинства применений (можно 2-3Гб если памяти девать некуда). Что кроме /tmp? На сервере drupal.ru в tmpfs были также добавлены /var/run, /var/lock (файлы в обеих местах мелкие, экономия честно говоря на копейки, ну так для общности) и /var/spool/mail. Последняя папка используется для хранения почты мейлсервером и не во всех конфигурациях стоит выносить её в память, т.к. после перезагрузки машины содержимое будет потеряно. Но для drupal.ru, где почта используется только для рассылки уведомлений с сайта и письма хранятся в спуле короткое время - это приемлемо.

MySQL старых версий предпочитал сохранять временные таблицы в тех же директориях, где лежат базы данных. Последние версии насколько я вижу по умолчанию используют /tmp, однако можно явно сказать MySQL об этом, прописав в конфиге my.cnf опции:

Проверить, какие переменные куда смотрят можно запросом к mysql:

Для проверки можно повыбирать данные запросами с GROUP BY + ORDER BY, гарантированно создающим временные таблицы на диске и с помощью

убедиться, что временные файлы создаются в /tmp. В MySQL до 5.0.48 был баг с выставлением TMPDIR, чтобы использовать TMPDIR отличный от дефолтного следует использовать более свежую версию MySQL (мы решили это кардинально, апгрейдом пакетов Fedora с 7 до 10). Отдельно стоит отметить, что в конфиге MySQL есть настройки регулирующие размер памяти под временные таблицы, чтобы избежать их создания на диске. Но всё равно, таблицы превышающие заданный в конфиге лимит будут создаваться на файловой системе и тут можно подстраховаться с другой стороны - разместив фс в памяти. Также запросы содержащие поля BLOB и *TEXT всегда создают временные таблицы на диске.

Отдельно замечу, что не стоит выносить в память /var/tmp, т.к. эта директория чаще используется для хранения кешей программ, которые могут быть актуальны даже после перезагрузки сервера (чего не скажешь о /tmp, в котором не принято хранить данные, критичные к перезагрузке).

На drupal.ru для управления кешем используется модуль cacherouter и по мере донастройки сервера кеши пробовали размещать в разные места. VPS на Мастерхосте всем хорош, кроме скорости работы файловой системы, поэтому варианты файловых кешей в нашем случае оказались очень неэффективны. Уже давно для кеширования на сайте применяется memcached, на текущий момент поднято 4 демона memcached с лимитами памяти по 128-256Мб на разных портах и разные таблицы кешей в друпале настроены на свои экземпляры memcached (идея by Andypost), также разные сайты (на аккаунте сейчас размещены ещё ubercart.ru, drupalcon.ru, web-cron.ru) используют разные экземпляры. Дополнительно используется кеш в eaccelerator и для эксперимента в cacherouter все кеши сайта ubercart.ru вынесены на файловую система на tmpfs.

Проблемой, с которой пришлось столкнуться через сутки работы после массового задействования tmpfs стал недостаток shared memory - на сайте отвалились блоки (проблемы кеша) и на сервер стало невозможно попасть даже по ssh. Выручила только панель управления аккаунтом VPS, где обнаружился ценный пункт со списком процессов и кнопкой kill. Убиение части процессов позволило вернуть ресурсы в норму и зайти на сервер. На выделенном сервере это не станет проблемой (машина со сходной загрузкой работает с массовым использованием tmpfs стабильно), но на VPS лимиты на разные ресурсы могут быть жёстко ограничены. Следует смотреть данные в панели управления, а также:

отражающий данные по текущему использованию различных ресурсов системы и максимальным лимитам на них (совет by Gor). См. последний столбец в этой таблице - если он не нулевой, то у вас проблемы. В нашем случае лимит на shmpages был исчерпан и сервер приостановил выдачу shared memory процессам. Аппетиты по размерам tmpfs и памяти задействованной под eaccelerator пришлось поубавить (eacceleratorу выделено в итоге 128Мб), но в результате сайты работают стабильно и заметно быстрей.

Ещё раз хочу поблагодарить Andypost за апгрейд системы и Gor за советы по настройке VPS!

В тему: статья по начальной настройке VPS на Masterhost