Posterous theme by Cory Watilo

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] проблему вылечил. С нетерпением жду что обнаружится дальше...