Персональные инструменты
CUSTIS
Сайт CUSTIS →
Вакансии
Блог команды
Архив событий
Архив публикаций
Навигация
Заглавная страница
Свежие правки
Случайная статья
Справка
Поиск
 
Инструменты
Ссылки сюда
Связанные правки
Спецстраницы
Чистый HTML
→M$WORD
→OOffice

РИТ:Высокие нагрузки-2008 (Отчет Стаса Фомина)

Материал из CustisWiki

Перейти к: навигация, поиск

Замечания и предложения направлять автору.

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

Сразу замечу, хотя явно вроде не указано (в списке спонсоров-соорганизаторов десятки значков участников, даже «udaff.com»), что эту конференцию (highload.info, не путать с highload.ru) было бы правильней именовать «Яндекс:Нагрузки», ибо практически «контрольный пакет» всех докладов был от «Я», также было немало Я-участников в узнаваемой униформе креативных футболках. Похоже Яндекс тут был ключевым организатором, и ничего плохого в этом факте нет. Может стоило тогда так и назвать конференцию и провести ее на самой территории Яндекса, с экскурсиями по машинному залу и т. п. Когда-то (1999) я был в серверной Яндекса, но сейчас, думаю, там все сильно круче.


Содержание

Общие соображения

Понравилось

  • Огромные плазменные телевизоры в залах. Лучше, чем проекторы, особенно лучше, чем «проекторы с тыльной стороны экрана» (были такие на РИТ-2008, убивали все цвета в ноль).
  • Специально выделенное время (порядка 15 минут на доклад) на вопросы. Зачастую интересуют именно вопросы (даже не всегда ответы), чтобы уловить, что интересует сообщество.
  • Добираться метропешеходу вполне терпимо (по сравнению с дырой типа Крокус-сити). Претензии автовладельцев имеет смысл посылать лесом, ибо в Москве автомобиль уже давно ни роскошь, ни средство передвижения.

Update: Сейчас, когда в Крокус-сити провели Крокус-метро, аргумент снимается.

Проблемы и предложения

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

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

  • Возможно был бы полезен формат 5-минутных блиц-докладов. Некоторые доклады вполне ужимались до такого формата. Стоит попробовать — то есть либо большой доклад с вопросами-обсуждениями, либо 5 минут позора (или успеха), — и следующий.
  • Хотелось бы публикации докладов (хотя бы презентаций), немедленно после их показа на конференции. Вот сейчас я, пока еще все не забыл, пытаюсь написать отчет о конференции, пока у меня клубятся впечатления и пара-тройка порожденных мыслей — но уже не помню точно, кто и что утверждал (могу путать тезисы разных докладов). Оно конечно эти презентации потом опубликуют — но тогда у меня потухнут собственные впечатления, и смысла писать что-то не будет. В общем, никаких технических проблем к немедленной публикации презентаций после их показа я не вижу, и проблем авторам это не создает — в отличие от обязательного предоставления презентации на флешке перед конференцией, авторы могут править презентацию до самого момента выступления, а потом она должна попадать в руки организаторов и немедленно публиковаться.

День первый

Что такое нагрузка

Хороший доклад «еще раз о компьютерной архитектуре от практика-железячника», некие тривиальные основы о «сферическом вебсервере в вакууме».

  • Диски, память, сеть. Кэш, кэш, кэш.
  • Прочувствуйте «физику» процесса, подивитесь огромному GAPу эффективности диска на последовательном и рандомном доступе.
  • Мимоходом «похоронены» SAS/SCSI диски — их удел только в «кеширующих» машинах с высоковероятным рандом-доступом, а в основном нечего выделываться, берите обычные SATA и используйте правильные алгоритмы (сортировки дисковых массивов — только слиянием и т. п.).
  • RAIDы вроде тоже заругали (или в другом докладе, не помню) — смысл, что надежность должна обеспечиваться уровнем выше, типа вместо 3 живучих «Тигров» пусть будет 30 Т-34.
  • По памяти и CPU был тезис, что хотя многопроцессность была отстой, современная многотредовость рулит (тредов должно быть не меньше, чем дисков плюс процессоров, а еще лучше заложить запас).
  • AMD с привязкой памяти к процессорам must die.

О проектах, отягощенных производительностью

В Яндексе разработчик – творческое начало, создающее проекты, отягощенные нагрузкой.

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

  • общедоступная вебсистема, дофига пользователей, большие объемы, куча транзакций, никакой сложной логики, пофиг на отказы (нажмите Refresh, если что не нравится и т. п.)
  • корпоративные системы — сложная логика, то есть одна транзакция дает движение в куче таблиц-счетов и т. п., и вообще объем кода в строчках и человеко-годах огромен. Ошибаться нельзя, падать нельзя, но нагрузка плевая.

Но есть и редкий третий тип. Речь зашла о редких высоконагруженных «бизнес-логичных» системах (такие имеет смысл ловить наверно только в ЖКХ — офигически сложные расчеты всяких там льгот, куча транзакций и т. п.), или какой другой массовый биллинг (телекоммуникационный). Банки думаю не — кроме яндекс.денег, любой интернет-банк по нагрузке отдыхает.

Ну а дальше докладчик прошелся по всем аспектам разработки таких систем, разрушая мифы, раздавая эпитеты и приговоры различным технологиям:

  • СУБД кроме Oracle, DB2, MySQL и PostgreSQL — ересь,
  • Oracle DBA зажрались и в массе лохи,
  • Микрософтовский стек ASP.NET+MSSQL — дорого из-за серверных лицензий.
  • Java есть современный надежный Cobol, и это есть хорошо. Вообще «убогость языка — бонус к надежности».
  • С# сам по себе ничего, но развертывание дороговато, (в основном за виндовс-сервер-лицензии).
  • Python прет (особенно Django), возможно будущее за Java+Python.
  • Всех (обоих) творцов на Erlangе гнать-избегать,
  • RoR — тормозит,
  • двухзвенка масштабируется отстойно (привет «Oracle и PL/SQL» подходу), по сравнению с трехзвенкой, потому что кэш СУБД слишком тупой-низкоуровневый.
  • нефиг выделываться с XML-сериализацией — CPU на ветер.

Другие мысли:

  • на инфраструктуру не больше 10 % прибыли.
  • автоматизация тестирования вебформ — обязательно.

В общем, наверно самый полезный для нас доклад, надо дождаться видео (я даже запросил DVD-диски, может пришлют), и смотреть всем.

Диски не прислали.

Как писать высокопроизводительные сервера

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

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

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

Ну еще известна шизофреничная сложность отладки программы с тредами, на что докладчик искренне удивлялся — «зачем отлаживать? не проще ли писать без ошибок?».

Вроде как проверено на крупных яндекс-проектах, типа краулера и верхнего уровня поиска.

Была жесткая дискуссия, требовали доказательств, цифр, корректного эксперимента.

Я лично склонен поверить докладчику. Причем с корутинами думаю не столкнусь, а то что апач2 с тредами хорош (пусть даже чуть хуже FSM) — это хорошо, возможно альтернативы ему отомрут сами со временем.

HCS — система хранения данных в Рамблере

HCS (Hierarchically Compressed Stream) — некая библиотека для реализации некоторой алгебры операций (слияния, фильтрация, агрегация,…) над сверхбольшими плоскими файлами. (1011 строк, 10Tb/ 200Gb обновлений в день).

Работает быстро (сравнивали правда с неоптимизированными движками MySQL), но, насколько я понял, это не параллелиться (а ведь есть Hadoop, который вроде как можно было бы применить для этих задач).

Вроде готовится к публикации в опен-сорс.

Примечание два года спустя — так и не выложили.

Сервис хранения данных на базе SQL Server Data Services

Маркетинговый доклад. Верный признак «чисто маркетинга», когда всякие «архитектурные» картинки рисуются блоками с градиентной заливкой, всякий гламур и анимация на слайдах. По сути некая компиляция whitepaperов разных технологий (SaaS, DaaS, PaaS,… все модные buzzwords, все в кучу).

Интерес (судя по заполненности зала) был слабоват.

Проблемы работы с большими объемами реляционно слабосвязанных данных в высоконагруженных веб-проектах

Очень невнятное название, не шибко внятное содержимое. Типа у нас тут реляционная база и большая нагрузка — давайте выкинем нормальную форму нафиг, но при этом, вместо использования стандартных механизмов хранения часто требуемых данных во всяких NoSQL-кешах, завести опять таки в реляционной БД, специально денормализованные таблицы.

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

Насколько я понял, это ребята из команды пытавшейся оптимизировать наследие Фицпатрика, что им так и не удалось[1], и в результате все они покинули проект.


Масштабирование системы баннерной рекламы с централизованной базой данных

Несколько топорная (без гениальности, изящества, и т.п.) реализация баннероторговли и баннеропубликации на Oracle.

Зачем там Oracle — совершенно непонятно, скорее всего унаследованный код финансовых модулей на PL/SQL, которых лень переписывать, вокруг чего начали воротить все остальное. Ибо надежность там не нужна, транзакционность и немедленность реакции — тоже (грузят апельсины бочками данные SQLLoaderом), вообще как-то все ---. Похоже еще есть момент экономии на лицензиях (другой логики для централизованности СУБД я не вижу).

Бизнес примитивный и надеюсь скоро вымрет, когда баннерорезки будут у всех, кроме полных даунов (и накручивающих трафик роботов), а реклама станет контекстной и уйдет в поисковики.

Из интересного — ребята смогли выйти и работают на японском рынке. Я то думал, что японский национализм абсолютен, и гайдзинов брать в разработчики не будут, тем более когда полно своих боевых программистов.

День второй

Sphinx в примерах и задачах

Мне ужасно стыдно, но я проспал и пришел только к концу. Хотя тема явно интересная, уже есть два эффективных бесплатных и опен-сорс движка полнотекстового поиска — Sphinx и встроенный поиск PostgreSQL (Lucene таки тормозной). Очень интересно кто-кого, и даст ли «синергию» конкуренция и перекрестное опыление.

Например в некоторых наших внутренних MySQL-системах я уже подключил Sphinx для поиска, в некоторых — думаю подождать и сразу перейти на PostgreSQL, и делать полнотекстовый поиск с морфологией напрямую в БД.

На PostgresQL не перешли, но в трекере теперь используем полнотекстовый поиск MySQL (с морфологией), в принципе, тоже неплохо.

Организация асинхронной обработки задач

Частично опоздал, но в целом доклад не оправдал моих ожиданий. Судя по названию можно было бы ждать опыта использования специализированных продуктов — от вендоров, типа Oracle Advanced Queuing (в тезисах говорилось про оракл), IBM WebSphere MQ,…, а может даже и опен-сорс. Увы, рассказали о простом самодельном решении на оракле (очереди на дорогой и жирной РСУБД). Как-то невозбуждающе.

Практическое использование Hadoop в системе интернет-статистики

Разумное и модное решение задачи параллельной обработки и агрегации логов посещения сайтов. Используется фреймворк Hadoop (параллельные вычисления в парадигме map/reduce), который для таких задач вроде как идеально предназначен, и в общем-то единственно доступный (опен-сорс), ибо гугловый аналог закрыт, а больше вроде ничего нет.

Кластер относительно небольшой (12 восьмиядерников с 8Gb памяти), но справляется. Два прохода:

  • Схлопывание текстовых многополевых атрибутов в idы (индексирование).
  • Обработка (агрегация разного рода) полученных индекс-файлов, получение отчетов.

Ну и всякие там хитрости, вроде все разумно. Опять таки, убьют наверно баннерорезки и этот бизнес.

CAS — сервер приложений C++

Как-то не. Ждал «сервер приложений на C++». Оказалось, «не сервер», «не приложений», «не C++». То есть ребята написали очередной шаблонизатор, для вызова из скриптовых языков. Вроде как быстрый (судя по картинке-гистограмме с неподписанными осями и без единой цифры), но как-то не то, что ожидалось.

Насколько я понял, им он позарез нужен, чтобы спасать от высоких нагрузок написанное на перле поделие Бреда Фицпатрика, что же, посмотрим[2].

Но я в общем, не в теме, шаблонизаторы меня если интересуют, то не с точки зрения максимальной производительности, а с точки зрения максимальной гибкости и удобства для разработки и модификации. Т.е. я готов например, согласится, что XML/XSLT, и Template Toolkit — не ОК, но не знаю, действительно ли все настролько плохо, что нужно изобретать свой велосипед.


Виртуализация в среде highload servers

Вроде по содержанию маркетинговый доклад, подвигающий фишку виртуализации от SWSoft — вместо выполнения виртуальных машин целиком (VMWare, Hyper-V, Virtual PC, VirtualBox, …), на хост машине размещается одно ядро операционной системы, а виртуализуется все остальное — файловая система и все что на ней.

Для маркетингового доклада выглядел как-то вяло, но оказалось, что докладывал не маркетолог, а инженер техподдержки (для него это нормально).

Выгоды сферической виртуализации в вакууме понятны, угрозы тоже (взлом виртуальной машины высоковероятно приводет к взлому машины хостера, и конец всей сотне виртуальных машин). См. например An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments. Да и без всяких взломов, как выяснилось, трудно рулить физическими ресурсами — например можно ограничить виртуальную память каждой машине, но живую память квотировать нельзя — соответственно одна «оборзевшая» виртуальная машина может поставить «раком» остальных.

Сравнений с конкурентами тоже не было. Но тема интересная.

Application Streaming

Жесткий маркетинговый («парилово») доклад от ENDEAVORS (доклада кстати, не было в программе — вероятно это такой вот метод инкорпорирования «джинсы» в конференцию). Презентация с гламуром и анимацией, причем разработанная видимо зарубежом — ни слова по-русски (даже не локализовали).

Суть — очередные модели SaaS, не только как вебприложений, но как скачиваемых в специальную среду rich-приложений, работающих ограниченное время (за плату). Почему-то утверждалось, что CRM-системы на вебинтерфейсе невозможны (вроде как неправда).

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

Надеюсь в светлом будущем не придется арендовать фильмы в виде защищенного этой технологией одноразового приложения, а все эти технологии благополучно сдохнут. Пусть разве что останутся честные SaaSовсцы, предоставляющие (пусть за деньги) приложения на своем хостинге.

Архитектура Photofile.ru

История эволюции архитектуры фотохостинга, от совсем любительской (на одном сервере), до более-менее масштабируемой. В деталях, как появлялись разные узкие горла, и какими эвристиками с ними боролись — как включали второй сервер, как перетаскивали файлы, оставляя на их месте симлинки, как делали шардинг через Dynamic DNS и т.п.

Алсо, ругали Cache Smarty.

В общем, с появлением таких монстропроектов, как «я.фотки», «netprint.ru», с огромным машинным и человеческим ресурсом, с изначально масштабируемой архитектурой, фотофайлу наверно высокие нагрузки более не угрожают.

Архитектура и реализация сервиса печати фотографий netprint.ru

Крутые парни. Большой промышленный проект — практически уже монополия на фотопечать (почти все фотохостинги печатающие фотки, печатают через них). Типичный пример, как централизованный онлайн-сервис убил все кустарные лаборатории.

Архитектура — Java, вроде как разваленная на вебсервисы (JMS), плюс PHP+XCACHE+LightHttpd для вебморды. Кстати, опять таки PostgreQL.

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

  • вместо удаления — пометка об удалении, удаляет специальный демон потом;
  • перекодировка изображений — написали сами оптимизированный под Intel код, вроде как порвал ImageMagick в десятки раз.

Ребята не ведутся на марки, тренды и авторитетов:

  • бэкап делают на ленты, ибо посчитали, что чуть дешевле (для новых систем вроде как ленты лет уж пять как похоронили общемировым консенсусом).
  • опять таки самописная обработка изображений,
  • RAID — sucks.
  • тренировки по восстановлению в формате «внезапная пожарная тревога» (может шутили?),
  • изучение поведения системы под нагрузкой в дни естественных пиков (пост-праздники, НГ).

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

Решение проблем высоких нагрузок на примере проекта Яндекс.Фотки

Сервис очень хороший, и докладчики наверно хорошие (редкий зверь — два докладчика, практически «парный конферанс»), но доклад вызвал раздражение и аллергию.

Презентация намеренно сделана «банально-попсовой», символы архитектуры заменены всякой порнографией (типа женский бюст — Cisco, банан с двумя апельсинами — сами додумайте и т.п.). Плюс дурацкие фото, как эмоциональная иллюстрация идей. Что-то похожее я видел на презентациях с конференции автоматизаторов торговых сетей — тупые и тривиальные тезисы слайдов засыпаны содержимым с fishki.net чуть более чем полностью.

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

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

Доставка контента пользователям

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

Средняя температура по больнице — 4 минуты на ролик, 250Кб/сек — доставка. Отметил, что пользуются WebDAVом для трансляции операций по загрузке и редактированию и не жалуются.

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

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

Примечания и ссылки

  1. ↑ Насколько я общался, скорее по политическим причинам
  2. ↑ Хотя с ЖЖ я уже ушел, ибо имхо, под управлением российских менеджеров путь один, и он в никуда — нас ждет классический набор «е*ый стыд» + «просрали все полимеры»

Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.

Источник — «http://lib.custis.ru/index.php?title=РИТ:Высокие_нагрузки-2008_(Отчет_Стаса_Фомина)&oldid=24666»