Server moving adventures
Второй день занимаюсь переездом содержимого одного сервера на другой. Другой - VPS под FreeBSD (привет, ДЦ Воля).
В общем, это последний раз когда я до оплаты сказал что он неплох. Теперь только реальные сервера. Ну и может VDS под Linux... В общем, именно эта реализация ужасна. Меня мало интересует как и что - факт налицо.
Первая ласточка - mysql. Сообщение о нехватке памяти в логах:
[cc lang="text"]
080806 13:39:10 [ERROR] /usr/local/libexec/mysqld: Out of memory (Needed 1043824 bytes)
[/cc]
Судя по найденому в гугле и попыткам что-либо изменить, это вылазит из-за дефолтного в i386 FreeBSD значения максимального количества памяти на процесс. И изменить его у меня не удалось. В результате куцые буфера, и веселые запросы толпятся в очереди, а MySQL уверенно пухнет. И опухает:
[cc lang="text"]
[root@vps ~]# ps axu | grep mysql
bash: fork: Cannot allocate memory
[/cc]
Причем, такое поведение я уже встречал ранее. Дважды. Тогда еще и файловые дескрипторы заканчивались (привет phpbb с кучей плагинов).
Но все был бы ничего, однако базы в большинстве своем живут в MyISAM, но самая тяжелая - как и полагается, в InnoDB. И вот любой запрос с джоинами на ней ложил тачку.
Во время разборок с мускулем был применен киллер, найденый в темном переулке на форумах мускуля:
[cc lang="php"]
#!/usr/local/bin/php
10 && $row['User']!='root' ) {
$sql="KILL $process_id";
mysql_query($sql);
}
}
?>
[/cc]
Теперь появилось время на мысли. 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.
Заменив строки с
[cc lang="php"]
...
$str = preg_replace('#(&\#*\w+)[\x00-\x20]+;#u',"\\1;",$str);
...
$str = preg_replace('#(&\#x*)([0-9A-F]+);*#iu',"\\1\\2;",$str);
...
[/cc]
на
[cc lang="php"]
$str = preg_replace('#(&\#?[0-9a-z]+)[\x00-\x20]*;?#i', "\\1;", $str);
...
$str = preg_replace('#(&\#x?)([0-9A-F]+);?#i',"\\1\\2;",$str);
[/cc]
проблему вылечил.
С нетерпением жду что обнаружится дальше...