Основы построения масштабируемых

высоконагруженных веб-проектов

Семинар (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. Базовые компоненты и архитектуры

Скорость доступа к данным

#00 #01cache

CPU

Memory

cache

>1e-5 s

<1e-9 s< 1e-6 s

>1e-4 s

“HARD” DISK

FS cache

Network

типичные цифры

Диск – слабое звено• Если что-то лежит на диске, не меняется и часто

читается – оно мгновенно в 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: концепт

nginx

Apache mod_php, mod_perl, mod_python FastCGI

«легковесный» сервер (LWS)

«тяжеловесный» сервер (HWS)

«статика», SSI, perl «динамикa»

«быстрые» и «медленные» клиенты

[front/back]end:масштабирование

SLB

F

F

F

B

B

B

B

N/Nf

N/Nb • F и В – «логический» уровень• F и B гомогенны (обслуживание, замена)• F и B могут быть разными «физическими» серверами или одним сервером (единый однородный «слой» серверов, на каждом LWS и HWS)

Масштабирование

зара

бота

ли

потратили

линейное

эфф

ективность

Масштабирование веб-кластера

• Гомогенность: при большом числе серверов можно не разделять front- и back-endы

• Независимость компонент• Минимум общих ресурсов (share-nothing => share

accurately)• Некоторые распространённые ловушки:

– общие данные на nfs (сессии, код) => локальные копии кода, сессии в memcached

– локальный кеш => общий кеш– что-то пишем в базу realtime => сделать тяжелые

операции асинхронными

nginx: load balancing

upstream backend { server backend1.example.com weight=5; server backend2.example.com:8080; server unix:/tmp/backend3;}

server { location / { proxy_pass http://backend; }}

nginx: fastcgiupstream 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)• Кеширование веб-сервером (прокси-кэш)• Объектный кеш: сериализованные данные• «Некогерентный»(несогласованный) кеш

Несогласованность локального кеша

frontend

LCdata

data

backend

backend

LC

Global Cache Global Cache

+

+

Global Cache

• 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

memcached

Кластеризация сессий

• 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/php-fpm

• Конец 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) больше для приложений с интенсивной записью

Black hole«dummy» slave

Server#1

filtered binlogдля slavesServer#2

MasterServer#1

MySQL: replication filtering

• Master: binlog-[do|ignore]-db• фильтр «ручками»: SET SQL_BIN_LOG=0• Slave: replicate[|-wild]-[do|ignore]-[db|table]• BLACKHOLE engine: «черная дыра», no data

Relay slaves

relayslave

slave slave slave slave

master

• --log-slave-updates• топология

– 1 relay, M slaves– M (relay + 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: концепт

“client”

“client”

“server”

“server”

request

result

MessageQueue

Consumersmessage

синхронное, “point-to-point”

асинхронное, “publisher-subscriber”

database

“publisher” “subscriber”

1) enqueue/dequeue2) publish 1) enqueue/dequeue

2) subscribe/receive

MQ на БД

Универсальная очередь

• {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%

Dev

elop

men

t (tim

e)

Support (time)

• маленькие проекты• начало проекта

«динамичные» проекты

«загнанные», неразвивающиеся проекты, «динозавтры»

100%

100%

Кривой «технологический» менеджмент приводит к тяжелым болезням роста

Разработка с учётом дальнейшей поддержки

• бизнес-идея

• модель

• варианты реализаций

• верификация

• планирование

• производственные работы

René Magritte   Les amants

наиболее распространенная ошибка: не видим, что происходит на «физическом» уровне

например, какие операции происходят в процессе обработки запроса

Что нужно видеть?• вспомните о моделях СМО• запросы к СУБД и внешним

сервисам, прочие «блокирующие» или «тяжелые» операции

• простые измерения «ручками» - таймеры

• ошибки (любые!)

• время между возникновением внештатной ситуации и её исправлением должно быть минимальным

• жизненный цикл проблемы

WTF? !

неопределённость предсказуемость

;)

визуализация интеллект команды

Поддержка

Development: визуализация потенциально узких мест (debug toolbar, логи), тестыProduction: мониторинг (расширенный), измерение производительности в реальном времени, сбор и анализ логов

Инструменты

«пожалуйста, сообщите нам об этом» и «не забудьте указать адрес страницы»

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

Error_log!

плохо

хорошо

Мониторинг

• измеряй и властвуй• «тупой» мониторинг серверов не даёт нужной

информации• нужен мониторинг приложения и компонент• измерение качества архитектуры• открытость: общее видение системы у всех

членов команды• снижение стоимости владения, повышение

качества поддержки

req/sec

average time

• Scripts• Virtual hosts• Physical servers

PINBA: мониторинг в режиме реального времени

Краткая история одной аварии с иллюстрациями

время обработки запроса

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}

• SQL: “сырые” данные или отчеты• Отчеты – это отдельные таблицы,

обновляются «на лету»• Базовые отчёты (~10): по системе, по

скриптам, по хост+скрипт…• Отчеты по произвольным тегам

(ENGINE=PINBA COMMENT='report:foo,bar‘) => {script_name, foo_value, bar_value, count, time}

• http://pinba.org – много примеров

PINBA: Отчёты

Например, так «протухает» код

Наимедлейшие из медленных

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 17ITEM 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)

• довольно медленно• не всё (по крайней мере, в старых

версиях)• трактуйте результаты как

статистические "сэмплы"• или увеличивайте статический буфер в

исходниках

• Callgrind и т.п. – хорошо, но много• Снижаем размерность: мерить только то, что

потенциально «тормозит» (disc, запросы к «сервисам» – db, memcached, с/c++,…)

• И ещё average time, CPU, число запросов по группам

• Автоматически добавим в конец любой страницы• Devel: всегда включен • Production: можем писать в лог

auto debug & profiling (1/1)

• что происходит на «физическом» уровне• визуализация СМО• визуализирован «cost» любого ответа с бэкенда• легко ловить нетривиальные «косяки»

– при рефреше нет dbq->memq– много «get’ов» вместо «multiget’a» (или insert’a)– межсерверные транзакции– несколько разных соединений с одной и той же базой– cache-set при "лежащей" базе/ошибке– чтение со slave данных, только что записанных на

master– и так далее…

auto debug & profiling (2/2)

• Меряйте больше!• с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• Если Вы хотите получить

презентацию – заполните, пожалуйста анкету

• Буду крайне признателен за любые отзывы и пожелания, особенно критические