Performance engineering stories from #fdminicon Saransk

Несколько историй из жизни
Performance Engineer'а
Александр Чистяков,
главный инженер Git in Sky,
2014
Как я съел кусок мыла
Александр Чистяков,
главный инженер Git in Sky,
2014

Давайте познакомимся
§ Меня зовут Саша
§ Я работаю главным инженером в компании Git in Sky
§ Мы занимаемся эксплуатацией веб-проектов,
помощью в разработке веб-проектов, собственно
разработкой веб-проектов и автоматизацией веб-
проектов
§ Во всем этом приходится участвовать мне
Несколько историй из жизни Performance Engineer'а. 2014

А в чем участвуете вы?
§ Веб-разработка?
§ Эксплуатация веб-сайтов?
§ Поддержка проекта, написанного непонятно кем?
§ Борьба с хабраэффектом?
§ Принятие решений об аренде/покупке серверов?
§ Еще пока не определились, всё такое вкусное?

О чем пойдет речь?
§ Кто такие performance engineers и зачем они нужны
§ Как справиться с хабраэффектом
§ Сколько серверов нужно, чтобы вкрутить одну
лампочку
§ Что лучше: MySQL или MongoDB? PHP, Perl или
Ruby?
§ Однажды у моей подруги с ее парнем...

Кто такой performance engineer?
§ Это человек, который делает performance
engineering
§ http://en.wikipedia.org/wiki/Performance_engineering
§ ^ многа букв
§ Человек, который знает, как все устроено внутри не
в терминах бизнес-логики приложения

Как бороться с хабраэффектом
§ Я испытываю хабраэффект почти каждый раз, когда
открываю статью на Хабре
§ Способы борьбы:
§ Не верьте в магию
§ Не читайте статьи на Хабре
§ Знание — сила
§ (на самом деле, сила это масса на ускорение)

Структурная схема типичного веб-проекта

Проблемы типичного веб-проекта
§ Непосредственно вытекают из его структуры
§ Подразделяются на:
§ ВНЕЗАПНО ничего не работает
§ Всё тормозит!
§ Мы арендовали c3.xlarge, а оно все равно
тормозит!
§ Данные куда-то пропали

Переходим к практике
§ Краткое содержание следующих серий:
§ Описание проблемы, происшедшей у моей
подруги с ее парнем
§ Описание пути решения проблемы
§ Несколько слов о том, чем именно
руководствовались при решении проблемы,
и почему всё удалось (или не удалось)

Случай на производстве №1 (типичный)
§ Сайт-новостник, написанный с использованием
UMI.CMS древней версии
§ Проблема: медленно работает админка, время
от времени начинает медленно работать всё
§ “Медленно” - страница генерируется десятки
секунд

Решение №1 (типичнее некуда)
§ Включить MySQL slow queries log
§ На всякий случай добавить в код вызовы
профайлинга (подойдет что угодно — например,
записывать скорость генерации страницы в лог, в
базу данных, в PINBA, в Graphite или еще куда-то)
§ Убедиться, что проблема в запросах к БД
§ Найти долгий запрос и посмотреть его query plan

Почему (не) работает (тоже типично)
§ Запрос сгенерирован ORM и делает фиг знает что
§ На самом деле, никто не знает, что именно он
делает, но он джойнит две огромных таблицы,
накладывает условия и сортирует результат
§ Индексы не работают, да и не могут
§ Такие сортировки — хуже всего для СУБД
§ Разработчики не знают, как быть

Альтернативная история
§ Можно хакнуть ORM и заменять “плохой” запрос на
“хороший” (резалтсеты должны совпадать)
§ Можно заменять “плохой” запрос на N “хороших”
§ Можно вообще выбросить ORM
§ ^ До этого в моей практике не доходило ни у кого
§ Можно выбросить плохой запрос — вдруг, никто не
заметит?

Случай на производстве №2 (тоже типичный)
§ Сайт по продаже чего-то
§ Когда приходят боты, чтобы парсить контент — всё
тормозит
§ “Боты” - это не Яндекс или Google, а какие-то
конкуренты, которые игнорируют robots.txt и
публично доступное API

Решение №2 (довольно типичное)
§ На сайте уже стоит платный NewRelic, который
умеет показывать проблемные места с
хорошей степенью детализации*
§ * Для некоторых языков программирования
§ Туда никто даже смотреть не стал — ботов
просто забанили по IP
§ Потому что нефиг тут шастать!

Случай на производстве №3 (уже было)
§ Сайт по продаже чего-то еще
§ Когда приходят боты, чтобы подбирать логины
клиентов — всё тормозит
§ Боты приходят слишком умные, и по IP их забанить
невозможно — они делают по одному запросу в
несколько минут с одного IP, не чаще

Решение №3 (довольно унылое)
§ Добавить в код профилирующих метрик
§ Убедиться в том, что тормозит шаблонизатор
§ Подумать, о замене шаблонизатора на нормальный
§ Оценить трудоемкость
§ Выделить общий для ботов шаблон (запросы по
HTTP/1.0, у нормальных клиентов — 1.1)
§ Побанить ботов по шаблону

Случай на производстве №4 (бывает)
§ B2B-сервис, ходящий за исходным данными для
расчетов на несколько внешних сайтов
§ Когда клиентов на сайт заходит много — наступает
отказ в обслуживании
§ Особенно, если в то же самое время какой-нибудь
из сайтов-партнеров отдает данные не слишком
быстро

Решение №4 (тоже унылое)
§ Добавить в код профилирующих метрик
§ Убедиться в том, что синхронные запросы к
внешним сервисам — это далеко не всегда
хорошая идея (никогда, на самом деле)
§ Добавить uwsgi воркеров (пусть их будет 150)
§ Скрестить пальцы

Альтернативная история
§ Убедить разработчиков переделать
чудо-приложение под асинхронную модель
взаимодействия с внешним тормозным
миром
§ ^ Как оно и должно быть по науке
§ Хочешь, чтобы что-то было сделано — сделай
сам

Найдите десять отличий
§ Во всех четырех историях есть общие черты:
§ Приложение работает неоптимально
§ Проблемы довольно очевидны
§ У разработчиков нет времени и/или
желания разбираться с проблемами
производительности
§ Технический долг (и энтропия) растет

Пара слов о социальном взаимодействии
§ Коллеги не будут вас любить:
§ Вы разрушаете то, что было создано ими
§ Они часто путают красоту и эффективность
§ Для них вы какой-то выскочка
§ У них есть более важные задачи, чем
общение с вами
§ Они знают бизнес-логику, а вы - нет

Случай на производстве №5 (Н.Е.Х.)
§ B2B-сервис из случая №4
§ ОДНАЖДЫ все перестало работать, а именно:
§ Загрузка процессора 100%
§ Несмотря на наличие SSD, база данных работает
не слишком быстро
§ А приложение — и того хуже

Решение №5 (магия дружбы)
§ Метаться, кричать
§ Найти, что поменялось в последние две недели
(ничего не поменялось)
§ После 30-40 минут раздумий выключить в BIOS
сервера Hyper-Threading и запретить
изменения частоты процессора
§ Выдохнуть

Почему это работает
§ Не будь у моей подруги с ее парнем опыта
работы с системами виртуализации — фиг
бы они вообще до этого додумались
§ Планировщику операционной системы тяжело
в ситуации, когда ядра меняют частоту,
к тому же, некоторые из ядер не существуют
на самом деле
§ Планировщик двигает задачи туда-сюда

Стоп, стоп, стоп!
§ Метаться, делать другие хаотические движения,
а через какое-то время решить проблему?
§ WTF?
§ Факты — гипотеза — ответные меры
§ Как возникла гипотеза?
§ Сбор фактов, потом их анализ:
§ echo t > /proc/sysrq-trigger

Немного когнитивной психологии
§ А почему именно echo t > /proc/sysrq-trigger,
§ А не другая странная и непонятная мера?
§ Исходим из известных нам фактов: что-то
занимает процессор
§ Как посмотреть, что именно?
§ В приложении — gdb thread apply all bt
§ Не видим ничего необычного — спустимся ниже

Случай на производстве №6 (сложный)
§ Сервис показа мобильной рекламы
§ Набор асинхронных сервисов на языке Perl
§ ОДНАЖДЫ ПРЯМО НА ПРОДАКШНЕ все
перестало работать, а именно:
§ Реклама перестала отдаваться, хотя партнеры
работают исправно
§ На сервисах в пределах одной машины - таймауты

Решение №6 (очевидное)
§ Обвешать вообще всё метриками профайлинга,
включая 3rd party асинхронные модули
§ Под “вообще всё” я имел в виду вообще всё
§ Найти магическую константу MAX_PER_HOST в
одном из модулей, который, вообще-то, был
задуман автором как эмуляция браузера
§ Увеличить ее с 4 до 400
§ Жить спокойно до следующего падения

Почему это работает
§ Потому что это и есть нормальный инженерный
подход, а именно:
§ Измерить (получить метрики)
§ Выработать план (проанализировать метрики)
§ Внести полезные изменения
§ Снова измерить

Почему было сложно
§ Несмотря на верность в целом, описанный
подход имеет ряд недостатков:
§ Невозможно предсказать время его
сходимости в общем виде
§ Он вообще может не сойтись в общем виде
по объективным причинам
§ Альтернативные отличные идеи (“всё
переписать”, etc)

Все переписать!
§ Итак, что лучше, Perl, Ruby или PHP?
§ В неравенстве Perl <> Ruby <> PHP, в конечном
счете, где-то должны находиться и вы сами
§ И если вы хуже и чем Perl, и чем Ruby, и чем
PHP — у вас не получится НИЧЕГО
§ Для CPU-bound задач берите что-нибудь, что
поближе к железу, чем перечисленные
не-JIT-enabled скриптовые поделки*
* есть всякие наработки и для них

Случай на производстве №7 (повсеместный)
§ Клиент хостился на Хетцнере
§ ОДНАЖДЫ в зеркале сломался первый диск
§ Через некоторое время сломался и второй
§ Когда все это заметили — данные уже были
немножко потеряны

Решение №7 (необходимое)
§ Завести бэкапы!
§ При чем же тут performance?
§ Pooling, compression, deduplication...
§ ^ BackupPC отлично подходит, но...
§ rsync очень сильно нагружает дисковую
подсистему машины-клиента
§ Опция --bwlimit=500 (или сколько можете)

Почему это (не) работает
§ Зачем нужны бэкапы?
§ Затем, чтобы однажды ими воспользоваться,
например...
§ Развернуть систему из бэкапа целиком!
§ Бэкап сотен гигабайт будет разворачиваться
несколько суток
§ ^ Для начала просто задумайтесь об этом

Выводы
§ Старайтесь всегда точно знать, где вы находитесь
§ Измеряйте
§ Планируйте
§ Не паникуйте
§ В сложной ситуации делайте что-нибудь красиво
§ Все хорошо будет

С вами был Александр Чистяков,
главный инженер Git in Sky
alex@gitinsky.com
http://gitinsky.com
http://meetup.com/DevOps-40
Пожалуйста, ваши вопросы.
Спасибо за внимание!

Performance engineering stories from #fdminicon Saransk

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Performance engineering stories from #fdminicon Saransk

Similaire à Performance engineering stories from #fdminicon Saransk (20)

Plus de Alex Chistyakov

Plus de Alex Chistyakov (20)

Performance engineering stories from #fdminicon Saransk