VitaliyFilippov в 11:54, 23 июля 2013

2013-07-23T11:54:14Z

Новая страница

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

McHost пиарился, [[:Файл:Стас_Фомин_на_Higload-2009_xx.JPG|привёз голых девок]]. Ещё только сейчас понял, что большинство презентаций были какие-то уж больно фиговые. 5-6 слайдов на полчаса времени?…

Я рассказывал блиц-доклад [[PHP-разгон: серебряная пуля из автомата Комменца-Вальтера» (Commentz-Walter)]]. Есть [http://team.custis.ru/2009/10/highload.html корпоративный отчётик с презентацией] и [http://woland.pl.ua/1167-video-s-highload-2009-blic-doklady/ видео].

== MySQL Performance Tuning — Morgan Tocker (Percona) ==

* http://highload.ru/papers2009/12506.html

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

# '''Апгрейд железа.''' Ну вроде всем понятно, но чуть-чуть разжевал: вы конечно попробуйте… но всё равно надо сначала мозгом подумать — а то окажется, что узкое место — диски, и что? Процессор проапгрейдите, а диски-то никуда не денутся. Это из серии «плоско лежащей базы — ни о чём». (c)
# '''Оптимизация конфига.''' Может помочь, если изначально в нём были серьёзные ошибки или несоответствия реальной ситуации. Конечно же упомянул [http://forge.mysql.com/projects/project.php?id=44 mysql-tuning-primer] — он процесс проверки SHOW STATUS автоматизирует.
# '''Добавление индексов.''' «Самый прикольный путь». Ну тут вроде всё ясно. Привел пару примеров.

Увы, не упоминалось про использование различных Storage Engine, особенно «нетривиальных» или стандартных, но новых. А их есть — кроме стандартных MyISAM и InnoDB, есть ещё как минимум [http://askmonty.org/wiki/index.php/MariaDB Maria] (модифицированный MyISAM), [http://dev.mysql.com/downloads/mysql/6.0.html Falcon (MySQL6)] (улучшенный [[wikipedia:Multiversion concurrency control|MVCC]]), [http://www.primebase.org/ PBXT] (вроде InnoDB, но чуть быстрее), [http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-overview.html кластерная NDB].

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

* http://highload.ru/papers2009/12507.html

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

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

* http://highload.ru/papers2009/12829.html

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

<font color="red">*</font> На самом деле то, что хорошие сайты в топе, это ещё не так плохо: общался я с саппортами Агавистого [http://holm.ru/ Холма], там постоянно нужно было банить всякий варез и прочую порнуху, и саппорты говорили так: можно прийти на работу, глянуть в топ, и первые 10 сайтов сразу забанить. И ошибка будет минимальна.

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

* http://highload.ru/papers2009/12826.html

Замечательный доклад от замечательного докладчика и великого перлиста — [http://blog.timbunce.org/about/ Тима Бунса], [http://search.cpan.org/~timb/ автора] многих очень популярных Perl-модулей.

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

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

Вторая часть — как делать оптимизацию. Идеи применимы не только к Перлу, а к любым программам вообще. «Перед оптимизацией… Во-первых…… НЕ ДЕЛАЙТЕ ЕЁ!». Вообще-то это мысль [[wikipedia:Michael_A._Jackson|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’ов, а если не получается, используйте всякие {{CPAN|Class::Accessor::Fast}}, Faster, XSAccessor и т.п, убирайте лишний код, не shift’ите лишний раз параметры часто вызываемых функций.

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

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

В целом — всё.

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

* http://highload.ru/papers2009/12827.html

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

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

* http://highload.ru/papers2009/12508.html

Продолжение традиции рассказа Changelog’ов на конференции. Дам ссылку на [http://postgresqlrussia.org/articles/view/151 официальный пресс-релиз], и ладно.

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

* http://highload.ru/papers2009/12256.html

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

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

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

* http://highload.ru/papers2009/12226.html

Интересный доклад про ещё не готовое, но светящее нам в ближайшем будущем Русское Облако наподобие [http://aws.amazon.com/ec2/ Amazon EC2], только лучше в стопицот раз. Находится оно процессе разработки, представляет из себя много (хотя и не очень много) мощных [http://xen.org/ Xen]-машин без дисков, хитрых <s>сисек</s> цисок и [[rupedia:Juniper Networks|juniper]]'ов, большого сетевого хранилища. Детали уже, увы, не помню. Помню, что ''пока что'' там нельзя вылезти за пределы одной машины — т.е потребовать процессора и памяти больше, чем есть на одной машине. Но там это довольно много (128 Гб и кажется 4 2хядерных Xeon’а), и кроме того, в ближайшем будущем они это пофиксят.

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

* http://highload.ru/papers2009/12217.html

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

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

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

А если ничего не помогает — [http://hll.msu.ru/ идти к ним] и спасаться.

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

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

[[Категория:Highload++ 2009]]
{{replicate-from-custiswiki-to-lib}}

Highload 2009: Отчёт Виталия Филиппова - История изменений

VitaliyFilippov в 11:54, 23 июля 2013