Презентация - 2011

Основы построения
масштабируемых
высоконагруженных веб-проектов
Семинар (8 часов)
Алексей Рыбак
Badoo Development (badoo.com)
Задачка на разминку
Пусть в нашем распоряжении имеется
некоторый веб-сервер. Выполняя запросы,
часть времени он проводит в ожидании ответов
от удаленного сервера базы данных, остальное
время занимает работа процессора. Считая, что
ресурсы базы данных и пропускная способность
сети – неограниченны: при каких условиях
сервер может отдавать 1000 запросов в
секунду?
Наш план
• Введение
• Базовые компоненты и
архитектуры
• Управление и поддержка больших
проектов
• Избранное по заявкам, обсуждение
проблем, любые ваши вопросы
0. Введение
Кто зачем пришёл (1/2)
•
•
•
Не очень хорошо знаком с
архитектурой и принципами
масштабирования много-серверных
систем, хочу узнать основы
В нашем проекте уже несколько
серверов, хочу узнать, как расти
дальше
Мне всё более-менее понятно, хочу
систематизировать знания и получить
консультации по ряду вопросов
Кто зачем пришел (2/2)
•
•
•
•
•
программист
администратор
руководитель группы/отдела
всё вышеперечисленное
ничего из выше перечисленного
Ещё пару вводных слов
• Стек технологий – LNMP
• Многие проблемы носят
фундаментальный характер
• Постараемся «перезагрузить» мозг
• Будет много живого общения
• Не стесняйтесь прерывать и
задавать вопросы
• Будет много флипчарт-сессий
Почему “перезагрузить” мозг?
Как программирует «продвинутый новичок»?
1. Осознаёт предметную область (бизнесанализ, пользовательские сценарии)
2. Создаёт «модель» и «над-язык» (данные,
сущности, операции над ними)
3. Пишет код, внося изменения в над-язык
(реже – пересматривая модель)
•
•
•
В п.2 мы кое-что забыли
Модель не имеет системного каркаса
Нужна верификация модели с системной
точки зрения – системное проектирование
Проектирование (1/2)
• Многоуровневый анализ
• Логический уровень: модель данных
• Software-уровень: ОС, ФС, вебсервера, базы данных и другие
базовые компоненты
• Hardware-уровень: диски, память,
сеть, CPU …
• У всех компонент – и программных, и
железных - есть свои важные
особенности, которые играют
колоссальную роль
Проектирование (2/2)
• Любой архитектор обязан иметь
навыки системного администрирования
• Правильное «объединение» всех
компонент
• О масштабировании нужно заботиться
заранее
• Всё это - не преждевременная
оптимизация
Сети массового обслуживания
• Массовый поток требований случайного
характера
• Телефонные станции, супермаркеты,
автомагистрали, call-центры, ремонтные
предприятия…и конечно интернет-проекты!
• Первая работа - А.К.Эрланг, «The Theory of
Probabilities and Telephone conversations»,
1909
• Не пугайтесь, не будем углубляться в
математику, главное – «чувствовать» модели
Базовая модель
очередь
канал обслуживания
обслуженные заявки
требования
переполнение: отказы
Характеристики:
• число требований в ед. t
• пропускная способность (число обслуженных требований)
• среднее время обслуживания, распределение (моменты)
• число отказов в ед. t
Важное свойство: нелинейная (стремительная) «деградация»
N-канальная СМО с ожиданием
каналы (N)
очередь
требования
Ищите подобные модели в своих проектах.
Это - архитектура вашего бизнеса.
Остальное – в-общем, вторично.
обслуженные
заявки
Цели изучения СМО
Повышение эффективности:
• Пропускная способность
• Время ожидания
• Совокупная стоимость
Попробуем рассчитать на
«пальцах» проект
•
•
•
•
•
•
•
•
•
•
•
Суточная аудитория - 10 млн человек
Оператор – процесс веб-сервера
Требование – запрос от браузера
Расчёт крайне грубый
Время на один запрос – 0.1 сек
75% загрузка: 24 час X 45 мин X 60 сек = 64800 сек
Всего запросов на оператора 64800*10 = 0.648 млн
Каждый пользователь делает 30 кликов
Всего запросов 30*10млн = 300 млн
На один сервер – 10 процессов
Число серверов 300 / (10*0.648) = 46.2
Этот расчёт – неверный 
• Не учитываем «случайность» распределения
• Не учитываем структуру запросов (1 хит != 1
запрос)
• Не учитываем суточное распределение
• Для UGC 10 млн на практике – это сотни, а то
и тысячи серверов
• В жизни системы куда сложнее, поэтому иной
раз проще не считать, а сразу проводить
измерения
Базовые софтверные
компоненты проекта
• Веб-сервер
• Сервер приложений (может быть
интегрирован в веб-сервер)
• СУБД
• Кеш-сервер
• Цель: «прокачать» как можно больше
хитов за как можно меньшие деньги
заработали
Масштабирование
линейное
нелинейное
линейное, но с плохой
производительностью
потратили
Говорят, что scaling и performance – разные вещи.
Это не совсем так. Это всё про деньги. Scaling – класс кривой,
Performance – её характер (например, угол наклона)
1. Базовые компоненты и
архитектуры
Скорость доступа к данным
типичные цифры
Memory
#00
#01
cache
cache
CPU
<1e-9 s
“HARD” DISK
>1e-4 s
< 1e-6 s
FS cache
Network
>1e-5 s
Диск – слабое звено
• Если что-то лежит на диске, не меняется и часто
читается – оно мгновенно в FS cache и доступ к нему
такой же быстрый как к памяти
• Считать по сети из памяти удаленной машины чаще
быстрее, чем с локального диска
• Читать/писать последовательно и много –
значительно выгоднее
• Пакетная запись на диск: накопили в памяти и
сбросили. Можно вовсе асинхронно (возможны
потери).
• Будущее – за SSD
Linux: параллелизм
• Процессы (processes)
• Трэды (threads)
• Для осуществления «параллельной»
работы необходимы переключения
между режимами ядра и задачи переключение контекста (context switch)
• Ключевой момент для большинства
классов серверов – модель обработки
сетевых соединений
Модели обработки сетевых
соединений
• Process per connection
– CGI: fork per connection
– Pooling: Apache (v.1, mpm_prefork – min, max,
spare), PostgreSQL+pgpool, PHP-FPM …
• Thread per connection
– Pooling: Apache (mpm_worker – min, max, spare),
MySQL(thread_cache)
• FSM (finite state machine)
–
–
–
–
«современные» ядра: kqueue, epoll
общий интерфейс libevent, libev
FSM + process pooling: nginx
FSM + thread pooling: memcached v>1.4
Обработка сетевых
соединений веб-сервером
• process-per-connection (apache 1, 2
mpm_prefork)
• медленные клиенты = куча процессов
• thread-per-connection (apache 2 mpm_worker)
• медленные клиенты = куча потоков
• Keep-Alive – 90% неактивных клиентов
• накладные расходы – context switches, RAM
• “lightweight“ (nginx, lighttpd, …)
• nginx (не нгинкс, не нжинекс и даже не
нгинекс, а эн-жин-ыкс (engine-x)!)
flipchart case #1
• Отдача статики веб-сервером
Почему nginx?
• 1 master + N workers (10**3 – 10**4 conn)
• N: CPU, вероятность блокирующих операций
• FSM + поддержка эффективных методов работы с
соединениями
• большое внимание к скорости и качеству кода
• минимум копирования данных
• Keep-Alive: 100Kbytes active / 250 bytes inactive
• очень удобная конфигурация
• даже есть встроенный кастрированный perl
• sysoev.ru, apache-talk@lexa.ru
Типичная конфигурация
веб-сервера
• Что делает сервер?
• Выполняет код
• Обслуживает клиента
• Разве повар принимает заказ?
• Разные задачи, разделить
• Двухуровневая схема (frontend/backend)
• nginx + Apache + mod_php, mod_perl, mod_python
• nginx + FCGI (например, php-fpm)
[front/back]end: концепт
«тяжеловесный» сервер (HWS)
«легковесный» сервер (LWS)
nginx
«быстрые»
и «медленные»
клиенты
«статика»,
SSI, perl
Apache
mod_php,
mod_perl,
mod_python
FastCGI
«динамикa»
[front/back]end:масштабирование
N/Nb
N/Nf
B
F
B
SLB
F
F
B
B
• F и В – «логический»
уровень
• F и B гомогенны
(обслуживание, замена)
• F и B могут быть
разными «физическими»
серверами или
одним сервером
(единый однородный
«слой» серверов,
на каждом LWS и HWS)
заработали
Масштабирование
линейное
потратили
Масштабирование веб-кластера
• Гомогенность: при большом числе серверов можно
не разделять front- и back-endы
• Независимость компонент
• Минимум общих ресурсов (share-nothing => share
accurately)
• Некоторые распространённые ловушки:
– общие данные на nfs (сессии, код) => локальные
копии кода, сессии в memcached
– локальный кеш => общий кеш
– что-то пишем в базу realtime => сделать тяжелые
операции асинхронными
nginx: load balancing
upstream
server
server
server
}
backend {
backend1.example.com weight=5;
backend2.example.com:8080;
unix:/tmp/backend3;
server {
location / {
proxy_pass http://backend;
}
}
nginx: fastcgi
upstream backend {
server www1.lan:8080 weight=2;
server www2.lan:8080;
}
server {
location / {
fastcgi_index index.phtml;
fastcgi_param [param] [value]
...
fastcgi_pass backend;
}
}
Отдача защищенной статики
• через скрипт – плохо («тяжелый» процесс на
каждого клиента)
• X-Accel-Redirect («тяжелый» процесс быстро
проверяет, можно ли отдавать, и даёт «указание»
веб-серверу)
• модули (URL-сертификаты)
• http://sysoev.ru/nginx/docs/http/ngx_http_secure_link_
module.html
• http://wiki.nginx.org/NginxHttpAccessKeyModule
Кеширование
• «память»-10-9-10-6,«сеть»-10-4,«диск»-10-3 и выше
• страницы(+картинки и т.д.), HTML-блоки, «объекты»
• эффективность: соотношения hit/miss/set, «кешпамять на одного юзера»
• HTML-блоки: не всегда эффективно
• А был ли мальчик? (if-modified-since)
• Кеширование веб-сервером (прокси-кэш)
• Объектный кеш: сериализованные данные
• «Некогерентный»(несогласованный) кеш
Несогласованность локального кеша
LC
frontend
backend
LC
data
data
backend
Global Cache
Global Cache Global Cache
memcached
• danga.com/memcached/ (LiveJournal)
• «глобальный» кеш-сервер
• оптимизированная работа с памятью (slab alloc,
object versions) и сетевыми соединениями (libevent)
• Крупнейшие мировые проекты: LJ, slashdot, digg,
facebook (десятки терабайт)
• идеален для сессий, объектного кеша
• multi-get, stats (get, set, hit, miss + slab info)
• легко масштабировать
• i = crc32(key)%N и вариации
• время жизни, LRU и пролонгация
• неидеально написан, особенно после facebook
Кластеризация сессий
• http-conn: кидаем клиента на один сервер в
рамках сессии (производительность,
неравномерная нагрузка)
• NFS: никакая масштабируемость, SPOF,
“nfs stale handle”, скорость
• Database: SPOF, скорость (лучше: heap,
cluster)
• Memory: высокая скорость, почти линейная
маcштабируемость. Memcached, Zend
Session clustering
flipchart session
• Есть ли вопросы?
• Case#2: база знаний (википедия)
• Case#3: медиа-хранилище (фото-видеохостинг, файлопомойка)
Компоненты (cont.)
Что ещё входит в базовые компоненты:
• Application servers: обычно
интергированы в веб-сервер
(исключение - FCGI). Пару слов про
PHP-FPM и особенности PHP
• СУБД (MySQL)
Приложения
•
•
•
•
Приложения на скриптовых языках
«Собирают» динамические страницы
Много блокирующего IO
Часто создают существенную нагрузку
на CPU
• В качестве примера рассмотрим PHP
Особенности PHP
• Acceleration (APC, xcache, ZPS,
eAccelerator)
• memory & CPU usage (zval:
C(1M), Perl(10M), PHP(20M))
• modules rock!
• FCGI (fpm)
FPM
• PHP-FPM: PHP FastCGI process
manager
• Менеджер FastCGI-процессов для PHP
• Архитектура сервера напоминает nginx
(master + N workers)
PHP-FPM: эксплуатация
• Плавно обновляться, не теряя
соединения
• Видеть все ошибки
• Автоматически реагировать на
подозрительное поведение воркеров
(выход, тормоза, массовые падения)
• New: динамическое количество
воркеров (apache-like)
PHP-PFM: основные
возможности
• Плавный перезапуск/обновление
кода
• Мастер ловит stderr воркеров
• Автоматический трейсинг и
завершение работы медленных
воркеров
• Аварийный перезапуск при
массовом падении воркеров
PHP-PFM: доп. возможности
• Error header снимает проклятие
пустой белой страницы (200 OK на
ошибку)
• fastcgi_finish_request() – отдать
output клиенту, но продолжить
работу (сессии, статистика и т.д.)
• Accelerated upload (поддержка
request_body_file - nginx 0.5.9+)
FPM на пути к PHP
• Mamba, Badoo (2004-2006): набор
разрозненных патчей
• Андрей Нигматулин. 2007: один патч поверх
PHP (5.3.0-0.5.12, http://php-fpm.org)
• 2009: проект отнимает массу времени,
«берёт руководство» Michael Shadle,
коммитит dreamcat4 http://launchpad.net/phpfpm
• Конец 2009 … Антон Довгаль, Jerome Loyet FPM наконец в PHP! Отдельный SAPI, 5.3.*.
• Groups: highload-php(en|ru)@googlegroups.com
Базы данных
• Самый «капризный» компонент
• Пофантазируем о том, как бы мы
разрабатывали СУБД
• Поймем «модель» обслуживания
• Поговорим о масштабировании
Вы - БД и выполняете SELECT
в первом приближении:
• установить соединение,
выделить ресурсы
• скорость, память на
стороне сервера…
• получить запрос
• проверить кэш запросов
• разобрать SQL-выражение
• bind vars, stored proc…
• получить данные
• index lookup, buffer cache,
disk read
• отсортировать данные
• in-memory, filesort, key buffer
• отдать результат
• очистить ресурсы, закрыть
соединение
MySQL: кратко о самом важном
•
•
•
•
•
•
•
•
•
•
•
•
•
Движки - MyISAM, InnoDB, Memory(Heap); Pluggable
Блокировка: MyISAM на уровне таблиц, InnoDB на уровне
строк
«Ручные» блокировки: select lock, select for update
Индексы: B-TREE, HASH (no BITMAP)
point->rangescan->fullscan;
fully matching prefix; innoDB PK: clustering, data(“using index”),
myisam key cache, innodb buffer pool
dirty buffers, transaction logs: innodb_flush_trx_log_at_commit
many indexes – heavy updates
sorting: in-memory (sort buffers), filesort
USE EXPLAIN! Using temporary, using filesort
innodb_flush_method = O_DIRECT
лучше использовать маленькие таблицы вместо одной
большой
Проектирование
•
•
•
•
•
•
типы приложений: OLAP/OLTP
обычно OLAP – MyISAM, OLTP - InnoDB
представьте, что вы – БД
какие операции следует выполнить?
нельзя ли заменить одни операции другими?
нельзя ли вовсе отказаться от каких-либо
операций?
• хороший и правильный запрос к БД – тот,
которого нет ;)
• не бойтесь денормализации
• позаботьтесь о масштабировании заранее
Денормализация
• шашечки или ехать? 
• денормализация
– лишний join
– сортировка
– группировка
– фильтрация
– агрегация из разных источников
– горизонтальное разбиение
таблиц
• Кейсы
– Case#4: Счётчики
– Case#5: Деревья в БД
– Case#6: Поисковый индекс
Некоторые «приёмчики»
•
•
•
•
multi-операции
On duplicate update
table switching (rename)
memory tables как результаты
промежуточных вычислений
• updated = updated
СУБД: масштабирование
•
•
•
•
•
•
•
•
пользовательский контент
ОЧЕНЬ много IUD-операций
линейное масштабирование
репликация или кластеризация
(sharding)
эксплуатация, стоимость владения
отказоустойчивость, мин. SPOF
балансировка нагрузки
удобство обслуживания
Масштабирование
• Scale up vs Scale out
• Репликация (очень нелинейное)
• Вертикальное: по задачам (по
таблицам)
• Горизонтальное: по «основным»
сущностям – пользователям,
документам и т.д. – sharding
Репликация «на пальцах»
• Был один сервер w/r << 1
• Добавили ещё один, 100% рост
• Но w/r на мастере растёт – w не
масштабируются
• Чем больше серверов – тем хуже
• Социальные сервисы – много операций
записи
Проблемы репликации
• Линейна только при очень малом числе
серверов (writes не масштабируются)
• Очень много данных
• Неэффективная утилизация ресурсов (копии
данных на диске и в кеше)
• Особенности реализации (MySQL: раздача
лога, один тред и т.д. – и порождённые
извращения)
G: 1) больше, если «тяжелее» writes
2) больше для приложений с интенсивной записью
MySQL: replication filtering
• Master: binlog-[do|ignore]-db
• фильтр «ручками»: SET SQL_BIN_LOG=0
• Slave: replicate[|-wild]-[do|ignore]-[db|table]
• BLACKHOLE engine: «черная дыра», no data
Master
Server#1
Black hole
«dummy» slave
Server#1
filtered binlog
для slaves
Server#2
Relay slaves
• --log-slave-updates
• топология
master
slave
– 1 relay, M slaves
– M (relay + slave)
– и вариации на тему
relay
slave
slave
slave
slave
Масштабирование
заработали
линейное
потратили
Sharding: разделение данных
• Статическое (детерминированное), num_key%n_serv,
crc32(md5(str_key))%n_serv, «первая буква логина» и т.д.
• Это практически неуправляемо
• Математические трюки: магические 12, 24 и прочие
– всё равно плохо
• «Динамическое»: добавление новых машин,
замена, перенос, балансировка – без изменения
кода
• Минус динамического: часть приложения, которая
отвечает за адресацию – SPOF, м.б. высокая
нагрузка
Sharding: прозрачность
• Минимум головной боли при поддержке
• Управление разделением данных без
вмешательства в код
• «Проксирование»
• Координирующий сервис (отвечает на вопрос
“где?”)
• Динамическая координация менее прозрачна,
но архитектурно более правильна
• «Виртуализация» физических координат
{server, db_suffix, table_suffix} => storage_id
где?
Координатор
WebApp
Node # 1234
data
Storage nodes
Case#7: Sharding
• flipchart!
• самый сложный для понимания материал
• не стесняйтесь задавать вопросы!
MySQL в Badoo (1/2)
• минимизировать совокупную стоимость владения
• максимально гибко контролировать все
подсистемы
• минус в теории - плюс на практике
• MySQL не даёт "нагородить" сложные
зависимости между данными
• MySQL не диктует неэффективную или сложно
управляемую архитектуру
• многие проблемы больших проектов схожи и не
зависят от выбора СУБД
• cost-oriented development
MySQL в Badoo (2/2)
• InnoDB
• никаких сложных запросов, FK, триггеров и
процедур
• "продвинутая" репликация
• "продвинутый" апгрейд схем данных
• шардинг - виртуализация "физических"
координат {serverX, dbY, tableZ} => shard_id
• никаких "прозрачных" прокси
• динамическая координация клиентов
• очереди событий на базе MySQL
• архитектура не меняется пятый год (рост с 0 до
80 млн пользователей, несколько ДЦ)
Очереди
• Если шардинг – это разделение в
пространстве, то очередь – разделение во
времени
• Если что-то можно сделать потом – пусть
клиент не ждёт
• Легко сделать «универсальный» фреймворк
для работы с очередями
RPC
•
•
•
•
RPC = Remote procedure calls
Синхронно: удаленные сервисы
Асинхронно: очереди
Вариации: логически синхронно,
физически асинхронно
• Проблема транзакционной целостности
RPC/MQ: концепт
request
“client”
result
“server”
синхронное, “point-to-point”
асинхронное, “publisher-subscriber”
“client”
“server”
message
Message
Queue
Consumers
MQ на БД
“publisher”
“subscriber”
database
1) enqueue/dequeue
2) publish
1) enqueue/dequeue
2) subscribe/receive
Универсальная очередь
•
•
•
•
•
{event_class, event_data}
Внутри базы – нет проблем с транзакциями
Publisher/Subscriber
Диспетчеризация событий
Топология: (де)централизованная доставка и
обработка
Case#8: очередь
• flipchart!
• модель данных
• сбор данных
• failover
• децентрализованная очередь
Особенности архитектур
• flipchart!
• Case#9: Сетевое СМИ
• Case#10: Социальная сеть
Кризисы роста
•
•
•
•
Один сервер
Несколько серверов (скажем, десять)
Много серверов (сотни, тысячи… много ДЦ)
И ещё чтобы не очень падало и удобно
поддерживалось
• Переход между уровнями обычно
сопровождается «кризисом»
• Ключевое значение играет масштабируемая
архитектура
Масштабируемая архитектура
• Независимые или слабо-связанные
веб-сервера
• Горизонтальное разделение данных
• RPC (сервисы, очереди)
• Обслуживание без вмешательства в
код
Некоторые ловушки
• Высокая степень связанности (данных,
процедур, компонент) – плохое
масштабирование
• Полу-решения (накапливание рисков)
• Плохо управляемые инструменты
• Горе от ума (решения с позиций
«теоретиков», вредные с инженерной точки
зрения). Классический пример - ORM
Что читать?
• RTFM ;)
• Слайды с конференций – mysql, velocity, osconn.
tutorials, архитектура wikipedia, fotolog, youtube … highscalability.com
• Блоги - особенно тех, кто занимается консалтингом
http://jcole.us/blog/,
http://www.mysqlperformanceblog.com/
фид http://www.planetmysql.com – сборная солянка
• Books - немного  High Performance MySQL (2nd ed.
Shwartz, Zaitsev & co), Building Scalable Web Sites
(Henderson), Scalable Internet Architectures
(Schlossnagle), Настройка производительности UNIXсистем (Мусумеси, Лукидес) – вообще о
производительности, книги издательства MySQL AB
Press (руководство администратора и тд); Managing
gigabytes, Architecture of a Database System
2. Управление и поддержка
больших проектов
Большие проекты
• Миллионы пользователей
• 24x7
• «Много» серверов
• Многозвенная архитектура
• Мегабайты кода
• Зоопарк!
• Быстрый или мертвый
«Технологические» риски
• тормозим (или лежим)
• медленно реагируем на ошибки (не
реагируем или совсем не видим).
• плохо масштабируемся (или вообще не
масштабируемся)
• медленно меняемся (или не способны
меняться)
• высокая стоимости владения, низкий возврат
инвестиций и т.д.
development+support=100%
100%
• маленькие проекты
• начало проекта
Development (time)
«динамичные» проекты
«загнанные»,
неразвивающиеся
проекты,
«динозавтры»
Support (time)
100%
Кривой
«технологический»
менеджмент
приводит к тяжелым
болезням роста
Разработка с учётом
дальнейшей поддержки
• бизнес-идея
• модель
• варианты реализаций
• верификация
• планирование
• производственные работы
наиболее распространенная
ошибка: не видим, что
происходит на «физическом»
уровне
например, какие операции
происходят в процессе
обработки запроса
René Magritte Les amants
Что нужно видеть?
• вспомните о моделях СМО
• запросы к СУБД и внешним
сервисам, прочие «блокирующие»
или «тяжелые» операции
• простые измерения «ручками» таймеры
• ошибки (любые!)
Поддержка
• время между возникновением внештатной
ситуации и её исправлением должно быть
минимальным
• жизненный цикл проблемы
визуализация
WTF?
неопределённость
интеллект команды
!
;)
предсказуемость

Инструменты
Development: визуализация потенциально
узких мест (debug toolbar, логи), тесты
Production: мониторинг (расширенный),
измерение производительности в реальном
времени, сбор и анализ логов
Error_log!
плохо
«пожалуйста, сообщите нам об этом» и «не
забудьте указать адрес страницы» 
хорошо
«Все ходы записаны. Мы уже изучаем, почему такое
могло произойти. Приходите ещё, мы обязательно
исправим все косяки»
Мониторинг
• измеряй и властвуй
• «тупой» мониторинг серверов не даёт нужной
информации
• нужен мониторинг приложения и компонент
• измерение качества архитектуры
• открытость: общее видение системы у всех
членов команды
• снижение стоимости владения, повышение
качества поддержки
PINBA: мониторинг в режиме
реального времени
req/sec
average time
• Scripts
• Virtual hosts
• Physical servers
Краткая история одной аварии
с иллюстрациями
время обработки запроса
WTF?
Теперь нам известны скрипты, периодичность,
и более-менее ясно, где копать дальше
Анализ данных
•
•
•
•
найти, где копать
включить детальную отладку
анализ графиков
пики, периоды, характерные
масштабы
• распределения, достаточное
качество
Идеальный для саппорта
софт меряет сам себя
Эксплуатация веб-кластера
• Число запросов (полное, на сервер …)
• Время ответа (среднее, распределение,
по скриптам, по серверам …)
• Использование ресурсов (rusage)
• Непрерывный мониторинг в реальном
времени
• Качество приложений - что меняется при
релизах?
PINBA: архитектура
• Клиентский модуль для PHP
• Для любого запроса собираем
script_name, host, time, rusage …
• При завершении отправляем UDP
• И так со всех машин веб-кластера
• Серверный тред внутри MySQL (v.
5.1.0+)
• SQL-интерфейс ко всем данным
PINBA: данные
• request: script_name, host, domain, time,
rusage, mempeak, output size, timers
• timers: время + пары “ключ (тэг) –
значение”
• пример: 0.001 sec; {group => db::update,
server => dbs42}
PINBA: Отчёты
• SQL: “сырые” данные или отчеты
• Отчеты – это отдельные таблицы,
обновляются «на лету»
• Базовые отчёты (~10): по системе, по
скриптам, по хост+скрипт…
• Отчеты по произвольным тегам
(ENGINE=PINBA COMMENT='report:foo,bar‘)
=> {script_name, foo_value, bar_value, count,
time}
• http://pinba.org – много примеров
Например, так «протухает» код
Наимедлейшие из медленных
Memcached: статистика
•
•
•
•
•
•
•
Stats
Stats slabs
Stats items
Stats cachedump
Req/sec
Hit/miss
Bytes read/written
Memcached: stats
Cachedump (1/4)
17й слаб = 128 K
stats cachedump 17
ITEM uin_search_ZHJhZ29uXzIwMDM0QGhvdG1haWwuY29t [65470
b; 1272983719 s]
ITEM uin_search_YW5nZWw1dHJpYW5hZEBob3RtYWlsLmNvbQ==
[65529 b; 1272974774 s]
ITEM unreaded_contacts_count_55857620 [83253 b; 1272498369 s]
ITEM antispam_gui_1676698422010-04-17 [83835 b; 1271677328 s]
ITEM antispam_gui_1708317782010-04-15 [123400 b; 1271523593 s]
ITEM psl_24139020 [65501 b; 1271335111 s]
END
Cachedump (2/4)
•
•
•
•
•
•
Выдираем из cachedump имя группы
Распределение по размеру (аномалии)
Просто ошибки
Или пора включать архивацию
Или разбивать объекты
Для memcached большой объект это очень
плохо: все ждут
Cachedump (3/4)
• Выдираем из cachedump имя группы
• Распределение по времени доступа
• Можно тоньше играть со временами
хранения
• t жизни >> t времени доступа
• Уменьшить время хранения для данной
группы
Cachedump (4/4)
• довольно медленно
• не всё (по крайней мере, в старых
версиях)
• трактуйте результаты как
статистические "сэмплы"
• или увеличивайте статический буфер в
исходниках
auto debug & profiling (1/1)
• Callgrind и т.п. – хорошо, но много
• Снижаем размерность: мерить только то, что
потенциально «тормозит» (disc, запросы к
«сервисам» – db, memcached, с/c++,…)
• И ещё average time, CPU, число запросов по
группам
• Автоматически добавим в конец любой страницы
• Devel: всегда включен
• Production: можем писать в лог
auto debug & profiling (2/2)
•
•
•
•
что происходит на «физическом» уровне
визуализация СМО
визуализирован «cost» любого ответа с бэкенда
легко ловить нетривиальные «косяки»
– при рефреше нет dbq->memq
– много «get’ов» вместо «multiget’a» (или insert’a)
– межсерверные транзакции
– несколько разных соединений с одной и той же базой
– cache-set при "лежащей" базе/ошибке
– чтение со slave данных, только что записанных на
master
– и так далее…
Что измерять
•
•
•
•
Меряйте больше!
сonn/req, cpu/mem usage для всех сервисов
Статистику с баз, apache/nginx…
Memcached: get/miss по группам ключей,
расширенная статистика (slabs + items)
• la, cpu/mem usage с серверов
• Характерные времена загрузки на клиенте
(DOM_READY, ON_LOAD) – МЕГА ВАЖНО
• network…
Вопросы на выбор
•
•
•
•
•
•
•
•
•
•
•
задавайте любые 
нагрузочное тестирование
программа пост-анализа мониторинга
сбор и обработка логов
выкладка в бой
среда (devel, stage, production)
откаты/накаты схем
SQL vs NoSQL
профилирование скриптов
найм, собеседование
минусы “Agile”
Спасибо!
• alexey.rybak@gmail.com
• Если Вы хотите получить
презентацию – заполните,
пожалуйста анкету
• Буду крайне признателен за любые
отзывы и пожелания, особенно
критические