06/22/10 09:00
(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 има форум, лични съобщения и къмюнити от няколко всеотдайни потребители, които забелязват проблеми :-)

Въпросът

Не съм сигурен, дали Марио това ме попита. По-интересният въпрос е, какво се прави, когато сървърът се претовари, купуването на части не е опция и трябва да се оптимизира :-)

Публикувана на 06/22/10 09:00 http://dzver.com/blog/?p=1969
Facebook TwitThis Google del.icio.us Digg Svejo Edno23 Email

Свързани новини:

новини от България
graphic
спортни новини
graphic

Бързи връзки


Търсене


Архив

RSS Абонамент

Новини от Грамофон

"Новини от Грамофон" - Следете последните новини от България и чужбина обединени на едно място. Обновяват се през 1 минута.

 

  •  

Ново: Публикуване