Perl процессы грузят CPU на 100% под FreeBSD6

Статус
В этой теме нельзя размещать новые ответы.

websurfer

Постоялец
Регистрация
20 Ноя 2006
Сообщения
89
Реакции
10
Здравствуйте,

Собжевая ситуация. Начала возникать ориентировочно после того, как на сервак поставились ещё 3 тяжёлых ЦМСки (нюк, даталайф).

Сервер работает более-менее нормально, но в часы пик - 17:00-19:00 наглухо вешается. В настройках ПХП для ЦМСок ограничили кол-во обращений к мускулу, в настройках мускула поставили оптимальное число одновременных обращений к базам, однако проблему не решило - во время работы сервера через ТОП проскакивают секундные процессы перла с загрузкой КПУ по 10-50%, а в часы пик судя по всему именно перл убивает наглухо систему.

Ткните плз пальцем на вариант решения проблемы?

Да, кстати, сейчас разбираю логи мускула. По ним он перезагружался вот совсем недавно по сигналу 10. Вообще проблема видится в том, что перловским скриптом почему-то не достаётся свободных запросов для работы с мускулом и он начинает тормозить а потом и вовсе вешать систему. Ситуация совершенно мне непонятная. Может можно как-то ограничить максимальные ресурсы съедаемые перлом?

По эррор логам апача - достигнуто максимальное кол-во клиентов. Посмотрел в конфиге - это 256 (!!!).

Вобщем, проблема видимо, в мускуле. Он начинает падать при большой нагрузке, перезагружается, в это время перловские скрипты пытаются к нему коннектится, но не получается, они почему-то не отпадают и убивают сервак. В этом состоянии даже залогинится не получается ибо отпадаю по таймауту (иногда удаётся ввести логин, но пароля не дожидаюсь).

Задач 3:
1. Ограничить максимальную загрузку перлом проца.
2. Найти возможные варианты причин загрузки перовскими процессами CPU.
3. Найти возможные варианты причин падений мускула.

Хэлп ми плиз :) задолбался ребутить сервак

Сэнк'ю вэри мач фо йо хэлп
 
1. Анализ логов MySQL наверняка там есть тяжелые запросы.
2. Анализ логов Апача за этот период. может ДОС?
3. Проверь что там в Кроне на всякий случай.
4. Как не странно у меня такие вещи случались ранее, попытка найти слабое место не увенчались успехом. Итог оказался банально прост - пыль в кулерах процов снижала их эффективность и в момент больших запросов муська умирала. Чистка и смазка всех вентиляторов поставила все на норму. =)

Но у тебя это после установок СМС и значит первый пункт самое они ИМХО.

Удачи.
 
1. Запустил мускула с опцией мониторинга "медленных запросов". Посмотрю позже по логам что намониторилось.
2. На ДОС не похоже. Просто ЦМСки во-первых сами тяжёлые, а во-вторых на них идёт нагрузка в часы пик порядка 3 тыс уникальных за час. Само собой тяжко серверу.
3. Крон практически чистый - АвСтатс плюс пара простеньких запросов. А... ну ещё блогорама висит там раз в сутки :)
4. Это дедик, так что думаю дело не в кулерах. Да и прочистить их за 20 тыс км не представляется возможным :)

Да, с ЦМСками в принципе решено - буду перемещать ведь нагрузка "благодаря" их ПХПшным запросам - порядка 25-70% CPU только от них. Однако всё-таки хотелось бы найти причину возникновения столь "тяжёлых" процессов перла. Тем более, что все скрипты там достаточно просты и никто не вызывал зависания при тестах как на винде, так и под фрёй - всё прекрасно работает.

В любом случае, спасибо за советы.
 
В свое время, перед тем как написать свой движек, изучал чужие и набирался опыта. Ну и изучал хваленный тогда двиг Мамбы (сейчас Joomla клон) и наслышавшись о его крутости, продебагил его.
Что сразу бросилось в глаза -это около 60 запросов к базе при формировании главной странички. Ну думаю люди не дураки и начал проектировать свой двиг, запихивая в базу даже header, footer и skin коды.
За что и поплатился, когда нагрузка посетителей перевалила за 100 в онлайне. Услышав от хостера кучу "приятностей" я понял насколько я попал и стал быстро выбрасывать ненужное из базы и кешировать везде, где можно. В итоге я понял что популярные СМС для средних нагрузок не канают.

Возможно установленные тобой СМС имеют тот же недостаток.
 
Т.е. есть вероятность, что мускул падает из-за большого кол-ва обращений? Само собой ЦМСки обращаются оччччень много (по 20-40 обращений), однако (все они на пхп) в php.ini прописал максимально 50 обращений к базе ордновременно, а в базе єто кол-во где-то за полторы сотни. Т.е. по идее сейчас ЦМСки грузят только проц и память. Хотя... с тем, сколько этих запросов httpd идёт и как много (до 15метров под каждый) выделяется под них памяти, можно предположить, что апач просто съедает в часы пик много памяти, что не даёт "развернуться" на всю катушку мускулу, от чего тот и падает. Возможно?

Да, сервер - это не шаред, это дедик Celeron 2.0 + 512 RAM
 
однозначно нагрузка на MySQL
 
а процессы перла почему жрут так много CPU? они кратковременно кушают до 50% (буквально секунда в топе), но их появляется иногда несколько одновременно и именно это я думаю является причиной съедания всех ресурсов сервака.

с мускулом, видимо, ясно - он перегружается только в часы пик из-за нехватки памяти.
 
не думаю, если до этого было все ок.
Проверь, может pconnect используется (так же в настройках СМСок)?
это тоже частая причина.
 
поискал - действительно используется в некоторых соединениях этот тип. как я понял, соединившись, он потом не отпадает сам собой, а ждёт программного отключения. думаю, в ЦМСках всё-таки это предусмотрено и отключаются они нормально.
 
Для просмотра ссылки Войди или Зарегистрируйся

Second, the connection to the SQL server will not be closed when the execution of the script ends. Instead, the link will remain open for future use (mysql_close() will not close links established by mysql_pconnect()).
возможно кто-то не принял во внимание при разработке

и вот еще:
Using persistent connections can require a bit of tuning of your Apache and MySQL configurations to ensure that you do not exceed the number of connections allowed by MySQL.
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху