Диета за фотомаса Silvan Mühlemann; s блог
Нашите инструменти за наблюдение потвърждават ситуацията: Nagios стреля по мобилния ми телефон с SMS като картечница. Сивата крива, която описва натоварването на сървъра в Ganglia, е доста над червената линия. Морети, нашият инструмент за измерване на времето за реакция, съобщава няколко секунди, за да достави страница с покритие.
Добре известна ситуация, с която се сблъскваме отново и отново, както през последните шест години от нашето съществуване. Има два начина за справяне с тази ситуация: повече хардуерна или софтуерна оптимизация.
Добавянето на хардуер е бързо и лесно решение.
ВЪВЕЖДАНЕТО трябва да се ускори
В този случай ситуацията е различна: фотографите, които искат да добавят снимки към уебсайта, са засегнати. И по-малко посетителите, които искат само снимки. „Добавяне на снимки“ работи бавно. Следователно това са инструкции INSERT, а не заявки SELECT. Добавени са нови снимки. Така че нови редове на базата данни
приложено:
Тъй като работим с репликация, тези редове трябва да бъдат копирани на всички подчинени. Един INSERT на роб. Ако добавим още сървъри към клъстера, това няма да реши проблема, тъй като тези редове също трябва да бъдат добавени към тези нови сървъри. Повече сървъри не намаляват броя на INSERT в клъстера. В този случай хардуерът няма да помогне.
Продължаваме да търсим: ВЛАЖЕНИЯТА създават проблеми. ВЪВЕЖДАНЕТА са твърде бавни. Какво прави INSERT бавно? Какво е скъпо с INSERT? Не добавяне на данни, а писане на индексите. Индексите са сложни структури от данни, B-дървета, двоични дървета, които трябва да се проверяват за претегляне всеки път, когато се вмъква ред. Индексите са скъпи.
В случая с нашата таблица със снимки, индексите съставляват дори повече байтове от данните (въпреки че нашата структура от данни е аматьорска и пълна със съкращения)
Излишни колони и индекси!
Така че отидохме за индексите на таблицата с изображения. Боже мой, какви показатели сме поставили в младежката си безразсъдност? Практически всяка колона има индекс, въпреки че никога не се използва в заявка (тест с EXPLAIN SELECT). Все още има колони, които никога не са заявявани. злото!
Срешете през 60 000 реда код
И така: Стефан и аз стигаме до диетата на таблицата с изображения: С grep върху целия код наlate, проверявам всички обаждания към таблицата с картини. Кои индекси можем да изтрием? Кои колони вече не са необходими?
Резултатът: Стигаме до три колони и пет индекса, които не се използват. Особено удебелен пълнотекстов индекс може да бъде изгонен в отделна таблица чрез вертикално разделяне. Това ли е причината да бъдем щастливи, тъй като намерихме толкова много място за подобрение? Или трябва да се ядосваме за надуването ни в системата?
Няма значение: В събота сутринта в 01:00, Стефан изпълнява изявленията ALTER TABLE. След два часа продължителност на заявката, светкавичната диета е завършена. Резултатът:
Намаляване на файла с данни с 22%. Намаляване на индексния файл със 70%. Това води до по-бързи INSERT, по-бързи архиви и по-бърза РЕМОНТНА МАСА (което често е проблем с таблиците MyISAM).
Тази вечер ще покаже дали ще е по-лесно за фотографите да добавят снимките. Любопитен съм.