Highload-2013: Отчёт Виталия Филиппова

Информация о конференции, организация:

Highload-2013, «Конференция разработчиков высоконагруженных систем». Проходила в очередной раз в конференц-зале гостиницы Radisson на м. Киевская.
Самая первая и самая распиаренная из Бунинских конференция. Билет стоил аж 21000, плюс ещё были отдельные «учебный» и «VIP» дни (на которых я, естественно, не был).
Хайлоад начался с хайлоад-очереди на регистрацию. В разные обработчики она, правда, почему-то была разная (очередь с приоритетами, где каждый оценивает свой приоритет сам?), и встав в другую, ты терял времени на порядок-два меньше.
Вайфай нормально не работал, до отваливания в нём удавалось посидеть минут 5.
С едой всё было более-менее в порядке — кофе-чай всё время, 2 перерыва, каждый из которых для части людей — кофе-брейк с плюшками, а для другой части — обед (балансировали нагрузку талонами). Небольшие трудности с обедом — народу много, места сесть не хватало, часть еды быстро кончалась. Но голодным там всё равно никто не оставался.
Дали большую кучу раздаточных материалов — книжку с частью докладов с прошлой конференции, диск, рекламу, 3 блокнота… Полезный элемент — в этом году вместо ахтунг-стайл красной авоськи дали сумку для ноутбука, в которую и был упакован весь выданный crap.

Общая атмосфера:

Атмосфера в целом какая-то «коммерческая», видно, что компании туда ходят уже по накатанной для регулярного пиара.
Докладчики (компании) — всё одни и те же лица, посетители — наоборот, похоже, исключительно новые. Правильно Стас выразился — это как с борделем, нормальный человек ходит туда 1 раз в жизни; это ты ходишь постоянно, и тебя уже ничем не удивишь.
Девушек на конференции не было почти совсем, «радостную» программистскую тусовку разбавить было некем.
Многие зарубежные «звёзды», как обычно, лили воду, содержательной части в докладах от FB, например, процентов 10.
Было много докладов от одних и тех же компаний — может это и не плохо, но по-моему свидетельствует о неком спаде доступного разнообразия (или слабом подборе). Ну и badoo (которое сайт знакомств и вообще непонятно, почему в 21 веке имеет столько юзеров) уже слушать как-то неинтересно. Примеры повторов:
По 3 доклада от Badoo и 2ГИС; по 2 от Одноклассников, Facebook, Monty Program AB, Qrator/HLL, mail.ru, HashiCorp. К этим в общем-то претензий нет, понятно, что вторых таких же чуваков, как Qrator, найти сложно.

День 1

Экосистема Сочи 2014. Космос как предчувствие / Михаил Чеканов (Оргкомитет Сочи 2014), Ольга Куликова (Articul Media)

На докладе не был, отмечаю потому, что из интересного там было очевидное :-) сайт сначала сделали на БИТРИКСЕ, но потом всё-таки поняли, что с этого нереального ужоса надо сваливать. И таки свалили — переписали всё сами и довольны.

(незачёт) Как поставить миграцию баз данных на поток / Илья Космодемьянский, Роман Друзягин

Чуваки пытались рассказывать доклад вдвоём попеременно. Это хороший формат выступления, но слайды у них тем не менее были совершенно жуткие, да и сам рассказ таил в себе больше воды.

Из содержательного — миграции нужно всегда отрабатывать и нужно всегда иметь план «Б», то есть иметь возможность быстро откатиться назад, если миграция БД не удастся.
Из смешного — если будете покупать IBM DB2 — скажите, что мигрируете с оракла, они вам сделают скидку :-D

Полнотекстовый поиск в Почте Mail.Ru / Дмитрий Калугин-Балашов

Зашёл в самом конце, услышал чуть-чуть. В общем, смысл в том, что полнотекстовый поиск написан полностью кастомный, хранит отдельный индекс для каждого пользователя, и умеет сортировать только по дате. Вроде внутри некая лог-структура.

Из смешного — их спросили, неужели вам не подошло ни одно из готовых решений, зачем вы написали свой поиск? Они ответили — потому что есть ресурсы! («because we can!»)

Своевременная оптимизация / Carlos Bueno (Facebook)

Доклад рассказан неплохо, хоть содержательность и хромает. В основном было много общих слов.

Чувак из фейсбука перевёл слайды на русский язык (на каждом слайде фраза была и по-английски, и по-русски)… но, видимо, перевёл google translate’ом, потому что были такие перлы:

Optimisation: don’t ever do it! (* except sometimes).
Оптимизация: никогда не делайте его! (* кроме иногда)
Distrust numbers. Especially your own.
Числа недоверия. Особенно ваше собственное.

Ещё из смешного — доклад он начал со слов:

I work at Facebook, it’s a V Kontakte in America. I work at facebook performance team…

И тут кто-то спросил (было в твиттере, было ли в реале — не уверен) :D

OK, so when will you begin? [working on facebook performance]

А дальше общие размышления:

Проблема должна быть проверяемой, если она непроверяемая — то это не проблема…
Два пути решения — повысить производительность либо сдвинуть нагрузку (которой мы можем управлять — обсчёт какой-нибудь и т. п.)
Оптимизация это больше не про computer science, а про science science; вообще вся разработка — типа, умение «playing computer in your head». Однако: who is better than you in playing computer? the fucking computer! (не помню, к чему это — видимо к тому, что можно пытаться не придумать, а симулировать нагрузку)
Опять про корректность измерений: «I feel really stupid saying about this, but directly measure what you optimize»
Говорит, мы в один день проснулись, а Facebook на 10 % быстрее. Он такой — я говорю начальнику, смотри, круто! А он — ты зря радуешься, если много ситуаций, в которых система может ВНЕЗАПНО стать на 10 % быстрее, и лишь малая часть из них — хорошие :-)

Распространение систем на Scala благодаря Finagle / Julio Capote (Twitter)

Товарищ из Twitter’а просто рассказывал какая хорошая scala, и какая у них есть под неё библиотека RPC Finagle, я как-то выпал из контекста.

Опыт переезда соцсети Livestreet с PHP/MySQL на NodeJS/Redis/Lua / Дмитрий Дегтярев (Хабикаса)

Странный доклад… У чуваков был стандартный сайтик на стандартной отстойной блого-социально-подобной CMS’ке Livestreet. Данных там мало, всего несколько тысяч постов. И его вместо того, чтобы просто переписать, переписали на сильно извращённый вариант:

В качестве БД — Redis
В качестве логики — хранимые процедуры на Lua внутри Redis’а O_O
Вместо классической схемы сделали сайт почти целиком на AJAX
Генерация маленьких HTML страничек для возможности индексации осталась в Node.js

Сразу отметим: запихивать толстые хранимые процедуры в redis == на корню убивать его производительность, он же однопоточный мультиплексирующий и все команды должны выполняться быстро.

Типа, кэш мы инвалидировать не хотим, давайте сразу всё хранить в кэше… :-) хотя Redis — это вообще-то не кэш, а БД. Просто когда он вылезает за размеры памяти, работает весьма печально, а пока не вылезает, всё и так в памяти и по скорости он таки да, почти как memcache. Ещё в Redis’е есть два понятия — embed и sideload, типа при загрузке связанные сущности могут либо подгружаться по ID отдельно, либо встраиваться прямо в родительскую сущность. Первое, очевидно, меньше занимает места, второе — делает меньше запросов.

Потом чувак сделал мегасерьёзный «бенчмарк» и расстроился, потому что redis с его подходом не получился быстрее MySQL! Бенчмарк заключался в измерении скорости загрузки ВСЕХ ПОСТОВ из базы одним запросом. Офигеть бенчмарк. «На мой взгляд редис должен быть в 10 раз быстрее… но сейчас это не так, или я тест сделать ниасилил подходящий даже» :-)

Ещё в моих заметках отмечено «бред про многопоточный редис», но что это значит, я уже забыл :-)

Потом он полез профилировать redis, и обнаружил, что 50 % времени тот проводит в string2ll (конвертации строки в число). Интересно.

Но в общем и целом, буханка, троллейбус. Badoo’шники того же мнения, их чувак выразился «то есть вы решили пересесть с лёгких наркотиков на тяжёлые».

Дизайн движка метапоиска aviasales / Борис Каплуновский (Aviasales)

Интересный доклад от Aviasales («метапоисковика» авиабилетов), докладчик сначала было испугался, что его, как и предыдущего, сейчас запинают насмерть ребята из Badoo — он сказал, «я наверное тоже по вашему мнению пересел на тяжёлые наркотики», но на самом деле — нет, и архитектура, и доклад вполне адекватны и тот же badoo’шник это признал :-)

Задача: есть куча поставщиков API, которые по запросу умеют отдавать дикого размера XML’ки или JSON’ы с ценами на авиабилеты (1-30 мб). Пользователь выбирает даты, пункт отправки и назначения и число человек, и по этому запросу Aviasales должен максимально быстро сделать запросы ко всем поставщикам, собрать от них цены и отобразить пользователю в порядке возрастания. Кэшировать особо не покэшируешь, так как информация быстро меняется и должна быть максимально актуальной.

Нюанс: поставщики обычно сами тоже агрегаторы и тоже делают запросы к авиакомпаниям. И эти запросы поставщикам API не бесплатны. Соответственно, хоть запросы от Aviasales к ним для самого Aviasales и бесплатны, всё-таки лишние запросы тоже делать нельзя. Короче говоря, задача достаточно простая и прямолинейная.

Ещё нюанс: по их исследованиям конверсия уменьшается на 30 %, если среднее время ответа сайта повышается со 100 до 500 миллисекунд. Так-то.

Как было: Раньше у них всё это было представлено некой системой, написанной на Ruby On Rails, и это было довольно печально, так как RoR — типичный веб-фреймворк:

Стартует небыстро, 5-10 секунд (и перезачитывать код на лету видимо не умеет?) — это несколько затрудняет отладку.
Занимает немало памяти под каждый процесс зависимостями и т. п. (у них вроде 300 мб, но вероятно с учётом разделямой памяти)
Полностью синхронный, и пока какой-то процесс делает запрос к внешней системе — процесс тупо висит, курит бамбук и ждёт ответа на сокете. Занятая память простаивает. Кроме того, пока таким образом не завершатся все скачивания — не получается начать отдачу страницы пользователю (не получается сделать «живой поиск»).

Как стало: В общем, им всё это поднадоело, они решили всё переписать и изобрели свой «сервис-ориентированный» DSL на питоне, на основе сервера Tornado. DSL называется «Ясень», состоит из изолированных обработчиков (у которых на входе 1 объект и на выходе 1 объект) и довольно прост, умеет всего 3 вещи:

Последовательные цепочки — выход одного обработчика скармливается другому
Параллельные цепочки — выход одного обработчика скармливается набору других
Отложенные цепочки — выход всегда равен входу, предназначены для побочных эффектов (логгирование и т. п.)

Цепочки запускаются внутри одного процесса, то есть даже никакие JSON’ы между серверами туда-сюда не гоняются. Каждый обработчик при этом можно дёрнуть извне, таким образом отлаживаясь.

Система в целом написана на этом DSL, и его даже понимают менеджеры — бывает, приходят и говорят: а вставьте-ка мне вот сюда вот такой обработчик… И они вставляют.

Архитектура хранения — данные делятся на несколько видов:

Мелкие справочники (например, валюты) — хранятся в памяти процесса на каждом сервере.
Толстые справочники (> 1 мб) — хранятся в файловой key-value БД kyotocabinet. Она маппится в память процесса, соответственно, разделяется всеми процессами. Реплицируются на сервера с помощью, кажется, файловым репликатором lsyncd.
Логи — всегда пишутся локально, а потом асинхронно перетаскиваются в глобальное хранилище.
Динамические данные — пишутся на 2 redis-сервера для отказоустойчивости.

Какие есть процессы:

«Пчёлы» — рабочие процессы, «муравьи» — те, что логи переносят, и локальное хранилище (плёлы и муравьи — это не я придумал, это у него в докладе так было).
Ещё есть HAProxy для распределения соединений, «многоножка» — интерфейс администрирования, и мониторинг monit, в который смотрит «пингвин»-админ.
Если упадёт 1 redis — пофиг, система работает дальше. Если упадёт второй redis — ну, увы. Говорит, если у меня упадёт два редиса, я сначала уволю админа, а потом поставлю третий.
Ещё при каких-то видах сбоев (если помрёт глобальное хранилище логов?) — часов 8 оно точно спокойно проживёт, а это время, за которое типичный «пингвин» может выспаться, прийти и всё пофиксить.

Как делается синхронизация данных на серверах после сбоя — он не рассказывал. Возможно, делается руками админа-«пингвина».

Как мы храним 60 тысяч событий в секунду / Арсен Мукучян (AdRiver)

Сурьёзный плюсист в чорном костюме рассказывал, как за 5..10 человеко-лет (5 человек за 2 года вперемешку с другими задачами) они переписали хранилку событий в AdRiver. Событие ≈ показ баннера, занимает от 0.1 до 4 Кб. Старая система работала на основе syslog (оригинально), который дропает события, когда их становится много (это фича, а не баг). Писали они исключительно хранилку, конкретные вычисления статистики отданы на откуп клиентам к хранилищу (то есть, другим отделам).

Рассказывал немного грустновато, я немного отключался. Итог реализации — кажется, поточная схема взаимодействия и «поуровневая» система архивирования: свежие события на «ближних» серверах, старые «дальше», ещё из старых событий может удаляться малополезная, но длинная информация типа Referer…

Нагрузка сейчас 2 гбит/сек (закладывали до 20 гбит/сек), загрузка CPU 20-40 %, обслуживается 5000 клиентов с 10 серверов.

Обзор популярных современных алгоритмов хранения данных на диске: LevelDB, TokuDB, LMDB, Sophia / Константин Осипов (Mail.ru, Tarantool)

Что-то в этом году на хайлоаде было популярно рассказывать про всякие структуры хранения данных, в основном — оптимизированные для быстрой записи. Докладов было аж несколько. Но тем не менее — весьма интересно, я про детали реализации этих структур раньше как-то не слышал.

Во-первых, LSM-деревья (Log-structured merge-tree). Идея в том, что у LSM дерева есть несколько уровней хранения увеличивающихся размеров, первый (нулевой, он же memtable) из которых лежит в памяти, а остальные лежат на диске. Каждый уровень представляет собой дерево или список деревьев, и у каждого уровня есть растущий (обычно в 10 раз на уровень) лимит размера. Вставка производится сначала в нулевой уровень, при переполнении он сбрасывается в первый, при переполнении первого — попадает во второй… И так далее. Вставки получаются быстрые, так как не нужно мучаться с перезаписью отдельных мелких блоков данных. Однако зато мы, во-первых, имеем неслабый write amplification, а во-вторых — при поиске значений должны просматривать все деревья (что не круто). С первым ничего не поделаешь, а со вторым борются поддержание в памяти bloom-фильтров — некой хеш-таблицы, посмотрев в которую, можно сказать, в каких деревьях данных точно НЕТ, а в каких они МОГУТ БЫТЬ.

LSM-деревья используются в библиотеке LevelDB от гугла, встраиваемой SQL БД SQLite 4, в HBase, Wired Tiger и в NoSQL БД Apache Cassandra.

Во-вторых, Cache-oblivious структуры (общий термин, характеризующий то, что структуры эффективно используют кэш процессора, не зная его точного размера). Подход используется в новомодном движке хранения для MySQL — TokuDB (у них это называется Fractal Tree Indexes). Идея в чём-то похожая — просто в каждом узле обычного B-дерева ещё поддерживается «буфер» для вставок, и вставляемые элементы сначала попадают туда, а уже потом сбрасываются в дочерние узлы. Засчёт этого скорость записи опять-таки увеличивается и не падает, даже когда индекс перестаёт влезать в память.

В-третьих, Bitcask, используемый в Basho Riak. Это вообще вещь тупая — данные всегда пишутся последовательно, хеш-индекс всегда держится в памяти.

Ну и последнее — некий гибридный подход, используемый в библиотеке Sophia. Там, с одной стороны, данные делятся на непересекающиеся регионы, индекс которых (min, max для каждого) держится в памяти (получается что-то типа листов B-дерева), с другой — в памяти есть хеш-таблица, в которую в начале попадают новые элементы (чем-то похоже на memtable LSM-дерева). На диск последний хеш пишется в виде «журнала» (чтобы данные не терялись). А когда данных в этом хеше становится слишком много — данные распределяются по регионам, которые в свою очередь при переполнении разбиваются на под-регионы.

В конце докладчика спросили — а как Tarantool-то хранит?! Как, как — да никак. В памяти он хранит. В будущем, возможно, его научат хранить и на диске.

Статистика на практике для поиска аномалий в нагрузочном тестировании и production / Антон Лебедевич

Доклад интересный — про то, как можно применять методы статистики для выявления потенциальных проблем системы по графикам кучи показателей с кучи серверов. Ну или как их хотя бы сгруппировать / почистить так, чтобы количество стало вменяемым и в нём мог разобраться человек.

Выявление аномалий:

Поиск изменения среднего. С помощью банального скользящего обычного или экспоненциального среднего.
Поиск изменения распределения данных (делим данные на две части, применяем критерий Колмогорова-Смирнова).
Выявление нелинейного роста.
Выделение тренда с учётом сезонности + сильный выход за его границы (классический Холт-Винтерс). Минус в том, что нет нормального алгоритма для трёх сезонов, а их обычно как раз три :-) да и вообще в реальных данных часто встречается, например, график вида «пила».
Нарушение автокорреляции показателя.

Группировка показателей (поиск зависимостей между графиками):

Применяются методы кластеризации (k-средние, иерархическая группировка).
На основе, например, корреляции или среднеквадратичного отклонения между графиками.
Однако есть минус — такая группировка прекрасно «ловит» ротацию логов (когда старые логи сжимаются/удаляются). Она обычно происходит на всех машинах в один момент, и смена разных показателей в этот момент отлично группирует графики, хотя вообще-то их группировать незачем.

Всё это (или по меньшей мере часть), как ни странно, реализована в опенсорсном виде и её можно пощупать: https://github.com/etsy/skyline, https://github.com/etsy/oculus (части некого Kale Stack).

День 2

Завалить в один запрос: уязвимости веб-приложений, приводящие к DoS / Иван Новиков (ONsec)

Доклад немного в стиле «капитан ясен хрен», и явно было заметно, что товарищ пиарил свою конторку.

Рассказывал про баги в сайтиках, через которые «всё поломать» не получится, но DoS устроить вполне можно. Часть идей была полным (или НЕполным) бредом:

Бажные парсеры — типа бывают баги в парсерах (XML, CSV, входных параметров и т. п.), из-за которых оные зацикливаются. Утверждал бред, что если передать PHP параметр вида ?a[][][]…[][][], то он зациклится. Это конечно не отменяет того, что такие баги _возможны_, но явно не в этом месте.
Ещё одна бредовая идея — чувак утверждал, что популярные новомодные «классификаторы» (типа ютинетовского) тормозят, если им выдать что-то непонятное («синий красный зелёный одновременно фиолетовый и вес меньше 100кг»). Дурь. С чего им тормозить? Разве что имеются ввиду движки, которые по условию (< 100кг) вытаскивают все возможные значения веса и ищут по множеству? Но и это к серьёзным тормозам не приведёт. Ютинетовский подтупливает, конечно, но он и в целом небыстрый… а на DoS в один запрос это как-то не тянет.
Про переполнение хранилища сессий. Типа если сессии очень жирные (если там хранится вся история посещений со всеми полями запроса), то их туда можно накидать своих, и других людей не будет логинить, или если они в tmpfs, память кончится (что бред — tmpfs ограничен в размере). Но даже если всё так, то эксплуатировать довольно геморно — это надо реально долбить сервер запросами, иначе ваши «толстые» сессии всё равно будут вытесняться.
А вот эта относится к классу «капитан ясен хрен»: вспомнил поиск по регэкспам в БД, которые при этом ещё и берутся из параметров запроса. Не, то есть я не против, PHP-сайтики много ССЗБ пишут — многие популярные движки, например, исполняемый код в базе хранят (битрикс, Invision Power Board, например). Но это же реально ССЗБ — ясно же, что поиск по регэкспу в БД медленный ВСЕГДА. А он говорил, что типа можно сделать такой регэксп, который будет делать очень глубокий поиск с возвратом (backtracking) и тормозить.

Некоторые идеи были вполне ничего:

Часто ограничивают заливаемую картинку размером в килобайтах, но не ограничивают размер в пикселях. А ведь в PNG можно создать хоть 100000x100000 картинку маленького размера, залитую одним цветом — там же сжатие. И в итоге на масштабирование, и даже на кроп такой картинки приложение тут же потратит всю память сервера. Лучше даже так рассчитать размер, чтобы в OOM процесс сваливаться не успевал, а чтобы просто дико свопился — пожалуйста, DoS в один запрос.
Пример с яндексом — они нашли баг в WebDAV сервисе яндекс диска — попытка перемещения папки в свою дочернюю приводила к зацикливанию. Им даже 5000 рублей за эту находку дали.
Любые взаимодействия по сокетам, в которые можно подсунуть свой адрес — например, OpenID. Дело в том, что таймаут запроса часто работает не в целом, а на 1 операцию чтения из сокета. Тогда делаем свой сервер, который на запрос будет раз в (таймаут-1) секунд отвечать 1 байтом. Подсовываем его URL и делаем с ним штук 80-100 запросов к сайтику. Итог — все рабочие процессы заняты тем, что прилежно ждут, пока наш сервер им посылает данные по 1 байту.

Но про самое классическое чувак почему-то не вспомнил! Самое классическое — это банальное открытие последних страниц какого-нибудь длинного тяжёлого поиска. В один запрос, конечно, не завалишь, но лёгким DoS’ом заставить сайт дико тупить от такого действия можно очень часто.

Масштабирование скомпилированных приложений / Joe Domato

Причем тут «масштабирование» — непонятно. Рассказ был про автоматизацию сборки и CI. Послушал чуть-чуть, услышал про:

На винде все эти автотесты и CI настраивать геморно, на нормальных системах сильно удобнее.
Тестов мы не хотим много и не хотим мало.
Сборка должна быть повторяемой.

(полный отстой) Анализ производительности и оптимизация MySQL / Пётр Зайцев (Percona)

Тут я даже заметок никаких не напишу. Доклад вообще ни о чём, его можно было не делать. Там были не просто общие слова, а 100%-ная вода, состоящая из тривиальнейших идей. Про оптимизацию MySQL там не было вообще ничего, ни одной фразы.

Кто после такого доклада пошёл ещё и на мастер-класс этого мастера лить воду — лопух ;-)

Платформа для Видео сроком в квартал / Александр Тоболь (Одноклассники)

Рассказ о том, как Одноглазники передалали свой видеосервис на собственную платформу. До этого он работал сначала на платформе видео@мейл.ру, потом на rutube. Но, судя по всему, ни качество, ни стабильность ни того, ни другого их не устроило, а задача создания средненького видеосервиса — она в принципе не такая уж и суперсложная, поэтому они его решили сделать сами.

Объёмы нормальные, в день: 10 млн уников, 60 млн просмотров (до 100 гб/сек), 50 тысяч новых видео (= 5 ТБ = до 5 гб/сек).

Итого устроено всё довольно просто:

Хранилище — 70 серверов, 5 петабайт, БД и кэш — ещё 30, парк ffmpeg’ом под zookeeper’ом для трансформации — ещё 60, раздача и загрузка — ещё 30.
Есть возобновляемая загрузка (failover).
Используют flash. Хотят доделать HTML5 плеер.
Как обычно, псевдостриминг (и правильно, все так делают, кроме тупого рутуба). То есть, не RTMP или что-то подобное, а обычная раздача MP4 через HTTP, а если нужно перемотаться — HTTP Range Request.
Собственный вариант qt-faststart — скрипта, который перемещает MOOV Atom (заголовок видео) в начало файла (он в MP4 по дефолту в конце O_o), а также удаляет из него информацию о лишних keyframe’ах.
Нюансы перепаковки: несколько качеств, в 15 % случаев требуется коррекция длительности.
Чтобы всё это работало быстро, они, во-первых, напилили собственный кэш на своих one-nio и unsafe кэше, в который всегда попадают все заголовки видео, плюс попадает само видео кусками по 256 Кб.
Для кэша используется 96 Гб RAM и 4 ТБ SSD’шек на каждом сервере, плюс OBS. 80 % cache hit.

Вещание видео на 10 ГБит/с / Максим Лапшин (Erlyvideo)

Erlyvideo теперь вышел на американский рынок и называется Flussonic. И, видимо, теперь его используют разные группы нехороших лиц, наживающихся на продаже «нихрена» (контента). Сам Erlyvideo от этого, правда, хуже не стал (а то и стал лучше) и остался опенсорсным, что, безусловно, хорошо.

Рассказывал про разные нюансы раздачи видео с одного сервера на 10 гигабит. Типа процы в принципе не особо ускорились за 5 лет, но зато подешевели 10 гбит каналы, и появились SSD’шки, и вроде как стало можно раздавать и 10 гигабит. Например, на нагрузках в несколько гигабит у них подыхал software raid. И прочее — прерывания, дисковые очереди и т. п.

DDoS атаки в России в 2013 / Александр Лямин (QratorLabs/HLL)

Обзор ситуации с DDoS’ом в России за этот год.

Интересное:

Атак стало больше в 1.5 раза, рекорд за день вырос в 2 раза, макс. размер ботнета тоже немного подрос, рекорд длительности — наоборот, упал.
Spoofed атак («с чужого IP») стало больше, чем прямых.
В основном пик активности был в конце зимы и весной (в отличие от 2012 — пик был летом).
Уверенный лидер по атакам как в 2012, так и в 2013 — внимание, магические услуги! O_o за ним идёт правительство с почти четырёхкратным отставанием. Это что, такая «чёрная ddos магия»? Или просто кармическое наказание для шОрлатанов?
Отличная картинка и фраза про «год фиолетового DNS» (DNS amplification): тут есть всё — и фиолетовые пони, и облака, и кирпичи высокой кристаллизации… А почему пони фиолетовый — это потому, что его уже просто больше нельзя бить, он сплошная гематома
Товарищ зачем-то ругал UDP, потому что типа «любой протокол без авторизации и с плечом ответа» может привести к такому же усилению. Что-то мне кажется, что глупо UDP ругать — не будет его, будет что-нибудь ещё. А вот ratelimit на публичных сервисах — это правильно, да.

История MySQL и MariaDB / Michael Widenius (Monty Program Ab)

Видениус забавен, говорит с совершенно аццким акцентом. Рассказывал просто обзор фич MariaDB (аналогично https://mariadb.com/kb/en/mariadb-versus-mysql-features/). Напоминаю, MariaDB — это такой правильный MySQL, который пишут в основном те же люди, что писали изначально, вместо индусов из Oracle. О чём Видениус и напомнил, сказав, что программисты оракла явно не совсем понимают код, над которым работают.

Хотел я у него спросить, что у них там происходит с движком Aria, но не успел :-(. Aria — это «безопасный MyISAM», который в будущем они планировали сделать и транзакционным. Интересно, насколько он развивается, и есть ли вообще смысл в том, чтобы делать из него транзакционный движок — есть подозрение, что с появлением транзакционности все его плюсы (которые были) растворятся, и получится ещё один InnoDB, тормозящий на вставках.

Оптимизатор запросов в MariaDB: теперь и без индексов! / Сергей Голубчик (Monty Program Ab)

Отличный доклад — разработчик марии рассказывал о том, как они недавно наконец-то запилили в MariaDB статистику, независимую от движка хранения.

Типа, раньше статистика полагалась на движок и на индексы, так как говорила движку: «оцени мне cardinality этого индекса», «сколько строк в таблице?», «сколько стоит фуллскан?». А движки врут. Ну, не то, чтобы явно врут, но бывает, что а) подкручивают значения так, чтобы получать нужные планы, и б) просто делают неточную оценку. В итоге, например, значения от разных движков вообще могут различаться.

А теперь сама мария умеет считать статистику по таблицам, индексам и даже колонкам (без индексов, ищет мин/макс, процент NULL, среднюю длину, обратную мощность и умеет считать гистограммы) путём ANALYZE, работающего через фулскан таблицы. Используются гистограммы равной высоты (то есть с неравномерной шкалой).

Нюансы, я так понял, такие: во-первых, надо иногда делать ANALYZE (само оно статистику не считает), во-вторых, часть оптимизаций полезна для «медленных» выполнений запроса, без индексов.

Из юмора:

Показывал пример с таблицами сотрудников — «вот, смотрите, это такой странный набор данных, где мало менеджеров…»
Ему задавали вопрос, он такой, «я не уверен что я понял ~~запрос~~ вопрос…» :D

Как рассуждать о производительности хранилищ баз данных / Mark Callaghan (Facebook)

А вот и ещё один доклад про всевозможные LSM-деревья, LevelDB и подобное. В принципе нормальный доклад, но не совсем про производительность, а именно что про «рассуждения».

А именно — про Write Amplification, Read Amplification и Space Amplification — то есть, про увеличение числа записанных/прочитанных/хранимых данных по сравнению с тем, что мы реально хотим записать/прочитать/хранить. Понятное дело, что зачастую Write Amplification есть у оборудования (например, SSD), у СУБД (redo/undo лог), ФС (мин. единица записи — 1 сектор). Space Amp: метаданные, фрагментация, старые версии данных… Read Amp: как раз относится ко всяким LSM, когда чтобы что-то прочитать, нужно сходить во все уровни. Типа, Write/Read Amp ограничивает производительность — она не может быть больше, чем максимальная скорость работы дисков делить на усиление.

А теперь примерные оценки этих значений:

Алгоритм	point read-amp	range read-amp	write-amp	space-amp
B-дерево	1	1..2	page/row * GC	1..2
LSM leveled	1 + N*bloom	N	10*уровни	1.1 X
LSM с N частями	1 + N*bloom	N	возможно < 10	can be > 2
log-only (bitcask)	1	N	1 / (1-%live)	1 / %live
memtable+L1 (sophia)	1	1	размер БД/размер L0	1
memtable+L0+L1 (MaSM)	1 + N*bloom	N	3	2
tokudb	1	2	10*уровни	1.1 X

Примечания:

Это копия со слайда, только я про разные типы B-дерева опустил — у них всех один и тот же показатель. Разница только в сборке мусора
Если постоянно коммитить в B-деревьях, то Write Amp — очень большой (1 на лог + размер страницы делить на размер строки), есть нет — то меньше. Space Amp зачастую около 2, так как страницы держатся полными на ~60 %.

(10 — это типичная разница в размерах между уровнями)

В общем, интересно, но, в принципе, эти «усиления» далеко не всегда определяют производительность благодаря разнице в скорости последовательного и случайного ввода-вывода (и благодаря кэшу, кстати).

См. также linkbench в https://www.facebook.com/MySQLatFacebook

Cassandra vs. In-Memory Data Grid in eCommerce / Александр Соловьев (Grid Dynamics)

Рассказ о том, как они переводили некий продукт с хранилища в оперативной памяти (а конкретно это был Oracle Coherence In-Memory Data Grid) на Кассандру. Именно на неё, потому что у Mongo и HBase обнаружены SPOF, сложное развёртывание, и некоторые эксклюзивные блокировки. Плюс, кассандра умеет работать на несколько датацентров, что тоже было требованием.

Резюме — если данные влезают в память и если немного подтюнить кассандру — она, в принципе, практически так же производительна, как in-memory БД, ибо Linux’овый дисковый кэш работает хорошо.

У них была магическая цифра, с каждым тюном производительность росла на +15 % TPS :-D конкретно тюны были следующие:

Выключить swap
Commit log и данные — положить на разные диски
Асинхронные запросы по многим ключам + token-aware routing → ещё +15 % TPS
Юзать последнюю версию — с 1.2.6 на 1.2.8 → ещё +15 % TPS
Ключ «родительского» объекта как первый компонент составного ключа «дочернего» (группирует она их, видимо) → ещё +15 % TPS
Локальные кэши → ещё +15 % TPS

Сравнение распределенных файловых систем / Marian Marinov (1H Ltd.)

Доклад с качественным вдумчивым бенчмарком нескольких распределённых файловых систем (линуксовых, разумеется).

Сначала про ethernet контроллеры — из типичного гигабитного выжимается ~500 mbit всего лишь. Чтобы приблизиться к теоретическому лимиту (~920 mbit), нужно покупать дорогой контроллер.
Потом про ядро — почесать разные сетевые sysctl (см. презентацию: http://www.slideshare.net/profyclub_ru/marian-marinov), ethtool (всякие segmentation offload, receive offload)
Потом переходим к бенчмаркам: GlusterFS, XtremeFS, FhgFS, Tahoe-LAFS.
Итог — наилучший вариант это FhgFS, так как скорость хорошая и нет внезапных тормозов.

JIT компиляция в виртуальной машине Java / Алексей Рагозин

Тот же мэн, что рассказывал на SECR’е про Performance Test Driven Development. «Серия» из двух докладов, с общим названием «JVM Deep Dive» :-)

Первый доклад — про JIT.

Бывает классический JIT. Просто берёт код и компилит в машинный код перед запуском. Это .net, jvm, v8, ionmonkey.
Бывает трассирующий JIT (tracing JIT) — который сначала запускает в интерпретируемом варианте, а потом повторяющиеся куски («трассы») JIT’ит. Они получаются идеальные и без ветвлений совсем. Это flash, tracemonkey, pypy, luajit.
JIT в JVM (и официальной, и OpenJDK) довольно крутой. Он умеет разные оптимизации:
- Умеет на лету inline’ить функции
- Умеет заменять метод на стеке — в момент возврата из функции управление получает JIT, подменяет реализацию метода (вдруг заинлайнить что-то решил, например) и подменяет адрес возврата.
- Умеет превращать простые объекты в наборы скаляров (типа Point = float x, float y).
- Умеет инкрементальную компиляцию.
- Умеет ликвидировать код синхронизации там, где он не нужен (если значение не утекает за пределы текущего вызова функции). Например, StringBuffer.
- Умеет девиртуализацию функций (если вариантов нет) и инлайн final static членов класса.

Cборка мусора в Java без пауз / Алексей Рагозин

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

Резюме — нет, сборки мусора без пауз не бывает. Если очень много выделять памяти и не освобождать автоматически, в какой-то момент она всё равно кончится и придётся останавливать мир :-). А ещё — паузы можно уменьшить, и их отсутствие мало от чего спасёт — в real-time применениях всё равно найдётся ещё 100500 других проблем (свопинг, кривые руки и т.п).

Какие вообще есть алгоритмы сборки мусора?

Простейшее (mark&sweep) — остановили всех, прошлись рекурсивно по всем объектам, пометили достижимые, удалили остальные.
Concurrent mark&sweep с барьерами на запись: Немножко всех тормозим, находим корневые ссылки, потом всех возобновляем и маркируем достижимые объекты, потом всех приостанавливаем снова, перемаркируем то, что было изменено, опять всех возобновляем и удаляем отмеченное недостижимым. Барьер — это просто bitmap, который даёт нам понять, что же было изменено.
Разделение кучи на поколения — «старые» объекты живут долго и редко собираются, «молодые» — живут недолго и собираются часто.
Алгоритм «метроном» — сборка копированием с барьерами на чтение. Есть 2 области памяти: «старая» и «новая». Сначала все объекты в старой. Параллельным потоком включается сборка мусора, и начиная с этого момента, если поток при чтении видит, что объект в «старой» области — он его нерекурсивно копирует в новую и обновляет ссылку. Таким образом, код работает только с «новыми» объектами. Мусорщик параллельно тоже перемещает «старые» объекты в «новую» область памяти, обновляя ссылки. Процесс когда-то заканчивается. В общем-то идея хороша, но — накладные расходы немаленькие.
JVM-суперкомпьютер Azul Vega. По сути, хитрожопый вариант «метронома» с поколениями и аппаратной поддержкой, а именно — с дополнительными битами в адресах, служащими как барьеры (плюс для работы со слабыми ссылками). Но — физические JVM CPU делать невыгодно, они уже все почти повымерли, поэтому потом они сделали Azul JVM с той же идеей, которая использовала сначала виртуализацию, а потом и просто модуль ядра Linux x86-64 для поддержки этих самых бит. Ещё у неё есть 3 стратегии копирования — байтами (до 256 Кб), 4 Кб страницами (до 16 Мб), и 2 Мб страницами (> 16 Мб объекты).

См. также «шпаргалку» по сборке мусора в JVM от автора.

Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Персональные инструменты

Просмотры