НовостиРазбор технических проблем 27-28 февраля 2013 года.

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

Основную часть проблем составила нестабильная работа серверов баз данных mysql0 и postgresql0, причем, второй пострадал в значительно меньшей степени.

Причины же отказов были разными. 27 февраля мы получили сообщение от мониторинга о резком всплеске нагрузки на сервере Neon. Выяснение причин всплеска заняло некоторое время, в течение которого пул подключений к СУБД оказался занят полностью и сервер mysql0 перестал принимать новые подключения.

Проекты Rails, которые используют базы на этом сервере оказались не в состоянии выполнять запросы и их воркеры ушли в бесконечный цикл попыток переподключения либо получения данных, что вызвало еще больший рост нагрузки на этот раз уже на всех серверах хостинга. Мы знаем об этой особенности работы Rails и временно остановили проблемные проекты, что в целом стабилизировало ситуацию.

Тем временем наши специалисты обнаружили источник проблемы: сразу несколько проектов, на которых запущены популярные форумные движки вроде SMF подверглись атаке ботнета: с большой скоростью в 20-30 потоков в них размещались автоматически спам-записи. Форумы оказались с необязательной регистрацией и без проверки капчи. Они честно записывали любой поступивший POST-запрос в базу, открывая столько подключений, сколько пришло запросов.

Автоматическая система предодвращения флуда не среагировала на эту атаку, т.к. количество запросов в момент времени с одного IP-адреса было сравнительно невелико для принятия решения о блокировке этого адреса.

Мы заблокировали проблемные проекты до выяснения обстоятельств, перезапустили СУБД mysql0 и все проекты, которые его используют. На этом инцидент был исчерпан и сервис продолжил нормальную работу до утра 28 февраля.

28 февраля мы получили сообщение о резком росте нагрузки на сервер mysql0, при этом наблюдалась очень высокая дисковая активность. При этом в таблице активных запросов не было ничего необычного или странного. Дальнейшее разбирательство показало, что проблема кроется в части нашей панели управления: модуль исполнения задач, запущенный на сервере mysql0 начал активно увеличивать потребление памяти и занял ее всю, что и привело к активному использованию дисков для сохранения страниц памяти в swap.

Перезагрузка этого модуля и перезапуск MySQL помогли — ситуация моментально стабилизировалась.

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

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

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

Компенсации за неработу проектов будут начислены в течение этой недели всем клиентам, чьи проекты используют СУБД сервера mysql0.

  1. Александр:

    Ребят, молодцы. Вы всегда быстро справляетесь с пробелмами. Не могли бы вы поподробнее рассказать об ошибке в интерпретаторе ruby? Эсть ли на это тикет, для какой версии эта ошибка возникает, как обошли? Заранее спасибо))

  2. А проекты которые использовали PostgreSQL и которые два дня подрят получали 500 ошибки? Не получат компенсацию?

  3. admin:

    И проекты на postgresql0 тоже не забудем.

  4. admin:

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

  5. Георгий:

    Слушайте, но сейчас периодически вылезает проблема с переполнением пула соединений на mysql2.
    Может быть рекомендовать всем на sqllite переходить просто, раз с MySQL такая фигня?

    Хотелось бы чтобы проблемы конкретного проекта как можно меньше трогали остальных.