Средства за наблюдение в TBL (пост за програмиране)

June 22, 2010

Марио Пешев пита какви средства използвам за наблюдение на 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 е особено проблемен в това отношение. Може да е много бърз, но някои привидно прости SQL заявки могат да се окажат бомби със закъснител. За това е нужно да се наблюдават заявките при реална работа.

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

Въпросът

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

Публикувано в: TBL 5 коментара RSS 2.0

Ако постът ви харесва, цъкнете на сърцето:

Коментари

5 коментара на “Средства за наблюдение в TBL (пост за програмиране)”

  1. Марио Пешев on June 23rd, 2010 10:45

    Въпросът бе комплексен, но да – както с какво следиш процесите и работата в ТБЛ, така и как оптимизираш работата на платформата софтуерно :)

  2. dzver on June 23rd, 2010 11:36

    Груб план за оптимизация (+ четата са неща, с които се занимавам, а – са неща, с които вероятно ще се занимавам в бъдеще):

    1. Админска оптимизация
    - избор на подходящ уеб сървър
    + избор на подходяща конфигурация на уеб сървъра (.conf + .htaccess)
    + избор на подходяща конфигурация на php
    + избор на подходяща конфигурация на mysql
    + sphinx | lucene
    - apc
    ~ in-memory key/value store (memcached, memcachedb, redis, …) (ползвам моя алтернатива, но тези са по-добри)
    - load balancing
    - squid
    - репликация

    2. Софтуерна оптимизация
    + денормализация
    + DB Schema + индекси = кюърита
    + кеширане и cache invalidation
    + php – дати, цикли, работа със стрингове, памет, кънекшъни, output buffering, случайност и подреждане
    + python – парсване на html и xml, threading, оптимизация на изключенията, енкодинги.
    + пестене на query-та
    + HTML & JS & images :-)

    3. Пестене на лично време
    + usability в админските панели
    + заместване на ръчния труд със скриптове

    Поне по пост за всяко от тези неща… цял блог си трябва.

  3. Георги Чорбаджийски on June 27th, 2010 20:32

    Е как си изкриви мозъка да измислиш тези “кюърита”, като на нашенски му викат “заявки”, честно нямам си и идея.

  4. dzver on June 27th, 2010 21:02

    Ще бъде забавно да споделиш нещо по темата, вероятно знаеш доста повече от мен.

    За термините, които ползвам, си има причина и тя е, че не съм шлайфан в някакво IT общество или в университет, а съм се учил сам – SQL Query за мен е било ескюел кюъри и никой не ме е поправял.

  5. dzver on June 27th, 2010 21:32

    ps. използвал съм “заявка” десетки пъти в поста, значи очевидно знам за думата…

Оставете отговор