(http://dzver.com/blog/)
Средства за наблюдение в TBL (пост за програмиране)
Марио Пешев пита какви средства използвам за наблюдение на TBL, по отношение оптимизация за бърза работа.
Проблемът
TBL в момента има ~350K поста и няколко таблици между 1 и 10 милиона записа. Използва InnoDB и joins. Работи на машина, на която има по-натоварени сайтове, вкл. някои със специфични нужди за ресурс. Поставил съм си за стандарт под 0.1 sec време за изпълнение на PHP script. Броят HTTP requsets с употреба на SQL в рамките на TBL е грубо 500 000/ден (предимно заради ботове, widgets и ajax).
Заместване на mysql_slow
99% от случаите един сайт е бавен заради SQL-a му. MySQL е особено проблемен в това отношение. Може да е много бърз, но някои привидно прости кюърита могат да се окажат бомби със закъснител. За това е нужно да се наблюдават заявките при реална работа.
MySQL има slow query log – mysql_slow, който логва заявки, по-бавни от определено време. Проблемът е, че long_query_time не може да приема стойност под 1 сек (може в Percona Server или с пач, но тези варианти не са ми удобни). Ако имате заявка, която се изпълнява 10 000 пъти дневно и отнема 0.5 сек, сайтът ви отива по дяволите.
TBL има свой slow log, който се управлява в DB класа и опционално поддържа времена под 1 сек (типично оптимизирам на нива 0.02, 0.2 и 2 сек – допустимо за определени редки случаи). Има и справка, която групира бавните заявки по тип и сумира времената на изпълнение. Надничам там <1 път в месеца и току някоя бърза заявка е станала бавна, с нарастването на данните. Този лог трупа данни постоянно.
Index size
Следя INDEX_LENGTH в information_schema.tables, пестя памет за други цели.
Parsing time
За агрегатор е важно колко бързо събира информацията. Има втори лог, който се пуска опционално и е направен за тасковете по събиране на информация. Преди 1-2 месеца се наложи да го ползвам, за да открия проблем във feed reader-a.
Loading time
Зареждането на 1 сайт не е само php-то (или каквото ползвате) и не е само заглавната страница. Ползвам пълен набор от firefox plugins – yslow, pagespeed, ползвам webpagetest.org, но част от предписанията им са неприложими в моя случай, така че не се престаравам. GWT също предоставя такива данни, може да ги гледате.
Traffic
Наблюдавам MRTG графики за server load и трансфер, направени от приятел – zImage преди години, за мониторване на IRC. Трафикът може да бъде ботълнек, ако ви се счупи нещо в бекъпа примерно и започне да точи бесни GB-ти.
Emails
Получавам автоматично генерирани мейли при най-разнообразни събития. Разполагам и с 10-тина графики, от които може да се следи, ако работата е станала ненормална. TBL има форум, лични съобщения и къмюнити от няколко всеотдайни потребители, които забелязват проблеми
Въпросът
Не съм сигурен, дали Марио това ме попита. По-интересният въпрос е, какво се прави, когато сървърът се претовари, купуването на части не е опция и трябва да се оптимизира
Свързани новини:
- И Видин обявява грипна епидемия
- Без безплатни бързи тестове за грип
- Приложение на „Майкрософт” ще ни предупреждава за сайтове с фалшиви новини
- Опозиционерът Хуан Гуайдо се обяви за временен президент на Венецуела
- Жената, нападнала медик в Горна Оряховица, е с повдигнато обвинение
- Руската ВТБ: Заложници сме на нарастващ конфликт между Тръмп и Конгреса
- Ивелин Попов се настани в хотела на "Ростов" в Доха, ще подписва
- Алберт Попов спечели втория слалом за ФИС
- Паредес се отдалечава от ПСЖ
- Прекратиха търсенето на самолета със Сала поне за днес
- Погба носи тузарски костюм със своите инициали
- Зафиров: Цената на Неделев е висока
- Емери: Арсенал работи по трансфера на Суарес
- Зафиров: Неделев отхвърли ЦСКА и Лудогорец, търсим нападател и ляв бранител
Виж всички новини от 2010/06/22