official

Заводы стоят, одни мордоляпы в стране!


Previous Entry Share Next Entry
winter kaktus

Перспективы ЖЖ

Прочитал недавно пост Главного по ЖЖ на тему глюков сервиса. Я, как директор по разработке, хочу сказать, что ничего хорошего нас не ждет. И вот почему.

Рассмотрим выявленные проблемы:

1) Cбои в оборудовании (случающиеся хоть и крайне редко, но все-таки случающиеся).

Что у нас ломается из оборудования? По моему опыту экслуатации 40-ка сервеной системы полнотекстового поска, в 95% случаев это жесткие диски. В 4% случаев это проблемы с провайдером. В оставшийся процент входит все остальное. Насколько я знаю, у ЖЖ три копии базы данных. Каждая из копий, наверняка хранится на RAID массивах, для которых выход из строя части дисков не влечет потери данных и выхода копии из эксплуатации, а только уменьшает скорость доступа к той части базы, которая хранится на этом массиве. Но уменьшает не драматично. Любая самая левая система мониторинга при этом тут же начинает орать и визжать. Чинится это заменой поломанного винта. Через пару часов вылетевший узел выходит на штатный режим работы. При ЖЖ-ных объемах данных в несколько терабайт, и при троекратном дублировании должно было сломаться как минимум более половины оборудования, чтобы произошел такой сбой. Это просто невероятная ситуация. Из чего там это оборудование собрано, раз все так ломается? А если просто часть дисков вышла из строя, то оказать существенного влияния на работу ЖЖ это не могло. Если это не диски, то тогда виноват провайдер. Но это уже не проблема железа ЖЖ, это проблема голимого хостинга. Но про хостинг в ответе ни слова.

2) Значительный рост нагрузки, в данном случае вызванным вредоносным трафиком;

Для того чтобы завалить систему, рассчитанную на миллионы пользователей, надо сгенерировать вредоносный трафик на 10 миллионов пользователей. Конечно, генерить запросы проще, чем отвечать на них, но для того, что бы завалить уютненькую, у нее должны быть враги, обладающие системой по крайней мере сравнимой с ней самой. Почему, например, от DDOS не падает фэйсбук и вконтактик? Потому что только они сами могут заддосить друг друга. Яндекс может, Гугл, Ютуб. Системы рассчитаные на десятки а то и сотни миллионов одновременно работающих пользователей. У анонимных хакеров не хватит ни денег, ни трафика что бы хоть как-то ощутимо повлиять на их работу. А вот ЖЖ почему-то очень к такому трафику чувствителен. Даже кэш не спасает. Очень это все странно. Правда если накроется канал, то и обычный трафик «положит» ЖЖ. То есть сам ЖЖ будет работать как ни в чем не бывало, только пользователи будут лицезреть старину Фрэнки. Может проверить все-таки провайдера?

3) Неоптимальность некоторых SQL запросов, созданными еще во время основания ЖЖ;

Вот это единственная дельная причина. И очень печальная. Но она говорит нам о том, что в ЖЖ до сих пор никто не занимается оптимизацией движка. Как он был написан более 10 лет назад, так он и остался. И только когда все легло напрочь, разработчики удосужились заглянуть в ядро системы. А именно с этого надо было и начинать. И не сейчас, а несколько лет назад. Увеличение мощности железа тут результатов не даст. Толпа клонированных дистрофиков не выиграет марафон.

4) Перенос серверов, обслуживающих СУБД, на файловую систему ZFS, произведенную c целью улучшения DR составляющей ЖЖ.

Я не знаю что такое «DR составляющая ЖЖ» зато прекрасно знаю как работают базы данных и диски. Так вот по сути, БД — это несколько очень больших файлов. Внутри этих файлов хранятся так называемые «страницы» с данными, по нескольку килобайт. Управлением страницами внутри файла занимается сама база данных, а не операционная система, поэтому какую файловую систему не поставь, существенного толку от этого не будет. Диск-то работает также. Ну максимум там кэш можно включить-отключить, но и сама СУБД прекрасно умеет кэшировать данные с диска. Так что замена файловой системы, это выжимание последней капельки из дохлой кошки, упавшей в ведро с водкой. Никакого ощутимого прироста это не даст.

Но еще печальнее причин выглядят дальнейшие шаги:

1) Мы откатим файловую систему ZFS до предыдущей, в случае, если нам не удастся стабилизировать ее использование совместно с СУБД в момент пиковых нагрузок;

Это замена мыла обратно на шило, как я уже объяснял выше.

2) Мы обновим всю систему выдачи ошибок с целью их более детального отображения, включая сообщения о том, что некоторые пользователи не могут получить доступ к ЖЖ ввиду попадания их сетей в список блокируемых;

Как это поможет увеличению стабильности работы? Пользователь вместо Фрэнка увидит, что теперь он в заблокированной сети? Это совершенно бесполезное знание. Сам сервис как лежал так и будет лежать дальше.

3) Мы уже обновили систему мониторинга, сделав ее более глобальной, в плане возможности определения потенциальных проблем с доступом не только из США, но Европы и России;

То есть теперь, если проблема возникнет, пост о ней будет написан быстрее, так надо понимать? Как это увеличит надежность и производительность сервиса?

4) Мы уже изменили свои процедуры эскалации проблем с доступом и доступностью, что позволит нам в будущем решать их значительно быстрее, нежели раньше.

Теперь freedom не сможет спокойно бухать с собаками, у него теперь душа будет болеть за ЖЖ во время сбоев. Это тоже, видимо, существенно увеличивает работоспосбность трех копий базы данных.

5) В связи с частичной недоступностью ЖЖ в течении новогодних каникул, действие всех платных аккаунтов будет продлено на 1 месяц в ближайшее время.

Это, конечно, приятно, но от этого уютненькая надежнее не станет.

Итого получается, что не будет предпринято ни одного реального шага по исправлению ситуации. Все меры будут направлены на то, чтобы руководство ЖЖ узнало о сбое не на четвертый день, а скажем, на второй. Это расстраивает.

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

1) Проверить, что там с каналом от провайдера. Возможно он вовсе не такой широкий, каким кажется. У меня бывали случаи, когда со стороны провайдера бьют себя в грудь и мамой клянутся о 50-ти мегабитах, а тесты показывают 256 килобит. Даже если канал держит нагрузку, возможно его нужно расширить. Тогда ддосеры разобьются об кэш.

2) Увеличить количество серверов, работающих на получение и выдачу контента. Это поможет бороться с DDOs-ом и увеличит производительность ленты, как мне кажется, одного из самых ресурсоемких запросов ЖЖ. Опять таки, при наличии нормального кэша.

3) Провести тотальную ревизию движка. Выделить самого умного кодера, фаната бинарных деревьев, хэшей и алгоритмов слияния, которому по ночам снятся оптимальные планы SQL-запросов. Пусть он там все перешерстит. Может индексов где не хватает, а где наоборот, 10 лишних и не используемых, которые тормозят запись в базу и занимают место. В некоторых случаях тюнинг запросов может давать стократный прирос производительности. Конечно, скорость работы всей системы от этого в сто раз не вырастет, но прирост может быть весьма ощутимым.

4) Выполнить партиционирование таблиц с записями по дате, а таблиц с каментами по Id записи. Свежак хранить на SSD рэйдах, старье заливать на HDD. Проводить перепартиционирование раз в месяц. (Правда я не в курсе, насколько у mysql с этим хорошо, я давно не работал с этой базой). Это позволит львиную часть запросов осуществлять по гораздо меньшему объему данных. Что существенно увеличит производительность БД.

5) Ограничить максимальную глубину дерева каментов и ввести для них иерархический ключ. Тогда дерево коментов будет получатся одним запросом, вместо дерева нисходящих запросов. Плюс в страницах БД комментарии будут лежать рядом, что существенно уменьшит количество I/O reads. Сейчас, как я понимаю, каменты привязаны только к родителю. Поэтому вместо одного запроса приходится делать столько запросов, сколько всего потомков вниз по всем уровням от раскрываемого камента. Кроме того, при такой организации таблицы, комментарии одного дерева хранятся в разных местах на диске, потому что сортируются в по ключу Id, который зависит от времени создания комментария. Если же сделать иерархический ключ, то комментарии одной ветки будут хранится рядом друг с другом, что потребует существенно меньшего количества обращений к диску. Ведь жесткий диск, при случайном доступе к данным — самое тормозное по место системы. Скажем SATA диск на 7200 оборотов позволяет сделать не более 120 считываний из разных места диска в секунду. Не очень, скажем, совместимая с миллионами пользователей производительность.

6) Если осуществить пункты 4 и 5 на mysql невозможно, то имеет смысл поговорить с ребятами из Oracle или Microsoft, с целью перевода ЖЖ на любую из их баз. Да, там космические суммы за лицензии, особенно у Оракла. Но я думаю, с учетом популярности ЖЖ, общий язык можно будет найти.

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


Если в руководстве ЖЖ и так все прекрасно знают, то нельзя ли опубликовать хотя бы премерный перечень дальнейших шагов, направленных не на улучшение оповещений об ошибках, а на улучшение именно производительности системы? Было бы очень интересно.

Buy for 100 tokens
Buy promo for minimal price.

tipaa_etaa January 12th, 2013
нихуя не понял, но поддерживаю

vmenshov January 12th, 2013
Если кратко, то у древнего автомобиля красят руль, и приставляют бибикалку, а надо в движке копаться и подвеску менять.

ivan_vertin January 12th, 2013
Боюсь, если раньше "руки не дошли", то уже и не дойдут.
Недавно размышлял об альтернативной площадке для блога и ни одного оптимального варианта не нашел, поэтому, хотелось бы, чтобы жж жил и развивался.

Кстати, Вконтакте есть группа, где можно делать предложения по интерфейсу и прочему, есть ли что-то подобное в жж?

vmenshov January 12th, 2013
Да, в ЖЖ можно слать замечания и предложения. Но толку-то от этого? Интерфейс в большинстве случаев не влияет на производительность, так как он выполняется на клиенте. То есть нагружает твою машину, а не сервер. Конечно, это не всегда так, но в нашем случае, какой интерфейс не нарисуй, ядро от этого быстрее работать не будет.

(Deleted comment)
zorins January 12th, 2013
Тебе почему-то больше верю, чем Илье.
Хотя лечить по телефону - дело странное

vmenshov January 12th, 2013
Странное дело, согласен. Но может он хоть пост прочтет, и что-нибудь обнадеживающее напишет. Как оно там на самом деле. Потому что текущее изложение дел выглядит удручающе. Ни одного действия, направленного на исправление ситуации я в отчете не вижу.

(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
dar_win January 12th, 2013
Многабукв

vmenshov January 12th, 2013
Зато по делу.

skatovets January 12th, 2013
Это что значит, им лень на митинский рынок съездить?

vmenshov January 12th, 2013
Нет не значит. Провайдеров на митинском рынке не продают, и переписанные движки ЖЖ тоже :) Это значит что проблема скорее всего не в оборудовании.

timon_timonich January 12th, 2013
Ох как же я с тобой согласен, сам просто в принципе в курсе этой темы. Пару раз порывался отписаться в постах людея отмазывающих тормоза, но решил что меня закидают ссаными тряпками, особенно насчет момента что нельзя взять и все переписать с нуля, думаю не только можно но и нужно, при все уважении к ЖЖ, но думаю при желании с группой толковых разрабов, написать новый ЖЖ с нуля можно ну за полгода максимум.

з.ы. Ну пинайте меня :))

vmenshov January 12th, 2013
Я ждал тебя :)

На счет переписать с нуля за полгода спорный вопрос. Если взять только базу, возможность постить, френдить, каментить, читать ленту и рейтинг просматривать, то да, можно. Но в ЖЖ дохрена фич и приблуд. Всплывающие подсказки для пользователей, ПО для ботов. Скины и оформления журналов чего стоят. Open Id, техподдержка, жетоны, промо и куча всякой второстепенной байды. Поскольку почти вся она - интерфейсная, то отнимет в разы больше времени чем кусок ядра, отвечающий за это. По моему опыту станица с интерфейсом функции ядра пишется от 5-ти до 10-ти раз дольше чем сама функция ядра.

То есть если мы берем сферический ЖЖ в вакууме, то он за полгода пишется. А вот рюши это еще года на два минимум.

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

(Deleted comment)
kamlena January 12th, 2013
Дронов писал в комментах, что он не является профессиональным программистом и где-то мог сработать как испорченный телефон.
А вот Ибигдан - программист. Вот что он написал: http://ibigdan.livejournal.com/12232929.html

vmenshov January 12th, 2013
Ну, в общем все то же самое, что и я думаю. Да и любой более менеее разработчик думает так же. Меня смущает что в постах Ильи практически ничего нет про изменение архитектуры ЖЖ. А только это может исправить ситуацию. Ибигдан про изменение архитектуры пишет, но насколько он сам в теме?

ljpromo January 12th, 2013
прочел до конца:)

vmenshov January 12th, 2013
Ну ты герой :) Что-нибудь понял?

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

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

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

одно ясно что они скорее всего не знали что есть проблема, а если и знали то не смогли организовать бригаду по ремонту. после первых пьянок кое как подняли, а вот когда уже 9 все вышли на работу, то быстренько привели базу в порядок.

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

в конце 11 месяца установили счётчики Comscore на страницы LiveJournal для более подробной, оперативной и точной аналитики. (Обновление ЖЖ (#99)) - а в 12 месяце жж уже туговато крутился. Ну а то что аудит - зло, можно и не говорить.

vmenshov January 12th, 2013
Кстати хорошая мысль на счет закончившегося места. Эта проблема на некоторых файловых системах так просто не решается, поэтому могла реально вызвать такие задержки в востановлении работы. Хотя на ZFS, как раз, должна решаться легко. Но фиг знает, у меня особого опыта работы с ней нету.

На счет производительности в БД в зависимости от файловой системы, я думаю влияние там несущественно. Ну максимум +- 25%. И то вряд ли. Лысый, с нуля отформатированный диск с индексами без фрагментации даст куда больший прирост.

budan January 12th, 2013
Ви таки подгиваете все устои гусского инфогмационного бизнеса в Госии! Немедленно сдайте обгатно планы по фотографигованию пауков и сегьёзно ответьте на вопгос - сколько ещё жж протянет при "ничегонеделании"?

vmenshov January 12th, 2013
Тут надо оценить рост аудитории. Если она не будет расти, то все будет так же, с глюками и провисаниями, но сколь угодно долго. Если аудитория удвоится, то ЖЖ может не протянуть и дня.

kam4adal January 12th, 2013
Я понял главное - при желании ЖЖ можно починить, и будет все по человечески.
Последние дни вроде нормально все работает, надежда есть ;)

titlingur January 16th, 2013
А я так понял, что его надо не чинить, а переделывать полностью. В принципе, в других сферах это всегда рациональнее. Проблема вот в чем, на мой взгляд. Я ничего не понимаю в этой теме, но мне абсолютно понятен уровень людей, которые ею ответственно занимаются. Как раз недавно писал об этом
http://titlingur.livejournal.com/138918.html
И если я прав, то ЖЖ точно ничего не светит

sneawo January 12th, 2013
DR это судя по всему какой-то disaster recovery и гугл про mysql zfs ссылки дает, так что какой-то смысл в этом наверно есть, но в целом с тобой согласен

vmenshov January 12th, 2013
Я почитал подробнее про ZFS. Вся фишка там, как я понял, в навороченном дисковом кэше. Правда, чем кэш базы данных больше, тем преимущество ZFS жиже. Так что я думаю на серваках со 128 гигами оперативки вряди что она даст. И уж точно увеличения производительности в разы не будет.

Кстати и Oracle и MS Sql Server сами имеют достаточно крутую систему кэширования, минуя кэш операционки. И доступ осуществляют напрямую, через Direct I/O.

prosto_vova January 12th, 2013
Надо корнерезом пройти, а потом переложить. Ну это я про канализацию, по вашему один хуй не понимаю.

vmenshov January 12th, 2013
Да, есть такая беда с разработкой. Попробуй объясни нормальным языком, что имелось в виду.

ara_bublik January 13th, 2013
круто написали...
может прислушаются.....

moltshun January 16th, 2013
папа, а с кем ты сейчас говорил?

vgil January 16th, 2013
отказался от платного аккаунта...
не вижу смысла...
большинство моих френдов перешло на свой домен
в ЖЖ лишь кросспосты.
твиттер дает большую аудиторию

greatgonchar January 16th, 2013
Такому кодеру надо будет столько заплатить, что на жетоновые гранты блогерам не хватит!
Если серьезно, то мне кажется, что вся проблема в излишней коммерциализации уютненькой. Промо блоки в каждом втором журнале, стимуляция попадания в топ до добра не доводит, а лишь стимулирует создание ботов, репост-аккаунтов и повышенную активность на новых сервисах, стоящих на старой базе. Если все работало, а теперь не работает, то значит проблема в нововведениях, а не столько в старом движке.
Кроме того, надо понимать, что при быстром росте "тылы не поспевают". Идеи раздуть ЖЖ до уровня цукербука напоминают поход Наполеона на Москву. Ну раздуете, а сладить сможете?

ge_rus001 January 16th, 2013
Латанием дыр ЖЖ не поможешь, понял я из прочитанного )))

rwsmart January 16th, 2013
заметил, что фоновое автообновление френдленты отключилось.

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

vmenshov January 16th, 2013
Это не удивительно. Обновление ленты, на мой взгляд, один из самых тяжелых для ЖЖ запросов. Если есть проблемы с производительностью, то тут не до автообновлений.

livejournal January 16th, 2013
Здравствуйте!
Ваша запись попала в топ-25 популярных записей LiveJournal. Подробнее о рейтинге читайте в Справке.

vmenshov January 16th, 2013
Вот спасибо тебе, дорогой друг!

rockerface January 16th, 2013
несмотря на специфику, изложено доступно. странно, что такая огромная и мощная организация до сих пор болеет какимито детскими болезнями

vmenshov January 16th, 2013
На счет доступности у меня большие сомнения, на самом деле. Но конкретные советы человеческим языком описать трудно. Да, я думаю, и ни к чему это. Они же для спецов.

nomadmoon January 16th, 2013
> то имеет смысл поговорить с ребятами из Oracle или Microsoft, с целью перевода ЖЖ на любую из их баз.

А PostgreSQL мы типа вообще рассматривать не будем.

vmenshov January 16th, 2013
У меня нет боевого опыта работы с постгрессом. Как-то он меня миновал. Если в нем есть партиционированние таблиц, то сгодится и постгресс.

first_quarter January 16th, 2013
по делу, хоть и не кратко

vmenshov January 16th, 2013
Да, букв много, но короче не получилось.

(Deleted comment)
dualstandard January 16th, 2013
ОМГ ))))

nicplay59 January 16th, 2013
,, Папа, а тигр скушает 1 кг мяса? Конечно сынок. А два? И два скушает. А пять сможет? Конечно сможет, вот только кто ему столько даст.,,
Нужны деньги, а дать их жалко.

?

Log in

No account? Create an account