Почему упало "Куда"

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

Сначала цифры для статистики. Хотя, как потом будет понятно, значат они не так уж и много.

Мы работаем на кластере из 4 машин (CPU Xeon, 4 ядра, 2.3 ГГц), на которых крутится lighttpd, Django и memcached. За ними стоит 1 сервер БД, на котором крутится MySQL. Люди шли к нам нормально всю ночь и утро, и поток в 55 запросов/сек на одну машину мы выдерживали. Потом, где-то между 10 и 11 часами нам стало плохеть, в пике трафик поднялся до больше 300 запросов/сек на машину, и после этого... м-да :-(.

Проблема первого рода

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

Проблема нашлась в использовании сессий (не их самих, а в том, как мы их приготовили). Это те самые стандартные сессии, которые есть в Джанго. И вообще-то, в Джанго они сделаны достаточно умно — хранятся они в БД, но если в приложении в них ничего не записывать, то они не трогают БД вообще. К сожалению, у нас они использовались довольно интересным способом. Мы записываем в них сообщения для пользователя, которые показываются один раз и удаляются. Для этого в процессоре контекста у нас был такой код:

messages = request.session['messages']
request.session['messages'] = []  # ← строчка-убийца!!!

Вторая строчка — это очистка сообщений, которая суть запись в сессию. А раз выполнялось это в процессоре контекста, то отрабатывало это на каждый запрос.

Не совсем на каждый, правда, а только тогда, когда к нам приходил новый пользователь. Однако поскольку это был тизер на морде Яндекса, то у нас, собственно, практически все пользователи были новыми.

Впрочем, вы можете возмутиться, что даже с потоком в 1200 запросов/секунду MySQL на хорошем железе должен был справляться. Этому помешали две особенности таблицы сессий:

• она, как и все таблицы в нашей базе, использовала InnoDB в качестве движка
• ключ этой таблицы — md5-хеш, а не автоинкрементное целое

Если я ничего не путаю, таблицы InnoDB при добавлении каждой новой записи физически перестраиваются на диске в соответствии с порядком, заданным ключом. От этого, видимо, они очень быстро читаются. Собственно, в обычной ситуации с автоинкрементным целым ключом это тоже не вызывает проблем, потому что новая запись добавляется в конец, где и должна быть по порядку. Но раз у нас ключ по сути своей случаен, то каждая новая запись попадала куда-то в середину, что вызывало перестройку таблицы. Перестраивается она фрагментами, что при таких "хаотичных" вставках приводит к фрагментации и все большему и быстрому замедлению записи с ростом таблицы. Админы говорят, что в худшие времена жизни сервиса вставка одной записи в сессии занимала по 6-7 секунд!

В итоге, с какого-то момент скорость роста числа новых запросов обогнала скорость их обработки. Все попытки очухать сервис были, следовательно, обречены на провал, потому что чем дальше, тем медленнее он работал. Это, кстати, то, что я имел в виду о бессмысленности показателей: с таким якорем мерять скорость бессмысленно.

Из всего этого мы извлекли два урока (конечно же, "очевидных"):

• не стоит создавать сессии без нужды
• никогда не стоит хранить джанговские сессии в InnoDB-таблице

Кстати... Горькая ирония этой истории заключается в том, что по факту эту систему сообщений мы сейчас нигде не используем. То есть, сервис убила фича, которой... нет.

Проблемы второго рода

Возвратили сервис к жизни мы, в основном, тем, что запихали сессии в таблицу на памяти (ну и сняли тизер еще :-) ). Но в памяти, кстати, сессии тоже не зажили: там банально кончились подо что-то место, и вечером сервис снова лежал. Так что их пришлось вернуть обратно на диск. А сейчас мы и вовсе открутили ту "строчку-убийцу".

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

Проблемы, в порядке вспоминания, такие:

• "Dog-pile" эффект. Индексная страница состоит практически целиком из закешированных кусочков, каждый из которых, при этом, считается относительно тяжелым запросом. Когда кеш протухает, следующий же запрос вызывает его подновление. И пока это подновление не закончится, все следующие запросы тоже увидят протухший кеш и начнут выполнять те же самые запросы на подновление. Если время подновления достаточно длинное, а запросов достаточно много, то они создают дополнительную нагрузку, тем самым еще увеличивая время подновления и ухудшая ситуацию все дальше и дальше.

• Мы не используем пока еще чтение с реплик, что сняло бы нагрузку с убитого записями в сессии мастера, и, возможно, мы бы протянули дольше :-).

• Еще у нас на индексе была одна выборка с join'ом четырех таблиц, одна из которых — самая здоровенная таблица базы :-).

Стратегия

Вчера все выглядело очень плохо: мы упираемся в базу на запись, а это в мире реляционных СУБД означает, что масштабироваться экстенсивно (то есть добавить машин) нельзя. Надо что-то переписывать, как-то искусственно пилить базу, что тяжело и плохо. Однако сегодня, открутив запись в сессии, мы перевернули ситуацию с голову на ноги. На тестовом стенде, состоящем из одного фронтенда и одного бэкенда с базой мы грузим фронтенд на load около 80, при этом база загружена где-то на 2-2,5. То есть упираемся мы теперь не в нее. А вот фронтендов можно просто добавить, причем, как мне кажется, в базу мы теперь упремся еще нескоро. Запас попробуем оценить во вторник, когда попробуем пострелять по системе из двух фронтендов и базы.

А проблемы второго рода будем решать так:

• Для предотвращения dog-pile эффекта с кешем возьмем, видимо, MintCache.
• Я взялся писать бэкенд "mysql_cluster", который позволит использовать реплики. Пока мне кажется, что получится написать именно внешнюю подключаемую штуку, без хаков кода Джанго.
• Запросы будем дальше оптимизировать денормализацией, как и делали раньше.

Следите за новыми сериями!