The WebDevil » nginx

LVM Rocks

dm — Sat, 28 Feb 2009 23:18:18 +0000

Давно заметил что в Ubuntu (server edition) во время инсталляции начали предлагать использовать LVM. Но я все не решался поставить production на него. Затем пообщался со теми кто его использовал, почитал доку – и последний год стал его использовать, так как постиг скрытую в нем мощь

Допустим, у нас есть простенький бюджетный сервер. Мы развернули новое приложение, и его база стала расти весьма стремительно. Итого – база, веб-файлы и система живут на одном физическом диске.

Был куплен диск WD Razor, и на него перенесли базу. Нагрузка диска (iostat -x -m 1) составила 1-2%. Решено перенести туда же и веб-файлы, однако решение это пришло лишь через пару дней. Так что получилось наглядно продемонстрировать возможности LVM.

Part1. Creating…

Когда поставили разор на нем создали один раздел – LVM:

# fdisk -l

Disk /dev/sdb: 74.3 GB, 74355769344 bytes
255 heads, 63 sectors/track, 9039 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 1 9039 72605736 8e Linux LVM

Пару слов об организации LVM.
Уровень 1: volume group (vg). Это наивысший уровень абстракции, объединяющий в себе logical volumes и physical volumes.
Уровень 2: physical volume (pv). Это некое блочное устройство, способное хранить данные (HDD, RAID, …)
Уровень 3: logical volume (lv). Это эквивалент раздела на жестком диске.

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

Итак, сначала создавался pv:

pvcreate /dev/sdb1

Затем vg:

vgcreate sys_vg /dev/sdb1

И затем на все свободное место указанного pv (/dev/sdb1) создали lv с именем var_lib_mysql:

lvcreate -L 100%PVS -nvar_lib_mysql sys_vg /dev/sdb1

Дело за малым:

mkreiserfs /dev/mapper/sys_vg-var_lib_mysql
mount /dev/mapper/sys_vg-var_lib_mysql /mnt
/etc/init.d/mysql stop
mv /var/lib/mysql/* /mnt/
mv /var/lib/mysql/.* /mnt/
umount /mnt
mount /dev/mapper/sys_vg-var_lib_mysql /var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
/etc/init.d/mysql start

Вот собственно и почти все. Последний штрих – прописать монтирование раздела в fstab, дабы это происходило при загрузке автоматом. Можно скучно сделать это через blkid, увидеть там нужный UUID (например, f6946e54-c7d6-4688-8fac-05dcb1bf9973), скопировать его, открыть /etc/fstab и вставить туда строку вида:

UUID=f6946e54-c7d6-4688-8fac-05dcb1bf9973 /var/lib/mysql reiserfs defaults 0 2

а можно сделать так:

printf "\nUUID=`blkid | grep sys_vg-var_lib_mysql | sed -r 's/.*UUID="([^"]*).*/\1/i'`\t/var/lib/mysql reiserfs defaults 0 2\n" >> /etc/fstab

Да, если сделать umount /var/lib/mysql && mount /var/lib/mysql до ребута – то /dev/disk/by-uuid/f6946e54-c7d6-4688-8fac-05dcb1bf9973 (или какой там получится) там еще не будет. Для того чтоб появился до ребута надо перезапустить udev:

/etc/init.d/udev restart

Part2. Resizing…

Как я говорил раньше, с опозданием пришла мысль о том, что неплохо бы вынести и статические файлы на этот же винт. И сделать это совсем просто! Для этого от того lv что был создан раньше (и именуется var_lib_mysql) откусим немного места.

Сначала остановим все службы (говорят, reiserfs увеличивается/уменьшается без проблем налету, но я этого пока не пробовал на себе):

/etc/init.d/mysql stop
umount /var/lib/mysql

Затем уменьшим файловую систему, а затем и lv на 20ГБ:

resize_reiserfs -s-20G /dev/mapper/sys_vg-var_lib_mysql
lvreduce -L-20G /dev/mapper/sys_vg-var_lib_mysql

На всякий случай я предпочел проверить фс на ошибки (а вдруг!):

reiserfsck /dev/mapper/sys_vg-var_lib_mysql

Ну и возвращаем обратно MySQL:

mount /var/lib/mysql
/etc/init.d/mysql start

Теперь создадим lv для веб-файлов, и так как их намного меньше 20ГБ, я решил оставить 5ГБ про запас, никому их не присвоив. Потом можно будет налету добавить туда где закончится место.

lvcreate -L 15G -nvar_www sys_vg
mkreiserfs /dev/mapper/sys_vg-var_www

Далее – перенос файлов:

/etc/init.d/nginx stop
/etc/init.d/apache2 stop
mount /dev/mapper/sys_vg-var_www /mnt
mv /var/www/* /mnt/
mv /var/www/.* /mnt/
umount /mnt
mount /dev/mapper/sys_vg-var_www /var/www
/etc/init.d/apache2 start
/etc/init.d/nginx start

И опять не забываем про fstab:

printf "\nUUID=`blkid | grep sys_vg-var_www | sed -r 's/.*UUID="([^"]*).*/\1/i'`\t/var/lib/mysql reiserfs defaults 0 2\n" >> /etc/fstab

По материалам:

PS: после изменения размера мог измениться UUID для lv var_lib_mysql, хотя я и не уверен в этом. Но проверить не помешает.
PS2: если работаете удаленно – не забывайте про screen.
PS3: писалось по памяти, так что могут быть некоторые неточности. Тупой копипаст без вовлечения мыслительного процесса чреват боком. Я предупредил

Server moving adventures

dm — Thu, 07 Aug 2008 01:45:28 +0000

Второй день занимаюсь переездом содержимого одного сервера на другой. Другой – VPS под FreeBSD (привет, ДЦ Воля).

В общем, это последний раз когда я до оплаты сказал что он неплох. Теперь только реальные сервера. Ну и может VDS под Linux… В общем, именно эта реализация ужасна. Меня мало интересует как и что – факт налицо.

Первая ласточка – mysql. Сообщение о нехватке памяти в логах:

080806 13:39:10 [ERROR] /usr/local/libexec/mysqld: Out of memory (Needed 1043824 bytes)

Судя по найденому в гугле и попыткам что-либо изменить, это вылазит из-за дефолтного в i386 FreeBSD значения максимального количества памяти на процесс. И изменить его у меня не удалось. В результате куцые буфера, и веселые запросы толпятся в очереди, а MySQL уверенно пухнет. И опухает:

[root@vps ~]# ps axu | grep mysql
bash: fork: Cannot allocate memory

Причем, такое поведение я уже встречал ранее. Дважды. Тогда еще и файловые дескрипторы заканчивались (привет phpbb с кучей плагинов).

Но все был бы ничего, однако базы в большинстве своем живут в MyISAM, но самая тяжелая – как и полагается, в InnoDB. И вот любой запрос с джоинами на ней ложил тачку.

Во время разборок с мускулем был применен киллер, найденый в темном переулке на форумах мускуля:

#!/usr/local/bin/php

mysql_connect('localhost', 'root', 'pass');
$result = mysql_query("SHOW FULL PROCESSLIST");
while ($row=mysql_fetch_array($result)) {
$process_id=$row["Id"];
if ($row["Time"] > 10 && $row['User']!='root' ) {
$sql="KILL $process_id";
mysql_query($sql);
}
}
?>

Теперь появилось время на мысли. mtop помог отследить, что во всем виновата одна эта БД. После запора в ней более-менее тяжелые запросы в других БД тоже застряют.

Результатом был переезд этой большой базы на другой хост, и использование ее оттуда. Сервер с двухядреным оптероном и 4ГБ памяти не заметил появления балласта: запросы пролетали мгновенно. И это без попыток тюнинговать мускуль.

Далее начались проблемы с милой связкой nginx+apache. Как описано у Алексея, все заработало. Но некоторые странички отказывались показываться – браузер ругался на невозможность понять что же ему пришло. Такой ошибки я не встречал, и как оказалось никто из моего контакт-листа тоже.

А получилось следующее: обожаемый ExpressionEngine (и тебе привет) пытался все отдать за-gzip-леное. Апач справедливо отдавал это как HTTP/1.1 Transfer-Encoding: chunked. Но это в ответ на запрос HTTP/1.0 от nginx! Последний нифига не понимал и результирующий фарш доставлялся браузеру. Еще бы, он не хотел это нечто отображать…

Выключением опции gzip-сжатия в ExpressionEngine 1.5.3 это полечилось, однако…

… приключения с этим белым и пушистым зверьком не закончились. В форуме при публикации сообщения символы кириллицы отсутствовали. Долго я искал помощи через гугль, пока не полез в код. А в коде методом тыка нашел, что это все виноват xss_clean в версии 1.5.3.

Заменив строки с

...
$str = preg_replace('#(&\#*\w+)[\x00-\x20]+;#u',"\\1;",$str);
...
$str = preg_replace('#(&\#x*)([0-9A-F]+);*#iu',"\\1\\2;",$str);
...

на

$str = preg_replace('#(&\#?[0-9a-z]+)[\x00-\x20]*;?#i', "\\1;", $str);
...
$str = preg_replace('#(&\#x?)([0-9A-F]+);?#i',"\\1\\2;",$str);

проблему вылечил.

С нетерпением жду что обнаружится дальше…