Высокие нагрузки в поисковиках

Слава Шевцов
На сайте с 23.07.2005
Offline
370
1215

Есть интересный доклад о нагрузках и архитектуре Яндекс.Поиска Предлагаю обсудить.

Оглавление:

Что такое поиск и на чем все это работает

Архитектура поиска и взаимодействие серверов

Архитектура поискового кластера

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

Пример проблемы и её решений.

Неизменность точки зрения неизменно порождает иллюзию понимания.
M
На сайте с 29.03.2003
Offline
65
#1
Слава Шевцов:
Есть интересный доклад о нагрузках и архитектуре Яндекс.Поиска Предлагаю обсудить.

Оглавление:

Что такое поиск и на чем все это работает
Архитектура поиска и взаимодействие серверов
Архитектура поискового кластера
Методики анализа производительности кластера
Пример проблемы и её решений.

А чего там нового по сравнению с вариантом на highload ?

Проверь свои запросы: Вершки Рунета (http://www.43n39e.ru/)
K
На сайте с 24.03.2004
Offline
223
#2
Слава Шевцов:

Пример проблемы и её решений.

а там оказывается очень юморные люди работают...

если цисковские L2/L3 свичи не тянут, то доказывать это с помощью tcpdump является оригинальной затеей... к тому же по L2/L3 циска свитчит почти в полный рост, а достижение почти полного роста влечет за собой провалы в транспорте, т.к. шизеет все на уровне патчкордов и стандарта 1000Base-TX... выходом является переход на 10 гигабит, что есть выход, но влечет за собой дополнительные затраты по фрагментации... кстати внутри своей сетки очень замечательно спасают jumbo frames...

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

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

балансировка по кэшам...

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

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

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

мониторим в RRD постоянно...

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

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

Лоадбалансиг..

Двоечка мужики, чистая двоечка... в природе есть ospf, bgp, wccp... и балансить на уровне RR DNS уже совсем не модно, т.к. оно в случаях со слонами непредсказуемое иногда бывает... а балансеры тут ботлнек в чистом виде... поди с гигабитной дыркой наверное... нет, это не наш метод... мы бы внутри смаршрутизировали все на какой-то фейк, а на sfront-ы поставили либо wccp агенты либо ospf/bgp ... причем с последним, если коленка понимает что на ней собирают, можно получить нужное количество отказоустойчивых раздающих дырок... лоад шаринг виз кост екьюал патх.. как-то так... балансит ясен перенц по ксорке между src и dst айпи... экономия денег в чистом виде, т.к. делается все на наших любим свичах с гигабитными дырками и ни разу не в cpu... а если в URL добавить чуток поддоменов, то можно обойтись и без заглядывания в Host: и чо там в get пишут... если пересчитать на брендовые балансеры, то данный рецепт экономит пару сотен тыщ американских денег и во внешний мир смотрят честные гигабиты фронтов...

сейчас точно бабок буду просить...

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

ps. удачи... вот посмотрите, они рано или поздно так и сделают, т.к. лучше пока еще никто не придумал...

проверенная ддос защита (http://ddos-protection.ru) -> http://ddos-protection.ru (http://ddos-protection.ru), бесплатный тест, цена от размера атаки не зависит.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий