Leave a Comment
Realtime-профилирование проекта от Instagram
Measurements: счетчики и таймеры
Дабы следить за всем, что происходить внутри, надо как-то мониторить всю активность. Обычно это два типа активности: какие-то количества (counters, регистраций в секунду, например) и какие-то интервалы времени (timers, сколько по времени занимает лайкнуть винтажное фото, например). Но как быть, когда у тебя не одна машина на балконе, а пара десятков в ДЦ, и нам нужен один общий график, а не пара десятков разных? Решение простое -хранить все в одной базе данных. Но операция эта не столь быстра. На выход приходит UDP! Да-да, вместо того, чтобы пихать все в базу данных, мы просто будем кидать специальные пакетики по UDP с данными на один общий сервер, а сервер будет их принимать, суммировать и репрезентовать графически. Так вот, для этого всего в Instagram используют NodeJS daemon called «statsd». Он все это богатство ловит, а затем отправляет их прямиком в Graphite (штуковина для построения графиков, как вы могли догадаться).
Все это очень масштабируемо (в Instagram интервал поллинга стоит 10 секунд), потому позволяет следить за всем происходящим почти realtime.
Для мониторинга PostgreSQL серверов используется PGFouine. Он на основе логов PG сервера строит аналитику, позволяя выявить тяжелые запросы и закешировать их, либо же неоптимизированные запросы, запросы выдергивающие лишние данные и т.д.
Зомби-процессы
Ужасно грустно, когда клиенту вываливается 500 ошибка по истечению таймаута, не так ли? А кто виноват? Все молчат, а единственного свидетеля уже убили (kill -9). На помощь Instagram приходит Bitbucket с их open-source разработкой для Django под названием dogslow. Этот пёс цепляется к каждому запросу в самом его начале, и, ежели по истечению 25 секунд ответа на запрос не пришло, он сливает трейс вызовов куда-нибудь, например, на почту.
С его помощью ребята выяснили, что узким местом являлся memcached, который подвисал при запросах set() и get_many(), генерируя по 50 000 запросов / с, притом не используя весь процессор и, как следствие, тормозя весь процесс.
Репликация и рабовладение
Основными бекендами для хранения данных в Instagram, Inc. являются Redis & PostgreSQL. Как известно, оба этих движка думали о масштабируемости, потому позволили ребятам «на ходу» подключать слейвы, как только ресурсов начинало не хватать.
В первые 12 часов частота запросов к БД Redis достигла 40 000, что стало сказываться на производительности. На подключение дополнительных серверов ушло не больше 20 минут. Впечатляет, не правда ли?
Для масштабирования Postgre использовались Amazon EBS Snapshots. Для их подключения тоже потребовалось не больше 20 минут, благодаря легко настраивоему AWS окружению, в котором болтаются их мастер-сервера.
Android-ные фишки
Помимо всего этого, ребята написали утилиту node2dm — сервер node.js для отправки push-уведомлений в андроидный C2DM сервис. По их данным, он обработал около 5 млн. уведомлений в тот день. В честь этого,node2dm был подарен сообществу совершенно open-source-но.
Оригинал статьи — http://habrahabr.ru/post/141830/.
Ссылка на статью в блоге разработчика — http://instagram-engineering.tumblr.com/post/20541814340/keeping-instagram-up-with-over-a-million-new-users-in
P.S. ещё упоминается инструмент для отслеживания использования памяти — vmtouch
Similar Posts
LEAVE A COMMENT
Для отправки комментария вам необходимо авторизоваться.