Сбор информации о производительности системы.

[Wicked]

Сбор информации о производительности системы.

Столкнулся с ситуацией, когда есть более-менее готовая система (linux, nginx, fastcgi, php, mysql), которая просто очень медленно работает. Я на ней новичок, знаю мало. Передо мной стоит задача - сделать, чтобы она работала быстро

Как оптимизировать пхп я знаю. Как оптимизировать работу с бд - нормально. С масштабированием в последнее время тоже ничего. Кэширование - не вопрос.

Но сейчас понял, что не располагаю связующим звеном: эффективными методиками и средствами анализа того, ГДЕ именно системе требуется мое вмешательство. А это демотивирует, потому что я знаю, что в подобной ситуации мои предположения в итоге на 90% окажутся неверными, и я офигенно заоптимизирую ту часть, которая нуждается в оптимизации ДАЛЕКО не в первую очередь.

Собственно, что хочется в идеале:
Какой-то монитор-агрегатор того, что происходит на серверах (бэкендах), удовлетворяющий следующим требованиям:

• Достаточно широко охватывающий систему.
• Достаточно точно и детально указывающий на то место и условия, при которых возникают тормоза.
• Наглядность.
• Высокая стабильность, чтобы можно было мониторить продакшн.
• Минимальное падение производительности.

Но понятно, что идеал недостижим, поэтому приветствуются любые идеи насчет софта, методик и прочего, что облегчит жизнь

Ну и опишу, что имеем на данный момент (курсивом - несоответствия критериям):

• Mysql query log + mysqlsla для информации о производительности бд. На данный момент он почти не работает, потому что нету запросов, которые выполняются дольше секунды. Да и без microslow патча (который не хочется ставить на живую систему), это выявляет только очень грубые проблемы. Проблемы с охватом.
• Munin, для отслеживания, стало ли системе жить лучше. Пока разбираюсь, как по этой кофейной гуще делать какие-то выводы Нету детальной информации
• Логгер времени выполнения достаточно высокоуровневых частей системы (написан на чистом PHP, часть самой системы). К сожалению, выдает не очень репрезентативную статистику (это изменится в лучшую сторону при увеличении кол-ва пользователей), и не особо наглядную (думаю над тем, какие отчеты мне нужны).
  Наглядность - пока хромает. Стабильность: были прецеденты Падение производительности: были прецеденты.
• Xdebug на девелоперском сервере для обката частей, которые были признаны медленными (на основании пред. пункта). Для анализа - CachegrindVisualizer (win) / KCachegrind (linux). Проблемы с охватом, наглядностью, стабильностью и падением производительности. Зато детализация непревзойденная.
• Pinba monitor. Еще разбираюсь.

 

[grigori]

1я мысль - поставить отдельный лог-сервер, на него повесить демона, который принимает входящие udp-сообщения, которые пишутся в базу;
на production-сайте включить auto_append_file и auto_prepend_file, которые будут замерять время и отправлять udp-датаграммы на лог-сервер.

Т.о. ты за пару дней соберешь детальную статистику, какие именно страницы сколько времени (суммарно и индивидуально) у тебя исполняются, с минимальным влиянием на работу самой системы.

Также можно передавать статистику по любому модулю системы (надеюсь, она написана на N-Tier/MVC?).

 

[fixxxer]

ну для начала надо определить что вообще тормозит из
>>(linux, nginx, fastcgi, php, mysql)
и во что упирается (цпу, память, диск, сеть...)

первичная диагностика делается средствам и ОС, а дальше все тобой перечисленное + здравый смысл

(кстати, как это - пинбу заопенсорсили а я не в курсе? =))

-~{}~ 28.01.08 19:34:

>1я мысль - поставить отдельный лог-сервер, на него повесить демона, который принимает входящие udp-сообщения

так работает пинба, кстати

 

[Wicked]

1я мысль - поставить отдельный лог-сервер, на него повесить демона, который принимает входящие udp-сообщения, которые пишутся в базу;
на production-сайте включить auto_append_file и auto_prepend_file, которые будут замерять время и отправлять udp-датаграммы на лог-сервер.

Да, это про пинбу.

Похожее делает наш "Логгер времени выполнения достаточно высокоуровневых частей системы", но он сам пишет в базу. Может быть переделаю его так, как ты предлагаешь - слать через UDP. Спасибо за наводку. Это, наверное, станет более многословным средством по сравнению с пинбой (fixxxer, не в курсе, к ней же нельзя прикрутить кастомное логгирование?).

Также можно передавать статистику по любому модулю системы (надеюсь, она написана на N-Tier/MVC?).

MVC, ага.

и во что упирается (цпу, память, диск, сеть...)

Ну с цпу и сетью более-менее понятно - там известен предел.
А вот как понимать в том же мунине, что диск или память перегружены - для меня пока задача дай бог
Только я не представляю, как это сможет указать на причину проблем. Я что-то упустил?

(кстати, как это - пинбу заопенсорсили а я не в курсе? =))

А я этого и не говорил )
http://phpclub.ru/talk/showthread.php?postid=719955#post719955

 

[fixxxer]

а сколько вообще железок то и где чего крутится?

 

[Wicked]

1 LB с привязкой клиентов к серверам.
2 неплохих сервера с nginx + fastcgi php.
1 неплохой сервер с mysql.

Сейчас параллельно с оптимизацией обсуждаем, как будем масштабировать бд. Склоняемся к шардингу на mysql, хотя у отдельных личностей есть мысли переделать все на постгрес. Шардинг - в первую очередь из-за объемов бд.

-~{}~ 30.01.08 15:37:

Встала еще одна проблема, нетехническая.

На продакшн-сервере периодически возникают тормоза. Есть предположения, что из-за локов в бд, но не суть... главное, что я не могу их воспроизвести на тестовой машине. На данный момент подтверждение подобного факта на продакшене требует:
* написать патч к системе, отправить его на ревью.
* пропатченные части коммитятся в цвс ревьюером.
* из цвс система раз в сутки билдится в рпмки.
* из рпмок она раз в сутки же ставится на продакшн.
Соответственно, те, кто знает, сколько требуется итераций, чтобы подтверждить или опровергнуть теории относительно причин тормозов, могут предположить, сколько времени мне требуется на фикс, если следовать бизнес-процессам )

Меня это в корне не устраивает.

Какие будут предложения по адаптации бизнес-процессов компании для того, чтобы более эффективно и оперативно бороться с тормозами, когда они возникают только на продакшене?

-~{}~ 30.01.08 15:39:

пс:

* написать патч к системе, отправить его на ревью.
* пропатченные части коммитятся в цвс ревьюером.

сейчас плавно переползаем на свн и использование бранчей, так что эта часть, можно сказать, уже решена...

-~{}~ 30.01.08 15:50:

1я мысль - поставить отдельный лог-сервер, на него повесить демона, который принимает входящие udp-сообщения, которые пишутся в базу;
на production-сайте включить auto_append_file и auto_prepend_file, которые будут замерять время и отправлять udp-датаграммы на лог-сервер.

Кстати, а есть готовые решения для подобного сервера?
Просто если я смогу собирать данные, используя пхпшную логику, то отсылать с помощью самописного клиента по udp не представляется сильно сложным. Или есть какие-то камни?

 

[Black Raven]

Долго решал писать или нет, решил что стОит.

http://www.amazon.com/Building-Scalable-Web-Sites-applications/dp/0596102356/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1201694192&sr=1-1

довольно интересное чтиво. как многие книги издательства O'Reilly доступно на safari bookshelf (http://safaribookshelf.com/)

там собсно несколько глав именно про сбор статистики с разных типов служб.

 

[Wicked]

Black Raven
http://phpclub.ru/talk/showthread.php?s=&postid=774222#post774222
Я читаю ее нечасто и по порядку... но посмотрю тогда что там именно про мониторинг. Спасибо.

 

[ys]

Wicked

Ось linux?
Я не знаю как там сейчас с "process audit", но может оно есть?

 

[Wicked]

Ось CentOS.
Я пока что не знаю, что такое process audit.

В принципе, я перескочил до восьмой-десятой глав книги, и там много интересного. Предлагаю обсуждение отложить на несколько дней.

 

[fixxxer]

>mysql
engine?

-~{}~ 31.01.08 07:28:

>а данный момент подтверждение подобного факта
слать всех нафиг и экспериментировать на живом - это часто единственный способ быстро привести все в порядок

а вообще,
>>для начала надо определить что вообще тормозит

-~{}~ 31.01.08 07:30:

>>бсуждаем, как будем масштабировать бд. Склоняемся к шардингу на mysql

решение хорошее, у людей работает... два совета только
1 - никаких myisam
2 - репликацию нафиг

 

[Wicked]

engine?

innodb

а вообще,
>>для начала надо определить что вообще тормозит

вот я и хочу это сделать на продакшене Но экспериментировать в решении проблемы там, наверное, надо будет еще аккуратнее.

решение хорошее, у людей работает... два совета только
1 - никаких myisam

ну для некоторых не mission critical задач типа складирования тех логов о производительности - почему бы и нет?

2 - репликацию нафиг

Репликация, возможно, понадобится для HA каждого из шардов. Еще не решили.

 

[fixxxer]

1 ну я имею в виду для основных табличек особенно куда идут частые апдейты
2 главное чтобы не master -> many slaves ибо через некоторое время мастер будет занят исключительно раздачей бинлогов
3 вообще при шардинге главное правильно выделить сущность по которой разделяем =) в принципе их может быть и несколько, с соответствующим дублированием информации. главное - не бояться денормализации

-~{}~ 31.01.08 07:59:

>>вот я и хочу это сделать на продакшене Но экспериментировать в решении проблемы там, наверное, надо будет еще аккуратнее.

а не надо бояться
все системы сбора статистики хороши прежде всего для предупреждения аварийных ситуаций, типа "что то вот там у нас многовато кушает", а когда уже приперло - берешь идешь прям на сервак и вбиваешь в критических точках error_log(var_export).. итп

 

[Wicked]

1 ну я имею в виду для основных табличек особенно куда идут частые апдейты

само собой

2 главное чтобы не master -> many slaves ибо через некоторое время мастер будет занят исключительно раздачей бинлогов

Да, я в курсе Пока что вижу 3 подходящих варианта - M-M репликация, drbd-синхронизация, или просто общее SAN-хранилище.

3 вообще при шардинге главное правильно выделить сущность по которой разделяем =)

Это то и пугает, ибо стоит ошибиться и приплыли Наибольший страх вызывают всякие выборки, которые не соответствуют выбранной кластеризации, такие как "выбрать 1000 последних зарегистрированных юзеров".

в принципе их может быть и несколько, с соответствующим дублированием информации. главное - не бояться денормализации

Можно поподробнее и с примерами? Я вот, например, в качестве факультативного мозго....ства пытаюсь придумать, как бы я сделал френдов (френдленту) в жж. Как там сделано на самом деле - без понятия, но было бы очень интересно

-~{}~ 31.01.08 11:31:

>>вот я и хочу это сделать на продакшене Но экспериментировать в решении проблемы там, наверное, надо будет еще аккуратнее.

а не надо бояться
все системы сбора статистики хороши прежде всего для предупреждения аварийных ситуаций, типа "что то вот там у нас многовато кушает", а когда уже приперло - берешь идешь прям на сервак и вбиваешь в критических точках error_log(var_export).. итп

жостко
просто не хочется быть крайним, если вся система накроется благодаря моим кривым ручкам ))

 

[fixxxer]

ой, вопрос френдленты вообще сложный и не имет однозначного решения, было много рассуждений в ру_хайлоад кажется как бы класть френдов поближе друг к другу итп =)

но вообще оверхед на лишние mysql_connect небольшой, пока их не слишком много, тут уже надо смотреть куда все в итоге упирается - вообще все эти дела это сплошной поиск компромиссов между потреблением cpu, оперативки и hdd =)

-~{}~ 31.01.08 08:44:

вообще если ты сможешь отделить чисто техническую сторону от бизнес процессов и изложить задачу достаточно полно для обсуждения, но не затронув nda была бы интересная дискуссия. про сферических коней то можно долго рассуждать без особого смысла

 

[Wicked]

http://community.livejournal.com/ru_highload/27236.html ?
тогда я там тоже рассуждал

 

[fixxxer]

агаа

 

[Wicked]

Да, я согласен, что тема уехала куда-то не туда...

Но не понял, что все таки лично тебе интересней? техническая сторона или бизнес-процессы? Или и то, и другое, но раздельно?

 

[fixxxer]

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

 

[point]

Извините что влажу в ваш диалог Если в проекте веб сервером выступает апач, может быть эта заметка пригодится.

http://www.lissyara.su/?id=1582