Wednesday, October 27, 2010

HighLoad++ 2010

На днях в Москве прошла "конференция разработчиков высоконагруженных систем" Highload++, участником котрой мне посчастливилось стать. Ниже я хочу кратко пройтись по докладам, которые посетил в рамках конференции, выделив в них интересные на мой взгляд моменты.



День 1


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


Perfomance tweaks and tools for Linux


Довольно интересный доклад об утилитах Linux, котроые можно использовать при отладке приложений.

  • lsof - утилита для получения списка открытых файлов;

  • strace - утилита для просмотра системных вызовов и сигналов, происходящих при выполнении заданной команды;

  • ltrace - утилита для просмотра обращений к системным библиотекам, происходящих при выполнении заданной команды;

  • tcpdump / wireshark - утилита для просмотра сетевого трафика;

  • ab - утилита для нагрузочного тестирования HTTP-серверов;

  • sysbench - утилита для нагрузочного тестирования БД;

  • gdb - консольный отладчик приложений;

  • ioprofile - комбинация утилит lsof и strace для анализа I/O активности приложения;

  • /proc file system - псевдофайловая система для отображения ядерной информации (данные о конкретном процессе можно найти в каталоге/proc/PID/*);

  • iostat - утилита для мониторинга I/O опреций в системе;

  • ethtool - утилита для управления настройками Ethernet карт;

  • taskset - утилита для привязки процесса к заданному CPU;

  • irqbalance - утилита для распеределения прерываний оборудования между CPU.




Scaling to hundreds of millions of requests


Рассказ о развитии соц. сети для поклоников BSD BDSM :) Можно выделить следующие этапы развития проекта:

  • Проект располагается на одном сервере, возникают проблемы при масштабировании
    (scalability);

  • Проект переезжает на облака Амазона: очень удобно регулировать ресурсы, но переодически возникают внезапные кратковременные падения производительности ("spikes");

  • Проект переезжает обратно на выделенный хостинг. БД мигрирует на NoSQL решения (MongoDB), которые по началу показывают неплохие результаты. Однако, обнаруживается, что у MongoDB есть проблемы с конкурентными запросами (прим. проблема вроде бы уже решена), а с Cassandra у ребят возникли некие проблемы в бою;

  • Выбор БД останавливается на MySQL (master + slave) и Redis. В настоящий момент проект обрабатывает 70.000.000 requests per month.




Доклад о Facebook


Поверхностный рассказ об устройстве Facebook'a.

  • В разработке ребята из Facebook используют максимально короткие итерации, постоянно выкладывая изменения в бой. Это позволяет им сразу получать реакцию пользователей и исправлять баги. Естествено, что для каждого релиза составляется план отката;


  • Архитектура Facebook состоит из трёх слоёв: web-server'а, cache (memcache) и база данных (mysql без использования join'ов). Каждый из этих слоёв масштабируется горизонтально;


  • В системе нет ни одной единой точки отказа;


  • Пользовательский контент (картинки) храняться в MySQL (sic!). Используется шардинг (sharding) БД. На каждом узле (шарде) настроена репликация.




Shared Personalization Service - How to Scale to 15K RPS


Первый услышанный мною доклад от Microsoft, который мне вообщем-то понравился. Из интересных моментов можно выделить два:

  • При обновлении данных ребята сначала "подогревают"/обновляют кеш, и только потом пишут данные в БД;

  • Данные о пользователях шардятся по серверам. При этом соответсвие между Id пользователя и шардой вычисляется не автоматически, а храниться в отдельной (надо полагать key-value) БД.




Developing PostgreSQL perfomance


Общий рассказ о разработке PostgreSQL одним из авторов.

  • Регулярый benchmark перед каждым релизом;

  • При разработке приходится сталкиваться с проблемами, включающими в себя следующие аспекты: алгоритмы, системные библиотеки, оптимизация копилятора, работа с ОС, hardware;

  • Postgres может подойти под любые нужды - главное правильно подобрать настройки;

  • Postgres никогда не станет платным.




Managing replication of PostgreSQL


Доклад об особенностях репликации в PostgreSQL.

  • Существует два типа репликации: trigger-based (userspace) и log-based (integrated);

  • Примером trigger-based репликации является Slony;

  • Начиная с версии 9.0 PostgreSQL поддерживает log-based репликацию. На данный момент реализация асинхронная (на slave'ы данные поступают с задержкой в 200ms). Начиная с версии 9.1 (11.2010) добавится возможность синхронной репликации;

  • Log-based репликация не показала сколь-либо существенного падения производительности при 6-ти slave'ах;

  • При log-based репликации мастер не дожидается коммита транзакции, а сразу отсылает данные на slave/standby.




Scaling with Postgres


Своего рода "best practice" работы с PostgreSQL.

  • Культура разработки куда важнее новых технологий;

  • Программист должен работать в тесном сотрудничестве с DBA;

  • Для мониторинга Postgres'a пригодится утилита check_postgres.pl;

  • Для профилирования запросов к PostgreSQL пригодится утилита pgfouine;

  • Минимально допустимая для разумных людей версия PostgreSQL на данный момент 8.3;

  • Для реализации репликации стоит использовать следующие варианты:

    • Master - Master: Bucardo;

    • Master - StandBy: PostgreSQL 9.0;

    • Master - несколько Slave'ов: Slony.



  • Sharding: разбивайте БД на несколько, группируя таблицы по сервисам;

  • Pooling: открытие соединения - очень дорогая операция, так как требует создания нового процесса. Для ускорения работы приложения следует использовать пул соединений с БД.




Rapid upgrades with pg_upgrade


Рассказ о замечательной утилите pg_upgrade, позволяющей быстро и безболезненно обновить версию PostgreSQL.

  • База в 150GB обновляется с версии 8.3 до 9.0 в режиме link mode за 44 секунды, в режиме copy mode за 44 минуты.




Progressive downloads and rendering


Доклад разработчика Yahoo oб оптимизации времени загрузки HTML-страницы.

  • HTML5 позволяет асинхронную (async) и отложенную (defer) загрузку JS-файлов. В HTML4 эта функциональность доступна через DHTML;

  • Загрузка CSS-файлов блокирует rendering страницы. Для решения проблемы можно встраивать CSS в HTML-код страницы;

  • Для ускорения загрузки скриптов, расположенных в HTML-элементе HEAD можно насильно вызвать flush данных: <head></head><?php fluch();?>;

  • Приём с flush'ем также можно использовать для ускорения отрисовки обособленных блоков на странице;

  • Изображения можно хранить как часть HTML-страницы c помощью Data URI или Mime HTML;

  • Изображения можно загружать lazy-методом после загрузки основной страницы.





День 2


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


Sphinx Real Time indexes


Рассказ о новой возможности поискового движка Sphinx - Real Time индексах.

  • RT индексы в несколько раз медленне на больших (2 млн) объёмах данных;

  • RT индексы для ускорения работы требуют большего количества оперативной памяти;

  • RT индексы на практике работаю медленее, хотя в теории при выделении достаточного объёма оперативной памяти могут работать быстрее.




Sphinx для высоконагруженных и масштабируемых проектах


Доклад о сервисе поиска по десяткам терабайт данных.

  • Используются классические, а не RT индексы, так как последние не достаточно обкатаны;

  • Индекс тупо шардится по серверам. Выделяется основной сервер, на котором сконфигурирован distributed индекс, конкатинирующий шарды.




Масштабируемая система голосования на базе PostgreSQL PgQ


По сути доклад сводится к описанию работы с очередью сообщений на основе PostgreSQL - PgQ.

  • При наличии большой таблицы скорость работы с ней в некоторых случаях можно увеличить, выделив редко используемые данные и поместив их в архивную таблицу;

  • Очередь - это кран в трубопроводе, которым можно регулировать поток/нагрузку на нижележащие узлы в системе (очередь PgQ имеет конфигурируемые пропускные параметры);

  • Очередь PgQ - часть проекта skytools: набор утилит для работы с PostgreSQL от Skype;

  • Производительность PostgreSQL можно увеличить следующими способами:

    • Настроить vacuum;

    • Отключить fsync (возможна потеря данных, довольно спорное решение);

    • Включить асинхронные коммиты;

    • Hardware решение - поставить SSD-диски.






Компиляция скриптов PHP


Доклад ради доклада, не особо интересно.

  • Цель компиляции PHP-скриптов - избежать избыточной работы по лексическому анализу и интерпритации токенов в opcode;

  • Компилироваться PHP может как в native код (Roadsend, Raven, Phc, Hiphop), так и в non-native (Project Zero для Java, Phalanger для .NET);

  • 100% кода Facebook компилируется через HipHop;

  • HipHop не поддерживает некоторые функции (eval, create_function, preg_replace), не поддерживает большинство модулей, не поддерживает PHP 5.3 и реализован только под 64-ый Linux;

  • На больших нагрузках ведёи себя чуть лучше, чем Apache/Nginx + APC;

  • Результатом работы компилятора HipHop является исполняемый файл со встроенным web-сервером;

  • Единственная Success Story - это Facrbook, сам докладчик переводить свой сайт (rbk.ru) почему-то не торопится :)




Goal driven performance optimization


Абстрактный доклад о том, что же такое производительность от главы Percona Петра Зайцева.

  • Выделение параметров производительности: время отклика, загруженность системы;

  • Метрики: среднее время, максимальное время, проценты (95% запросов выполняются за 10s);

  • Типы медлительности: случайная, характерная для определённого сервиса;

  • Типы пользователей: люди, боты, сервисы;

  • Инструменты для замера производительности.




InnoDB architecture and performance Optimization


Реклама Percona и описание возможностей их XTraDB на фоне рассказа о настройках InnoDB.

  • Традиционная OLTP архитектура на основе с Orcale;

  • Хранит данные по строкам;

  • Блокировка на уровне строк;

  • Write ahead log (WAL);

  • Thread per connection.




Доклады о ВКонтакте


Дуров произвёл довольно неприятное впечатление. И вообще, контакт пишут лучшие умы современности и многократные победители олимпиад :)

  • 32 фронтэнда + тысячи бекендов (4 датацентра + 2 строятся, в Москве и Питере);

  • Деплоймент "обычный" самописный;

  • Мониторинг "обычный" самописный, шлёт SMSки;


  • Пользовательская статика хранится на XFS. Общей сетевой файловой системы между бекендами нет, всё разруливается на уровне скриптов;


  • Личные сообщения хранятся в самописном in-memory storage engine;

  • Собственный memcache c persistence и сжатием данных;

  • Новости реализованы как демон на Си + MySQL + Memcache. Сами новости храняться вместе с пользователями, которые их сгенерировали. Сборку новостей в ленту осуществляет отдельный сервер. Инициирует сбор новостей в ленту, тот кто читает новости своих друзей;

  • Поиск по анкете: нереляционная БД со специальным форматом ключа, содержащим характеристики пользователя + демон на Си с интерфейсом Memcache;


  • Сервера: ОС Debian Linux (свои доработки), Железо не брендовое (Intel 8 Core, 64 GB RAM);

  • Сервера используются в нескольких аспектах сразу: диск для фото, память для memcache;


  • Балансировка нагрузки средствами Nginx;

  • ПО: nginx / apache + modphp + XCache;


  • Нагрузочное тестирование проводится на группе пользователей (первые 10.000 Id);


  • Защита от DDos: пасинг логов (выявление закономерностей) в realtime и переконфигурирование nginx, решение проблемы на маршрутизаторах;


  • История: Переход с одного сервера на 2 после 10.000 посетителей в день;

  • Фотографии не удаляются с жёстких дисков и остются доступны по прямой ссылке (для уменьшения фрагментации).




Мастер класс по хранимым процедурам в MySQL


Доклад/МастерКласс от сотрудника MySQL/Oracle.

  • Использовать хранимые процедуры стоит только в административных целях. Не надо размазывать бизнес логику из приложения в БД;

  • Процедуру можно запускать из-под определённого пользователя (ключевое слово DEFINER);

  • PL/SQL корнями уходит в язык Ada;

  • Курсор при открытии материализуется во временную таблицу;

  • Результат работы харнимой процедуры кешируется локально для соединения (в отличие от trigger'ов);

  • Реализация некоторой логики на хранимых процедурах в разы медленнее реализаций на популярных языках программирования;

  • Кореллированные запросы при прочих равных быстрее работают на хранимых процедурах.





P.S.



  • Заметил, что многие люди используют слово "функциональность", вместо распространённого "функционал". С точки зрения русского языка это должно быть верно... надо будет перенять модную московскую тенденцию :)

  • Прослушивание докладов на иностранном языке здорово повышает ЧСВ. В некоторые моменты я прямо-таки чуствовал, как моё переваливает за 9000 :) А если серьёзно, было бы здорово, если б все люди общались на одном языке и не было бы языковых преград для обмена опытом и знаниями.


3 comments:

  1. На этом Highload'е я не был, но было интересно прочитать, что я пропустил ))

    Если будешь здесь, то сообщай обязательно.

    ReplyDelete
  2. Миша, а чего в гости не зашёл?

    Ещё не поздно исправиться ;)

    ReplyDelete
  3. Я уже в Новосибе, но в следующий раз буду иметь в виду )

    ReplyDelete