Второй день занимаюсь переездом содержимого одного сервера на другой. Другой – VPS под FreeBSD (привет, ДЦ Воля).
В общем, это последний раз когда я до оплаты сказал что он неплох. Теперь только реальные сервера. Ну и может VDS под Linux… В общем, именно эта реализация ужасна. Меня мало интересует как и что – факт налицо.
Первая ласточка – mysql. Сообщение о нехватке памяти в логах:
Судя по найденому в гугле и попыткам что-либо изменить, это вылазит из-за дефолтного в i386 FreeBSD значения максимального количества памяти на процесс. И изменить его у меня не удалось. В результате куцые буфера, и веселые запросы толпятся в очереди, а MySQL уверенно пухнет. И опухает:
bash: fork: Cannot allocate memory
Причем, такое поведение я уже встречал ранее. Дважды. Тогда еще и файловые дескрипторы заканчивались (привет phpbb с кучей плагинов).
Но все был бы ничего, однако базы в большинстве своем живут в MyISAM, но самая тяжелая – как и полагается, в InnoDB. И вот любой запрос с джоинами на ней ложил тачку.
Во время разборок с мускулем был применен киллер, найденый в темном переулке на форумах мускуля:
<?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('#(&\#x?)([0-9A-F]+);?#i',"\\1\\2;",$str);
проблему вылечил.
С нетерпением жду что обнаружится дальше…
