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

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

Материал из CustisWiki

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

Народу было много, спать хотелось, кажется, сильно, а от Стасовых таблеточек я отказался, так что хайлоад частично прошёл мимо и описаний будет мало. :-)

McHost пиарился, привёз голых девок. Ещё только сейчас понял, что большинство презентаций были какие-то уж больно фиговые. 5-6 слайдов на полчаса времени?…

Я рассказывал блиц-доклад PHP-разгон: серебряная пуля из автомата Комменца-Вальтера» (Commentz-Walter). Есть корпоративный отчётик с презентацией и видео.

MySQL Performance Tuning — Morgan Tocker (Percona)

Доклад про оптимизацию MySQL в несколько «обратном» стиле — началось всё с апгрейда железа — интересный метод оптимизации, дааа. Последовательность рассказа была такая:

  1. Апгрейд железа. Ну вроде всем понятно, но чуть-чуть разжевал: вы конечно попробуйте… но всё равно надо сначала мозгом подумать — а то окажется, что узкое место — диски, и что? Процессор проапгрейдите, а диски-то никуда не денутся. Это из серии «плоско лежащей базы — ни о чём». (c)
  2. Оптимизация конфига. Может помочь, если изначально в нём были серьёзные ошибки или несоответствия реальной ситуации. Конечно же упомянул mysql-tuning-primer — он процесс проверки SHOW STATUS автоматизирует.
  3. Добавление индексов. «Самый прикольный путь». Ну тут вроде всё ясно. Привел пару примеров.

Увы, не упоминалось про использование различных Storage Engine, особенно «нетривиальных» или стандартных, но новых. А их есть — кроме стандартных MyISAM и InnoDB, есть ещё как минимум Maria (модифицированный MyISAM), Falcon (MySQL6) (улучшенный MVCC), PBXT (вроде InnoDB, но чуть быстрее), кластерная NDB.

Quick Wins with Third Party Patches — Morgan Tocker (Percona)

Тот же товарисч продолжил беседу и рассказал о том, что вообще-то MySQL — это какбэ опенсорц, и поэтому не все позитивные изменения делаются самими MySQL’ями — различные компании и личности, типа Google, этой самой Percona и ещё некоторых, выпускают свои патчи, и среди них есть весьма интересные. Упомянул несколько патчей-фиксов производительности, статистику по возможным индексам и ещё что-то (см. презентацию). Так, полезно. Знать, что оно есть и может быть полезно.

История развития uCoz: от самосборного сервера до 4-х стоек — Евгений Курт (uCoz)

Доклад про быдлохостингконструктор сайтов ucoz.ru. Докладчик тему знал плохо, говорил только что мы мол были всегда бедные, доходов было мало, а желающих было много, сказал, что сейчас сидят на платформе, кажется, Supermicro… Сказал, что в какие-то моменты закрывали регистрацию, ну мол и что. Говорил, что аудитория у юкоза так себе, нормальных сайтов чуть-чуть, они там в топе перманентно*. Его спросили, а вы планируете как-то улучшать эту аудиторию? Внятного ответа тоже не было…

* На самом деле то, что хорошие сайты в топе, это ещё не так плохо: общался я с саппортами Агавистого Холма, там постоянно нужно было банить всякий варез и прочую порнуху, и саппорты говорили так: можно прийти на работу, глянуть в топ, и первые 10 сайтов сразу забанить. И ошибка будет минимальна.

Современное профилирование и оптимизация Perl (State of the Art Perl Profiling with Devel::NYTProf) — Tim Bunce

Замечательный доклад от замечательного докладчика и великого перлиста — Тима Бунса, автора многих очень популярных Perl-модулей.

Сначала профилирование — рассказ про Devel::NYTProf. Начинается доклад с демонстрации того, что «стандартный» Devel::DProf — «реально отстой» и работает откровенно некорректно =) пример очень простой — генерируется и вызывается последовательно 1000 одинаковых функций. В итоге — в топе где-то 5 из них, а остальные почему-то не занимают времени вообще (по мнению ДиПрофа). Посему нужен и написан Devel::NYTProf (до него был ещё Devel::FastProf) — действительно, кстати, очень хороший и удобный Perl-профилировщик (у нас я им, к примеру, Bugzillу 3 мучал). Умеет очень многое (о чём и сказал Тим) — что мерять? Реальное или процессорное время, затраты по функциям или по строкам? Так вот Devel::NYTProf умеет и то, и другое, и многое другое.

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

Вторая часть — как делать оптимизацию. Идеи применимы не только к Перлу, а к любым программам вообще. «Перед оптимизацией… Во-первых…… НЕ ДЕЛАЙТЕ ЕЁ!». Вообще-то это мысль Michael A. Jackson'а — «The First Rule of Program Optimization: Don’t do it. The Second Rule of Program Optimization (for experts only!) — Don’t do it yet». Мысль, очевидно, правильная, и заключается в том, чтобы, во-первых, не начать оптимизировать раньше времени, а во-вторых, не тратить силы на оптимизацию тех 97 % кода, которые выполняются 3 % времени.

Краткий план оптимизации:

Посмотрите на программу профилировщиком под «похожей на боевую» нагрузкой. Посмотрите на эксклюзивное время выполнения функций. Оно в порядке? Если нет — исправьте 1-2 наибольших ужаса. Посмотрите снова. Нормально? Вот и хватит.

Не очень? Поехали дальше с простыми фиксами: извлекайте инварианты из циклов, выходите из циклов как можно раньше, избегайте accessor’ов, а если не получается, используйте всякие Class::Accessor::Fast, Faster, XSAccessor и т.п, убирайте лишний код, не shift’ите лишний раз параметры часто вызываемых функций.

Снова не очень? Поехали дальше с известной нагрузкой (1000 одинаковых запросов): проверьте включительные времена выполнения и количества вызовов функций. Похоже на правду? Если нет, можно пофиксить, например, что-нибудь закэшировать.

Всё равно не очень? Тогда придётся перейти к структурным изменениям: перетаскивать циклы внутрь методов, менять структуры данных (массивы vs хеши), оптимизировать алгоритмы, если не помогает — переписать что-нибудь на C.

В целом — всё.

Мониторинг производительности Perl в высоконагруженной среде (Monitoring Perl Performance in High Load Environments) — Tim Bunce

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

Улучшения производительности в PostgreSQL 8.4 (Performance Enhancements in PostgreSQL 8.4) — Магнус Хагандер (Magnus Hagander), PostgreSQL Europe & Redpill Linpro (Sweden)

Продолжение традиции рассказа Changelog’ов на конференции. Дам ссылку на официальный пресс-релиз, и ладно.

Для чего не нужен memcached? — Илья Космодемьянский

Рассказ о том, что memcached стал так популярен, что его суют везде, где можно и где нельзя, и что делать так на самом деле не надо, что у СУБД есть свой кэш, надо только его правильно настроить, что когда кэшей становится много, их нужно синхронизировать, а это — затраты, и т. п. К MySQL сий перец относится весьма негативно, это вообще говорит местами конечно СУБД, но местами — одна головная боль. Ну так на самом деле мемкэш для того и придуман, чтобы помогать не очень продвинутому Мусклю. Точнее, в первую очередь, конечно, чтобы всякие веб-компоненты кэшировать.

Но мысль разумная: не надо пихать то, что не надо, туда, куда не надо :-)

Как мы делаем лучшую хостинговую платформу — Дмитрий Лоханский (Оверсан-Скалакси)

Интересный доклад про ещё не готовое, но светящее нам в ближайшем будущем Русское Облако наподобие Amazon EC2, только лучше в стопицот раз. Находится оно процессе разработки, представляет из себя много (хотя и не очень много) мощных Xen-машин без дисков, хитрых сисек цисок и juniper'ов, большого сетевого хранилища. Детали уже, увы, не помню. Помню, что пока что там нельзя вылезти за пределы одной машины — т.е потребовать процессора и памяти больше, чем есть на одной машине. Но там это довольно много (128 Гб и кажется 4 2хядерных Xeon’а), и кроме того, в ближайшем будущем они это пофиксят.

DDOS: Практическое руководство к выживанию — Александр Лямин (Инициативная группа при МГУ)

О. Пой гармонь, пляшите ноги да трезвонь набат! В МГУ DDOS ребята изучают, блджад. На халявных каналах и мощностях, и ничего не просят взамен — если у вас DDOS, приходите, мы вас разместим и спасём, и поучимся заодно. Делают они это месяца уже 3, отбили N атак, одна из них даже была на 7 Гбит канала, а теперь пиарятся-отчитываются. Правильно, купили ведь суперкомпьютер, отъели пол-парковки около южного входа 2-го гума под систему охлаждения, фигли простаивает?

Тезисы: DDOS экономически эффективен — стоит дёшево, а бизнес кладёт быстро и здорово. Чаще всего это тупой HTTP-флуд на какую-нибудь последнюю страницу тупого поиска. Дальше забивается сетевой стек системы, потом сетевая инфраструктура провайдера (это, кстати, проблемы провайдера!), потом — исчерпание канала. Отсебятина: от которого, кстати, иногда спасаются изменением DNS-записей на 127.0.0.1 (так делал, например, Баш). Другой вид атаки: бывает, коннектятся на 80-ый порт и молчат в трубку. Ещё бывает SYN Flood — это когда делают вид, что устанавливают TCP-соединение, а на самом деле виснут посередине (говорят SYN, сервер говорит SYN-ACK и ждёт ACK, которого уже не будет). Чаще всё это — транснациональные и зарубежные ботнеты, но бывают и дорогие, исконно русские, которые тупым отключением зарубежного трафика не отобьёшь. Бывают и мегаумные, которые запускают браузер и кликают мышкой по ссылкам, их отфильтровать тяжелее всего и нужно применять алгоритмы анализа поведения пользователя. Но таких они, кажется, не встречали — или почти не встречали.

Меры: в первую очередь в любом случае нужно отключить HTTP-сервер из автозагрузки, а потом уже делать всё остальное, а то может оказаться, что сервер перезагрузится и все усилия по его «оживлению» надо будет делать заново, так как система опять заткнётся. Дальше надо минимизировать все возможные размеры буферов, времена ожидания клиентов (диалапщиков в сад), ограничить нагрузку на скриптовый бэкенд, что-нибудь отфильтровать по урлам (только не трогать своих ajax’ов и полезных ботов), отфильтровать ботов и забить их в ipset (он быстрый), против SYN Flood’а применять SYN Cookies.

А если ничего не помогает — идти к ним и спасаться.

Кстати, где-то я как-то видел доклад какого-то студента, работающего в Яндексе (чуть ли не у нас на ВМК), который рассказывал об алгоритмах распознавания ботов по поведению. Правда, насколько я помню, для методов, описанных там, в случае DDOS’а нужно довольно сильное железо (читай — тяжеловаты). Но вроде как, в Яндексе они даже внедрены.

Ещё отсебятина: есть ещё такая мера, не помню, откуда придумал — перенаправление клиентов refresh’ем на нестандартный порт. Большинство ботов это не выловят.

Репликация: База Знаний «Заказных Информ Систем» → «Highload 2009: Отчёт Виталия Филиппова»

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

Источник — «http://lib.custis.ru/index.php?title=Highload_2009:_Отчёт_Виталия_Филиппова&oldid=42756»