Highload 2010 day two
Никак не мог найти время, чтобы написать про вторую часть конференции. Теперь я делаю это в рабочее время ;) в качестве отчета о поездке :) Сегодня у нас YotaAir - работаем вне офиса. Правда, два таких предыдущих дня я работал в офисе. Все-таки лучше рабочего места ничего нет. К тому же тогда было тихо и комфортно. Писать же про хайлоад вполне можно и дома... чем я и занимаюсь :)
Итак... Во второй день было уже не два зала, а три - первых двух все также расказывали, кто как и с какими проблема боролся, а в третьем проводилось что-то вроде тренингов-семинаров. Мы решили не особо напрягаться и придти на конференцию чуть позже начала, ибо ничего особо интересного для нас там не было. Единственное, на что можно было бы сходить, это "Практическое создание крупного масштабируемого проекта web 2.0 с нуля". Но мы отдали предпочтение комфортному сну и неторопливому завтраку. ;) Да и вообще во второй день до обеда особо полезных для нас докладов не было. Недолго думая, для себя я выбрал пару доклад про Python. Его часто используют в связке с плюсами, что мне, как заядлому плюсовику, сильно импонировало.
Профилирование памяти в приложениях на Python, Антон Грицай (Андромеда)
В качестве вводной части, Антон осветил ряд неочевидных случаев утечек памяти. Объяснил, почему это критично для серверов работающих на питоне. Немного рассказал, как устроены сборщики мусора в большинстве реализаций. Оказывается, почти все построены на подсчете ссылок! (такие сборщики мусора часто используются и на плюсах, вот оно, родство ;) ) Аргумент в пользу таких сборщиков - эффективность по времени работы и памяти. Далее Антон рассказал про возможные варианты поиска этих утечек, коих оказалось не особо много (кто бы сомневался :) ). Потом поделился опытом поиска профилировщика памяти, перечислил несколько вариантов, а потом порекомендовал использовать heapy, как единственный профилировщик, достойный внимания. Остаток доклада Антон посвятил рассказу о том, как правильно работать с heapy, который по ощущения является достаточно мощным (но специфичным) инструментом. Стоит отметить, что этот профилировщик может производить отладку на удаленной машине, что весьма удобно. У этого варианта даже есть свой плюс - профилировщик не влияет на расход памяти, что несколько упрощает профилирование. В целом, создалось ощущение, что профилирование памяти на питоне не развито. И, как мне кажется, когда начнут использоваться более продвинутые сборщики мусора, проблема перестанет быть актуальной. А пока живем с тем, что есть.
Сервер-агрегатор на Python, А. Сумин, М. Сабуренков, П. Труханов (Head Hunter)
Доклад от специалистов HH был со своей изюминкой. Человек, который разрабатывал эту систему и должен был рассказать о ней, перешел в другую компанию, и вместо него отдувалось 3 человека, которые тоже с этим были связаны, что достойно уважения. Начали они издалека, с исторической подоплеки развития своего сервиса. Давным-давно они выбирали систему, на которой можно было бы построить их сервис. Выбор пал на XScript от Яндекса, в частности из-за того, что он опирается на возможности XSLT для шаблонизатора, что не потребовало большой переделки сайта. По началу продукт Яндекса нареканий не вызывал, но позже все с большим трудом удавалось реализовывать новые требования к системе. XML оказался не очень удачным вариантом для реализации какой-либо логики в шаблонизаторе (представители Яндекса утверждали, что сейчас появилась возможность использовать lua, но тогда ее видимо не было). Все это привело к написанию на Python своего фронтенда для сборки данных и выдачи страниц. Меня заинтересовал принцип его работы. Все url адреса отображаются на диск в конкретные каталоги. В каждом каталоге лежат либо статические файлы, либо скрипты на Python, либо и то, и другое. При обращение по заданному адресу проверяется наличие скрипта, и в случае его наличия, он запускается для обработки запроса. Так же представители HH упомянули memcached, который используют для оптимизации поиска. В целом создалось впечатление, что ребята изобрели свой велосипед (и он работает!), но они им гордятся и готовы рассказывать всем желающим. Их движок доступен всем желающим вместе с исходниками.
Tarantool/Silverbox: высокопроизводительная база данных в оперативной памяти, Юрий Востриков (Mail.ru)
Юрий начал с того, что популярный memcached их не устроил по ряду причин и они решили сделать свою собственную базу данных в оперативной памяти. Весь остальной доклад, в основном, был посвящен проблемам быстродействия и тем, как их решили в Mail.ru. Высокая нагрузка заставляет бороться за каждую мелочь, писать свой собственный распределитель памяти, патчить ядро Линукса и прочее. Меня заинтересовал распределитель памяти. Решение не новое и узкоспециализированное, но интересное: распределитель памяти выделяет блоки памяти вполне конкретного размера, что позволяет избавиться от фрагментации памяти. В целом создалось впечатление о том, что решалась сложная частная проблема, и решение у нее было подобное же.
Оптимизация одного из топовых приложений для социальной сети ВКонтакте, Максим Лапшин
На мой субъективный взгляд, это был лучший доклад на конференции по качеству доклада. Максим рассказывал об одном из проектов, когда к ним обратились владельцы одного из приложений ВКонтакте с просьбой решить проблемы с производительностью. Начальное положение таково: некая служба знакомств, написанная на Ruby on Rails, 30000 пользователей, добавивших это приложение себе на страницу (в общем-то мелочь ;) ), примерно 9с на обработку запроса. Решить проблему позволило профилирование, профилирование и еще раз профилирование. Практически каждый раз профилирование опровергало начальные предположения о том, где находится узкое место. Первым шагом к ускорению работы было отключение memcached практически ото всюду. Отказ от кэширования данных, которые в этом не нуждаются, дал выигрыш в 1.5-2 раза. Далее Максим поведал о том, что плохое администрирование сильно мешало отладке сервиса. Сервера периодически сбоили до того момента, пока не наняли грамотного системного администратора. Архитектура серверов достаточно проста: RR - RabbitMQ - DB. У команды Максима опасения были в первую очередь по поводу первых двух компонент. Но, как оказалось, основные проблемы были связаны с базой данных. В результате ее просто разделили на несколько независимых. Данные системы таковы, кто это можно сделать. Было одно требование к системе, которое могло препятствовать этому, но заказчик решил, что оно не приоритетное и отказался от него. Ускорение работы вызвало интересный лавинообразный эффект - чем быстрее работало приложение, тем больше пользователей устанавливало его себе. По окончании работ количество пользователей перевалило за миллион. На вопрос, что сейчас стало с этим приложением, Максим сказал, что не особо в курсе, но по слухам его зачем-то переписали на php.
ВКонтакте, Олег Илларионов, Павел Дуров
Хедлайнером конференции можно считать именно этих парней. Сначала Олег рассказал о паре работ, которые они делали не так давно, а потом пришел Павел и отвечал на многочисленные вопросы. В целом полезной информации было мало, но посмотреть на звезд Рунеты было интересно. Хочется отметить:
- Олег рассказывал о новой системе сообщений ВКонтакте. О том, что они решили реализовать Jabber на Node.js и им пришлось допиливать последний под свои нужды. В какой-то мере я даже завидую этим парням, которые не боятся использовать полусырой продукт :)
- На многие вопросы Павел отвечал односложно "да, это так" или "нет, у нас этого нет".
- На каждый второй вопрос, касаемо внутреннего устройства ВКонтакте, Павел отвечал "это делается сишным кодом, написанным нашими олимпиадниками". В конце концов из него вытянули, что в принципе, это у них своя база данных.
- ВКонтакте в основном сражается с вопросами нагрузки из-за большого количества пользователей, поддержки системы в работоспособном состоянии. Создание новых фич занимает далеко не 100% времени (кто бы сомневался :) ).
- Многофункциональность серверов (файл-сервер и сервер приложений на одной физической машине) позволяет эффективно расходовать их ресурсы.
- ВКонтакте давно вышло на тот уровень, когда мощность дата-центра считается в киловаттах электроэнергии, а не в мегагерцах процессоров и мегабайтах ОЗУ.
- Все крупные социальные сети (ВКонтакте, Facebook, прочие) периодически собираются и обсуждают, кто как с какими проблемами сталкивается и как их решает. Интересно, будет ли когда-нибудь доступен "роуминг" в социальных сетях... ;)
- Кажется, что ВКонтакте повезло с коллективом. Олимпиадники + энтузиасты фронтендов + менеджмент позволяет ему быстро, гибко и эффективно реагировать на все.
Квадратный стол про использование many-core CPU, Google, Intel, Яндекс, Rambler
Представители четырех вышеобозначенных компаний отвечали на вопросы о многоядерных процессорах. Из интересного была только рекомендация вместо объектов синхронизации (в первую очередь мьютексов) использовать альтернативные варианты. Например, сохранить начальное значение, сделать вычисления и присвоить результат, если исходное значение не поменялось, в противном случае повторить процедуру сначала.
Сервис нагрузочного тестирования ddosme.ru, Иван Самсонов (Scalaxy)
В общем, Иван попытался порекламировать сервис свой нагрузочного тестирования. В основе лежит найденный им инструмент, к которому сделан веб-интерфейс. Каких бы то ни было преимуществ озвучено не было. Желания использовать этот сервис не появилось :)
Сравнительный анализ хранилищ данных, Олег Царев, Кирилл Коринский (Percona, Roox)
Докладчики попытались теоретически оценить несколько баз данных в зависимости от задач. На вопрос "почему выбрали именно эти базы" был получен ответ, что это "наиболее популярные базы". А на вопрос "почему нет sqlite" - "есть много разных баз, мы сравнивали те, что вспомнили". Что несколько испортило впечатление о докладе. В конце ребята быстро попрощались со словами "у нас скоро поезд и самолет".
Использование 0MQ для построения low latency распределенных систем, Андрей Охлопков, Алексей Ермаков (Global Hedge Capital Group)
В целом доклад представлят из себя введение в работу с относительно новой бибилиотекой для реализации серверов очередей сообщений. ZeroMQ представляет API для построения своих систем обмена сообщениями. ZeroMQ не требует наличия сервера-брокера сообщений, хотя и позволяет его реализовать достаточно просто. Используя эту библиотеку, можно достаточно гибко настраивать потоки сообщений между различными серверами. Например, можно построить широковещательный сервер, который отдает данные многим другим, или наоборот агрегатор сообщений. И то, и другое активно применяется в брокерских системах (одну из них как раз делают докладчики). Запомнилось, что в качестве протокола обмена данными ребята используют ProtocolBuffer (от Google). По итогам доклада у меня создалось впечатление, что систему следует применять, когда есть необходимость достаточно просто конфигурировать большое количество потоков данных между разными серверами.
Итак... Во второй день было уже не два зала, а три - первых двух все также расказывали, кто как и с какими проблема боролся, а в третьем проводилось что-то вроде тренингов-семинаров. Мы решили не особо напрягаться и придти на конференцию чуть позже начала, ибо ничего особо интересного для нас там не было. Единственное, на что можно было бы сходить, это "Практическое создание крупного масштабируемого проекта web 2.0 с нуля". Но мы отдали предпочтение комфортному сну и неторопливому завтраку. ;) Да и вообще во второй день до обеда особо полезных для нас докладов не было. Недолго думая, для себя я выбрал пару доклад про Python. Его часто используют в связке с плюсами, что мне, как заядлому плюсовику, сильно импонировало.
Профилирование памяти в приложениях на Python, Антон Грицай (Андромеда)
В качестве вводной части, Антон осветил ряд неочевидных случаев утечек памяти. Объяснил, почему это критично для серверов работающих на питоне. Немного рассказал, как устроены сборщики мусора в большинстве реализаций. Оказывается, почти все построены на подсчете ссылок! (такие сборщики мусора часто используются и на плюсах, вот оно, родство ;) ) Аргумент в пользу таких сборщиков - эффективность по времени работы и памяти. Далее Антон рассказал про возможные варианты поиска этих утечек, коих оказалось не особо много (кто бы сомневался :) ). Потом поделился опытом поиска профилировщика памяти, перечислил несколько вариантов, а потом порекомендовал использовать heapy, как единственный профилировщик, достойный внимания. Остаток доклада Антон посвятил рассказу о том, как правильно работать с heapy, который по ощущения является достаточно мощным (но специфичным) инструментом. Стоит отметить, что этот профилировщик может производить отладку на удаленной машине, что весьма удобно. У этого варианта даже есть свой плюс - профилировщик не влияет на расход памяти, что несколько упрощает профилирование. В целом, создалось ощущение, что профилирование памяти на питоне не развито. И, как мне кажется, когда начнут использоваться более продвинутые сборщики мусора, проблема перестанет быть актуальной. А пока живем с тем, что есть.
Сервер-агрегатор на Python, А. Сумин, М. Сабуренков, П. Труханов (Head Hunter)
Доклад от специалистов HH был со своей изюминкой. Человек, который разрабатывал эту систему и должен был рассказать о ней, перешел в другую компанию, и вместо него отдувалось 3 человека, которые тоже с этим были связаны, что достойно уважения. Начали они издалека, с исторической подоплеки развития своего сервиса. Давным-давно они выбирали систему, на которой можно было бы построить их сервис. Выбор пал на XScript от Яндекса, в частности из-за того, что он опирается на возможности XSLT для шаблонизатора, что не потребовало большой переделки сайта. По началу продукт Яндекса нареканий не вызывал, но позже все с большим трудом удавалось реализовывать новые требования к системе. XML оказался не очень удачным вариантом для реализации какой-либо логики в шаблонизаторе (представители Яндекса утверждали, что сейчас появилась возможность использовать lua, но тогда ее видимо не было). Все это привело к написанию на Python своего фронтенда для сборки данных и выдачи страниц. Меня заинтересовал принцип его работы. Все url адреса отображаются на диск в конкретные каталоги. В каждом каталоге лежат либо статические файлы, либо скрипты на Python, либо и то, и другое. При обращение по заданному адресу проверяется наличие скрипта, и в случае его наличия, он запускается для обработки запроса. Так же представители HH упомянули memcached, который используют для оптимизации поиска. В целом создалось впечатление, что ребята изобрели свой велосипед (и он работает!), но они им гордятся и готовы рассказывать всем желающим. Их движок доступен всем желающим вместе с исходниками.
Tarantool/Silverbox: высокопроизводительная база данных в оперативной памяти, Юрий Востриков (Mail.ru)
Юрий начал с того, что популярный memcached их не устроил по ряду причин и они решили сделать свою собственную базу данных в оперативной памяти. Весь остальной доклад, в основном, был посвящен проблемам быстродействия и тем, как их решили в Mail.ru. Высокая нагрузка заставляет бороться за каждую мелочь, писать свой собственный распределитель памяти, патчить ядро Линукса и прочее. Меня заинтересовал распределитель памяти. Решение не новое и узкоспециализированное, но интересное: распределитель памяти выделяет блоки памяти вполне конкретного размера, что позволяет избавиться от фрагментации памяти. В целом создалось впечатление о том, что решалась сложная частная проблема, и решение у нее было подобное же.
Оптимизация одного из топовых приложений для социальной сети ВКонтакте, Максим Лапшин
На мой субъективный взгляд, это был лучший доклад на конференции по качеству доклада. Максим рассказывал об одном из проектов, когда к ним обратились владельцы одного из приложений ВКонтакте с просьбой решить проблемы с производительностью. Начальное положение таково: некая служба знакомств, написанная на Ruby on Rails, 30000 пользователей, добавивших это приложение себе на страницу (в общем-то мелочь ;) ), примерно 9с на обработку запроса. Решить проблему позволило профилирование, профилирование и еще раз профилирование. Практически каждый раз профилирование опровергало начальные предположения о том, где находится узкое место. Первым шагом к ускорению работы было отключение memcached практически ото всюду. Отказ от кэширования данных, которые в этом не нуждаются, дал выигрыш в 1.5-2 раза. Далее Максим поведал о том, что плохое администрирование сильно мешало отладке сервиса. Сервера периодически сбоили до того момента, пока не наняли грамотного системного администратора. Архитектура серверов достаточно проста: RR - RabbitMQ - DB. У команды Максима опасения были в первую очередь по поводу первых двух компонент. Но, как оказалось, основные проблемы были связаны с базой данных. В результате ее просто разделили на несколько независимых. Данные системы таковы, кто это можно сделать. Было одно требование к системе, которое могло препятствовать этому, но заказчик решил, что оно не приоритетное и отказался от него. Ускорение работы вызвало интересный лавинообразный эффект - чем быстрее работало приложение, тем больше пользователей устанавливало его себе. По окончании работ количество пользователей перевалило за миллион. На вопрос, что сейчас стало с этим приложением, Максим сказал, что не особо в курсе, но по слухам его зачем-то переписали на php.
ВКонтакте, Олег Илларионов, Павел Дуров
Хедлайнером конференции можно считать именно этих парней. Сначала Олег рассказал о паре работ, которые они делали не так давно, а потом пришел Павел и отвечал на многочисленные вопросы. В целом полезной информации было мало, но посмотреть на звезд Рунеты было интересно. Хочется отметить:
- Олег рассказывал о новой системе сообщений ВКонтакте. О том, что они решили реализовать Jabber на Node.js и им пришлось допиливать последний под свои нужды. В какой-то мере я даже завидую этим парням, которые не боятся использовать полусырой продукт :)
- На многие вопросы Павел отвечал односложно "да, это так" или "нет, у нас этого нет".
- На каждый второй вопрос, касаемо внутреннего устройства ВКонтакте, Павел отвечал "это делается сишным кодом, написанным нашими олимпиадниками". В конце концов из него вытянули, что в принципе, это у них своя база данных.
- ВКонтакте в основном сражается с вопросами нагрузки из-за большого количества пользователей, поддержки системы в работоспособном состоянии. Создание новых фич занимает далеко не 100% времени (кто бы сомневался :) ).
- Многофункциональность серверов (файл-сервер и сервер приложений на одной физической машине) позволяет эффективно расходовать их ресурсы.
- ВКонтакте давно вышло на тот уровень, когда мощность дата-центра считается в киловаттах электроэнергии, а не в мегагерцах процессоров и мегабайтах ОЗУ.
- Все крупные социальные сети (ВКонтакте, Facebook, прочие) периодически собираются и обсуждают, кто как с какими проблемами сталкивается и как их решает. Интересно, будет ли когда-нибудь доступен "роуминг" в социальных сетях... ;)
- Кажется, что ВКонтакте повезло с коллективом. Олимпиадники + энтузиасты фронтендов + менеджмент позволяет ему быстро, гибко и эффективно реагировать на все.
Квадратный стол про использование many-core CPU, Google, Intel, Яндекс, Rambler
Представители четырех вышеобозначенных компаний отвечали на вопросы о многоядерных процессорах. Из интересного была только рекомендация вместо объектов синхронизации (в первую очередь мьютексов) использовать альтернативные варианты. Например, сохранить начальное значение, сделать вычисления и присвоить результат, если исходное значение не поменялось, в противном случае повторить процедуру сначала.
Сервис нагрузочного тестирования ddosme.ru, Иван Самсонов (Scalaxy)
В общем, Иван попытался порекламировать сервис свой нагрузочного тестирования. В основе лежит найденный им инструмент, к которому сделан веб-интерфейс. Каких бы то ни было преимуществ озвучено не было. Желания использовать этот сервис не появилось :)
Сравнительный анализ хранилищ данных, Олег Царев, Кирилл Коринский (Percona, Roox)
Докладчики попытались теоретически оценить несколько баз данных в зависимости от задач. На вопрос "почему выбрали именно эти базы" был получен ответ, что это "наиболее популярные базы". А на вопрос "почему нет sqlite" - "есть много разных баз, мы сравнивали те, что вспомнили". Что несколько испортило впечатление о докладе. В конце ребята быстро попрощались со словами "у нас скоро поезд и самолет".
Использование 0MQ для построения low latency распределенных систем, Андрей Охлопков, Алексей Ермаков (Global Hedge Capital Group)
В целом доклад представлят из себя введение в работу с относительно новой бибилиотекой для реализации серверов очередей сообщений. ZeroMQ представляет API для построения своих систем обмена сообщениями. ZeroMQ не требует наличия сервера-брокера сообщений, хотя и позволяет его реализовать достаточно просто. Используя эту библиотеку, можно достаточно гибко настраивать потоки сообщений между различными серверами. Например, можно построить широковещательный сервер, который отдает данные многим другим, или наоборот агрегатор сообщений. И то, и другое активно применяется в брокерских системах (одну из них как раз делают докладчики). Запомнилось, что в качестве протокола обмена данными ребята используют ProtocolBuffer (от Google). По итогам доклада у меня создалось впечатление, что систему следует применять, когда есть необходимость достаточно просто конфигурировать большое количество потоков данных между разными серверами.