Оптимизация drupal.ru на VPS Masterhost - обзор последних изменений

Главные вкладки

Аватар пользователя axel axel 14 марта 2009 в 2:20

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

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

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

# mount -t tmpfs -o size=1024M tmpfs /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 опции:

tmpdir=/tmp/

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

SHOW VARIABLES LIKE '%TMP%';

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

# lsof /tmp | grep mysql

убедиться, что временные файлы создаются в /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 лимиты на разные ресурсы могут быть жёстко ограничены. Следует смотреть данные в панели управления, а также:

# cat /proc/user_beancounters

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

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

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

Комментарии

Аватар пользователя axel axel 14 марта 2009 в 13:10

VladSavitsky wrote:
C удовольствием почитал.
А разве друпал.ру рассылает уведомления по почте? Я ничего не получаю.

Во всяком случае сообщения при запросе нового пароля шлёт, а вот насчёт subscriptions это надо смотреть. Но мейлсервер работает исправно.

Аватар пользователя Sky Cat Sky Cat 15 марта 2009 в 1:16

axel, скажите пожалуйста, сколько VPS используется для сайта drupal.ru и сколько памяти на каждой VPS?
Просто ваши данные:
# mount -t tmpfs -o size=1024M tmpfs /tmp
>> Уже давно для кеширования на сайте применяется memcached, на текущий момент поднято 4 демона memcached с лимитами памяти по 128-256Мб на разных портах

не очень-то соотносятся с параметрами тарифных планов компании .masterhost. На самом большом тарифе оперативной памяти всего 1024mb.

Аватар пользователя axel axel 15 марта 2009 в 2:58

Sky Cat wrote:
axel, скажите пожалуйста, сколько VPS используется для сайта drupal.ru и сколько памяти на каждой VPS?
Просто ваши данные:
# mount -t tmpfs -o size=1024M tmpfs /tmp
>> Уже давно для кеширования на сайте применяется memcached, на текущий момент поднято 4 демона memcached с лимитами памяти по 128-256Мб на разных портах

не очень-то соотносятся с параметрами тарифных планов компании .masterhost. На самом большом тарифе оперативной памяти всего 1024mb.

Используется один аккаунт на все сайты, тариф Pro если правильно помню. В top видно вообще 16Гб памяти и 8 ядер. Но минимально гарантируемый размер памяти на тарифе - 1Гб. Лучше подробности по ресурсам уточнить у Акжана, он здесь представляет Мастерхост. Настройки tmpfs ещё будем уточнять. Максимальный лимит в tmpfs можно задать превышающим общий размер вирт. памяти, а можно вообще не указывать - память под файлы выделяется при необходимости.

Аватар пользователя Akzhan Akzhan 15 марта 2009 в 12:28

Тариф VPS Pro, просто налицо использование памяти выше гарантированного минимума.

Тут главное - обеспечить работоспособность сайта и в случае, когда система будет готова выделить именно 1Gb.

Аватар пользователя Sky Cat Sky Cat 15 марта 2009 в 20:01

Просто с настройками, указанными выше, VPS просто будет ресурсы выбирать подчистую и Virtuozo начнет процессы убивать. Вот мне и непонятно, как это так:
>>Тариф VPS Pro, просто налицо использование памяти выше гарантированного минимума.
У меня по тарифу выделено 768 мегабайт оперативной памяти. И если я начинаю этот лимит превышать, виртуозо начинает убивать процессы из-за нехватки оперативки. В панели управления это выглядит как черная зона системных ресурсов.

И что будет, если я для tmpfs выделю 1000 мегабайт оперативки? Скорее всего, через некоторое время я вылечу в черную зону и придется убивать процессы.

Аватар пользователя axel axel 15 марта 2009 в 22:01

Просто пока ещё мы её недоиспользуем. Но после первого варианта настройки лимиты превысили - по shmpages и вышли в эту чёрную зону. Также одно время вылезали по лимитам othersockbuf, когда слишком активно использовали сокеты. Пока просто отслеживаю, насколько заполнились кеши - потом по результатам подкорректируем настройки (и обновим статью). В статье рекомендации получились скорее для выделенного сервера (на сервере с 12Гб например /tmp в памяти и лимит под него 2Гб - для распаковки всяких архивов и пр. операций), на drupal.ru сейчас 512Мб.

Аватар пользователя Demimurych Demimurych 15 марта 2009 в 15:38

А какие использовали параметры кеширования mysql ?

проводили ли сравнения, что лучше отдать лишнюю память под кеш, или все таким под tmpfs ?

Мои глупые эксперименты вроде увеличил там посмотрел на глаз, увеличил там, посомтрел на глаз показал что выгоднее лишнее отдать под кеш самого mysql

Конечно я не учитываю многих обстоятельств, от того и интересуюсь проводили ли исследования или где то читали про то что лучше.

Аватар пользователя axel axel 15 марта 2009 в 18:06

Demimurych wrote:
А какие использовали параметры кеширования mysql ?

проводили ли сравнения, что лучше отдать лишнюю память под кеш, или все таким под tmpfs ?

Мои глупые эксперименты вроде увеличил там посмотрел на глаз, увеличил там, посомтрел на глаз показал что выгоднее лишнее отдать под кеш самого mysql

Конечно я не учитываю многих обстоятельств, от того и интересуюсь проводили ли исследования или где то читали про то что лучше.

Исследования продолжаются Smile Уверен это не последний вариант настроек - посещаемость сайта постепенно растёт, при этом интересно сохранить его скорость не добавляя железных ресурсов. Хотя наш подход тоже нельзя назвать системным (даже честно признаюсь - это просто метод научного тыка Wink - в идеале нужно взять отдельный VPS, ставить тестовый сайт в разных конфигурациях и нагружать искусственными тестами. На живом drupal.ru особенно не попрактикуешся - и так во время апгрейда полдня сайт лежал и в течение двух последующих дней случались перебои. Поэтому так на глазок смотрим заполняемость кешей и отношения хитов к пропускам (где их можно посмотреть). MySQL настраивалась по рекомендациям скрипта tuning-primer.sh с http://www.day32.com/MySQL/ и разным умным рекомендациям, которые кто-нибудь где-нибудь услышал. Последние нововведения с /tmp задумывались не только под mysql - для любых программ операции с временными файлами в памяти имеют больше преимуществ. Нет смысла сбрасывать файловый кеш на диск для файла живущего несколько минут или десятки минут.

У меня нет однозначных данных, что эффективнее - настройки mysql под более полное использование памяти или возможность писать свои временные файлы в память. Вероятно для mysql эффективнее первое, но второй вариант с tmpfs - своего рода защита от некорректных настроек. К примеру, мне не удалось настройками mysql добиться снижения процента временных таблиц записываемых на диск ниже 30%, даже значительно увеличивая tmp_table_size и max_heap_table_size. В итоге mysql была настроена так, чтобы укладываться в потребление памяти в 1Gb (что в случае нашего vps и то получается с превышением минимально гарантируемой памяти), tmpfs удобнее тем, что можно ускорить работу всех программ использующих временные файлы - скажем закачки файлов в PHP и пр.

Аватар пользователя Sky Cat Sky Cat 15 марта 2009 в 20:10

Скажите пожалуйста, какая сейчас примерная суточная посещаемость сайта drupal.ru? Если это не секрет, конечно.

Аватар пользователя axel axel 15 марта 2009 в 22:07

График Google Analytics последние дни между 7..8 тыс. хостов в сутки. По выходным - 3..4 тыс. Остальные сайты аккаунта суммарно в пределах 500 хостов в сутки максимум, в общем не в счёт.

Поправка: вообще у них там visitors, а не хосты, черт знает, что это значит по версии гугла. Pageviews - 25-27 тыс. По спайлогу статистика по хостам меньше - где-то 5 тыс. в сутки.

Аватар пользователя Raven2000 Raven2000 24 марта 2009 в 0:10

eaccelerator это конечно хорошо, но и мусю тоже надо поюзать для производительности
MYSQL
[mysqld]
# Включам кеш запросов в мусю в зависимости от кол-во запросов
query_cache_size=64M
# Индификация ресурсоемких запросов (для обдумывания если не нужно закоментим)
long_query_time = 5
log-slow-queries = /var/log/mysql/slow.log

# mkdir -p /var/log/mysql; touch /var/log/mysql/slow.log; chown mysql:mysql /var/log/mysql/slow.log

смотрим (к примеру)
mysql> show variables like 'query_cache%';
+------------------------------+----------+
| Variable_name | Value |
+------------------------------+----------+
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 16777216 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+----------+
5 rows in set (0.00 sec)
+ соответственно юзать FastCGI и поставить nginx на фронт
Работа в разы улучшится.

Аватар пользователя axel axel 25 марта 2009 в 14:28

Raven2000 wrote:
eaccelerator это конечно хорошо, но и мусю тоже надо поюзать для производительности
MYSQL
[mysqld]
# Включам кеш запросов в мусю в зависимости от кол-во запросов
query_cache_size=64M
# Индификация ресурсоемких запросов (для обдумывания если не нужно закоментим)
long_query_time = 5
log-slow-queries = /var/log/mysql/slow.log
drupal.ru так и работает, на nginx+fastcgi. mysql разумеется подстраивали и кеш запросов включён. Со slow запросами проблем пока нет.

Аватар пользователя Raven2000 Raven2000 31 марта 2009 в 21:05

axel wrote:
drupal.ru так и работает, на nginx+fastcgi. mysql разумеется подстраивали и кеш запросов включён. Со slow запросами проблем пока нет.[/quote]
Так указал бы для людей чтобы они развивались. Smile
Я тут пишу статью как на FreeBSD это все развесить и размусолю конфиги думаю для всех будет интерестно например как точно настроить акселератор и какие есть и тп.
+ помимо этого укажу еще пару бонусов.

Аватар пользователя Valeratal Valeratal 25 марта 2009 в 14:55

visitors
это посетители, но по сессиям, насколько я помню
То есть если я зашел на друпал ру с одного IP утром и вечером, то посчитаюсь 2 раза

Аватар пользователя Konstantin_by@drupal.org Konstantin_by@d... 9 декабря 2009 в 4:39

А может кто опишет как поднять сервер с дефолтного тарифа мастерхоста с Fedora7 до самой последней настройки?
Такого еще никто не делал но это в интересах мастерхоста