|
Персональные инструменты |
|||
|
Highload-2013: Отчёт Виталия ФилипповаМатериал из CustisWikiИнформация о конференции, организация:
Общая атмосфера:
Содержание[убрать]
День 1Экосистема Сочи 2014. Космос как предчувствие / Михаил Чеканов (Оргкомитет Сочи 2014), Ольга Куликова (Articul Media)На докладе не был, отмечаю потому, что из интересного там было очевидное :-) сайт сначала сделали на БИТРИКСЕ, но потом всё-таки поняли, что с этого нереального ужоса надо сваливать. И таки свалили — переписали всё сами и довольны. (незачёт) Как поставить миграцию баз данных на поток / Илья Космодемьянский, Роман ДрузягинЧуваки пытались рассказывать доклад вдвоём попеременно. Это хороший формат выступления, но слайды у них тем не менее были совершенно жуткие, да и сам рассказ таил в себе больше воды.
Полнотекстовый поиск в Почте Mail.Ru / Дмитрий Калугин-БалашовЗашёл в самом конце, услышал чуть-чуть. В общем, смысл в том, что полнотекстовый поиск написан полностью кастомный, хранит отдельный индекс для каждого пользователя, и умеет сортировать только по дате. Вроде внутри некая лог-структура. Из смешного — их спросили, неужели вам не подошло ни одно из готовых решений, зачем вы написали свой поиск? Они ответили — потому что есть ресурсы! («because we can!») Своевременная оптимизация / Carlos Bueno (Facebook)Доклад рассказан неплохо, хоть содержательность и хромает. В основном было много общих слов. Чувак из фейсбука перевёл слайды на русский язык (на каждом слайде фраза была и по-английски, и по-русски)… но, видимо, перевёл google translate’ом, потому что были такие перлы:
Ещё из смешного — доклад он начал со слов:
И тут кто-то спросил (было в твиттере, было ли в реале — не уверен) :D
А дальше общие размышления:
Распространение систем на Scala благодаря Finagle / Julio Capote (Twitter)Товарищ из Twitter’а просто рассказывал какая хорошая scala, и какая у них есть под неё библиотека RPC Finagle, я как-то выпал из контекста. Опыт переезда соцсети Livestreet с PHP/MySQL на NodeJS/Redis/Lua / Дмитрий Дегтярев (Хабикаса)Странный доклад… У чуваков был стандартный сайтик на стандартной отстойной блого-социально-подобной CMS’ке Livestreet. Данных там мало, всего несколько тысяч постов. И его вместо того, чтобы просто переписать, переписали на сильно извращённый вариант:
Сразу отметим: запихивать толстые хранимые процедуры в 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 — типичный веб-фреймворк:
Как стало: В общем, им всё это поднадоело, они решили всё переписать и изобрели свой «сервис-ориентированный» DSL на питоне, на основе сервера Tornado. DSL называется «Ясень», состоит из изолированных обработчиков (у которых на входе 1 объект и на выходе 1 объект) и довольно прост, умеет всего 3 вещи:
Цепочки запускаются внутри одного процесса, то есть даже никакие JSON’ы между серверами туда-сюда не гоняются. Каждый обработчик при этом можно дёрнуть извне, таким образом отлаживаясь. Система в целом написана на этом DSL, и его даже понимают менеджеры — бывает, приходят и говорят: а вставьте-ка мне вот сюда вот такой обработчик… И они вставляют. Архитектура хранения — данные делятся на несколько видов:
Какие есть процессы:
Как делается синхронизация данных на серверах после сбоя — он не рассказывал. Возможно, делается руками админа-«пингвина». Как мы храним 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 / Антон ЛебедевичДоклад интересный — про то, как можно применять методы статистики для выявления потенциальных проблем системы по графикам кучи показателей с кучи серверов. Ну или как их хотя бы сгруппировать / почистить так, чтобы количество стало вменяемым и в нём мог разобраться человек. Выявление аномалий:
Группировка показателей (поиск зависимостей между графиками):
Всё это (или по меньшей мере часть), как ни странно, реализована в опенсорсном виде и её можно пощупать: https://github.com/etsy/skyline, https://github.com/etsy/oculus (части некого Kale Stack). День 2Завалить в один запрос: уязвимости веб-приложений, приводящие к DoS / Иван Новиков (ONsec)Доклад немного в стиле «капитан ясен хрен», и явно было заметно, что товарищ пиарил свою конторку. Рассказывал про баги в сайтиках, через которые «всё поломать» не получится, но DoS устроить вполне можно. Часть идей была полным (или НЕполным) бредом:
Некоторые идеи были вполне ничего:
Но про самое классическое чувак почему-то не вспомнил! Самое классическое — это банальное открытие последних страниц какого-нибудь длинного тяжёлого поиска. В один запрос, конечно, не завалишь, но лёгким DoS’ом заставить сайт дико тупить от такого действия можно очень часто. Масштабирование скомпилированных приложений / Joe DomatoПричем тут «масштабирование» — непонятно. Рассказ был про автоматизацию сборки и CI. Послушал чуть-чуть, услышал про:
(полный отстой) Анализ производительности и оптимизация MySQL / Пётр Зайцев (Percona)Тут я даже заметок никаких не напишу. Доклад вообще ни о чём, его можно было не делать. Там были не просто общие слова, а 100%-ная вода, состоящая из тривиальнейших идей. Про оптимизацию MySQL там не было вообще ничего, ни одной фразы. Кто после такого доклада пошёл ещё и на мастер-класс этого мастера лить воду — лопух ;-) Платформа для Видео сроком в квартал / Александр Тоболь (Одноклассники)Рассказ о том, как Одноглазники передалали свой видеосервис на собственную платформу. До этого он работал сначала на платформе видео@мейл.ру, потом на rutube. Но, судя по всему, ни качество, ни стабильность ни того, ни другого их не устроило, а задача создания средненького видеосервиса — она в принципе не такая уж и суперсложная, поэтому они его решили сделать сами. Объёмы нормальные, в день: 10 млн уников, 60 млн просмотров (до 100 гб/сек), 50 тысяч новых видео (= 5 ТБ = до 5 гб/сек). Итого устроено всё довольно просто:
Вещание видео на 10 ГБит/с / Максим Лапшин (Erlyvideo)Erlyvideo теперь вышел на американский рынок и называется Flussonic. И, видимо, теперь его используют разные группы нехороших лиц, наживающихся на продаже «нихрена» (контента). Сам Erlyvideo от этого, правда, хуже не стал (а то и стал лучше) и остался опенсорсным, что, безусловно, хорошо. Рассказывал про разные нюансы раздачи видео с одного сервера на 10 гигабит. Типа процы в принципе не особо ускорились за 5 лет, но зато подешевели 10 гбит каналы, и появились SSD’шки, и вроде как стало можно раздавать и 10 гигабит. Например, на нагрузках в несколько гигабит у них подыхал software raid. И прочее — прерывания, дисковые очереди и т. п. DDoS атаки в России в 2013 / Александр Лямин (QratorLabs/HLL)Обзор ситуации с DDoS’ом в России за этот год. Интересное:
История 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 (само оно статистику не считает), во-вторых, часть оптимизаций полезна для «медленных» выполнений запроса, без индексов. Из юмора:
Как рассуждать о производительности хранилищ баз данных / 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 ограничивает производительность — она не может быть больше, чем максимальная скорость работы дисков делить на усиление. А теперь примерные оценки этих значений:
Примечания:
(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 конкретно тюны были следующие:
Сравнение распределенных файловых систем / Marian Marinov (1H Ltd.)Доклад с качественным вдумчивым бенчмарком нескольких распределённых файловых систем (линуксовых, разумеется).
JIT компиляция в виртуальной машине Java / Алексей РагозинТот же мэн, что рассказывал на SECR’е про Performance Test Driven Development. «Серия» из двух докладов, с общим названием «JVM Deep Dive» :-) Первый доклад — про JIT.
Cборка мусора в Java без пауз / Алексей РагозинВторой доклад, тоже интересный, теперь про сборку мусора и про то, бывает ли она без пауз. Резюме — нет, сборки мусора без пауз не бывает. Если очень много выделять памяти и не освобождать автоматически, в какой-то момент она всё равно кончится и придётся останавливать мир :-). А ещё — паузы можно уменьшить, и их отсутствие мало от чего спасёт — в real-time применениях всё равно найдётся ещё 100500 других проблем (свопинг, кривые руки и т.п). Какие вообще есть алгоритмы сборки мусора?
См. также «шпаргалку» по сборке мусора в JVM от автора.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
||||||||||||||||||||||||||||||||||||||||||