The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Оптимизация алгоритма btree позволила увеличить производительность http-акселератора Varnish

15.06.2010 13:52

Poul-Henning Kamp, принимающий участие в разработке FreeBSD, опубликовал статью в которой рассмотрел проблемы в работе классического алгоритма btree. При разработке высокопроизводительного http-акселератора Varnish было замечено, что при работе с древовидными структурами не учитывается состояние виртуальной памяти, что при высокой нагрузке на VM приводит к провалам в производительности (возникновение паразитных задержек из-за VM page fault). Предложенная в проекте Varnish реализация бинарных деревьев B-heap продемонстрировала увеличение пиковой производительности до 10 раз.

Http-акселератор Varnish используется в таких проектах, как Facebook, Wikia и Slashdot. Работа Varnish базируется на задействовании современных методов мультиплексирования соединений, таких как epoll и kqueue, а также системных вызовов sendfile и madvise. Для формирования конфигурации используется специальный язык VCL, который затем компилируется в исполняемый бинарный код. В конфигурации допускается также использование вставок на языке Си. Присутствуют механизмы балансировки нагрузки, учета состояния и времени реакции бэкенд-серверов. Интересной возможностью Varnish также является способность собирать итоговые страницы по частям на стороне фронтэнда, определяя логику сборки на языке ESI (Edge Side Includes). Для упрощение управления кластером из множества Varnish-серверов подготовлен специальный web-интерфейс, позволяющий не только выполнять функции мониторинга, но и вносить изменения в конфигурацию.

  1. Главная ссылка к новости (http://queue.acm.org/detail.cf...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/26969-Varnish
Ключевые слова: Varnish, btree, optimization, memory, vm, speed
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (28) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, anonimus (?), 14:54, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > увеличение пиковой производительности до 10 раз.

    лихо!

     
  • 1.2, User294 (ok), 15:08, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    ИМХО, если волнует производительность, попросту нефиг на виртуальную память рассчитывать вообще. При современных объемах оперативки - чувак явно опоздал с исследованиями лет на 10. Вот лет 10 назад ему бы за такое исследование памятник при жизни воздвигли :)
     
     
  • 2.3, Andrey Mitrofanov (?), 15:21, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >ИМХО, если волнует производительность, попросту нефиг на виртуальную память рассчитывать вообще.

    Нынче вся память - виртуальная, это раз. Не факт, что там речь про "своп", это два. Вполне возможно, про "промахи TLB" или что-то подобное -- более "тонкое". См.например, http://lwn.net/Articles/374424/?format=printable

     
     
  • 3.16, User294 (ok), 17:48, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Нынче вся память - виртуальная, это раз.

    Но проседание скорости ее работы начинается только когда объем запрошенной памяти начинает превышать объем физической. Грубо говоря - если нет page faults, нет и проблем от них.

    > Вполне возможно, про "промахи TLB" или что-то подобное -- более "тонкое".

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

     
     
  • 4.20, аноним (?), 18:59, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Для альтернативно одарённых - кроме размеров рамы выросли и объёмы траффика. Прикинь на бумажке сколько рамы нужно чтобы закешить да хоть грёбанный Ю-туб и иди уже в трактористы-мелиораторы, Ыксперт :(
     
     
  • 5.23, User294 (ok), 20:08, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >на бумажке сколько рамы нужно чтобы закешить да хоть грёбанный Ю-туб

    Закешить что именно? Контент? Каталог оного? Или wtf?

    >и иди уже в трактористы-мелиораторы, Ыксперт :(

    А вы, очевидно, в уютную пещерку. И не забудьте свою дубинку :).

     
  • 4.24, аноним (?), 20:30, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > В данном случае насколько я понял упор сугубо на page faults и как с ними жить. Ну да, сперва создадим себе проблем а потом с помпой их разрюхаем...

    Господи, какое феерическое ламерство. Иди почитай что такое page fault, а то так договоришься до "придумали себе kernel panic'ов, а теперь мужественно их чиним".

     
     
  • 5.28, User294 (ok), 21:08, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я в курсе что такое page fault-ы, спасибо. Когда потребовалась страница памяти которой нет в физической оперативке, процессор генерит исключение. И по этому поводу обработчиком оного в операционке страница памяти подгружается откуда-то сбоку (из свопа, как правило на диске, хотя науке известны и более извратные варианты). И что такое memory pressure - представляю себе.

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

     
     
  • 6.36, аноним (?), 20:04, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Но не очень вдупляю зачем все это сделано вот так.

    То есть memory mapped file - одно из немногих _реальных_ технологических улучшений за последние 15 лет ... как то прошли мимо тебя да? :) Ну так я и говорю - Ыксперт!

     
  • 2.4, sluge (ok), 15:26, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну дак ты знаешь сколько чел одновременно ломятся на фэйсбук? тут и терабайта оперативки не напасешься! так что оптимизаторам респект!
     
     
  • 3.9, hostmaster (??), 16:10, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    так там и стоит далеко не один сервер, а собрать кластер из кешей на терабайт не сложно были бы деньги

    информация о том что facebook использует varnish есть только на сайте varnish-а ... к чему бы это

     
  • 2.11, Фкук (?), 16:19, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    При современных объемах оперативки ?

    Вам свободно в 64 ГБ?
    Мне - нет. А больше на мать не воткнуть.

     
     
  • 3.26, Дмитрий (??), 20:34, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Покупайте нормальную материнку...Вон STSS продаёт машинки 2U не c 64, а с 512Гб....вам этого мало ??
     
  • 2.19, аноним (?), 18:55, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    VM != Swap, dude! Ты не заговаривайся, сейчас 99.9% осей c VM.

    И перец пишет: "A 300-GB backing store, memory mapped on a machine with no more than 16 GB of RAM, is quite typical."   Лет 10-15 назад были бы те же цифры но MB, лет через 5-10 опять то же но TB ... суть того что он предлагает это не изменит ни на йоту.

    А ты статью то читал?! А то меня мучают смутные сомнения(С)

    PS: Ну а то что "640 Кб хватит всем" - мы уже слышали, да  :)

     
     
  • 3.27, User294 (ok), 20:58, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А еще 2 2 4 Для капитанов намекаю имелась в виду физическая оператива П... большой текст свёрнут, показать
     
     
  • 4.37, аноним (?), 20:23, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>А ты статью то читал?! А то меня мучают смутные сомнения(С)

    Всё - сомнения меня больше не мучают!
    Ыксперт статью __НЕ__ читал, либо ангельских букв не осилил :)


    >Да, но не совсем понял нафиг чувак сперва придумал себе проблемы ("а
    >давайте начнем свопиться?!") а потом их с помпой решил ("а давайте-ка

    Ну конечно, не всем же везёт жить в Ыдеальном мире Ыкспертов у которых данные _всегда_ влазят в 640KB :)


    >кроме того, если уж товарисч говорит о устаревших компьютерах - вообще,

    Наоборот - он говорит о новых - modern компьютерах. Которые начались с VAX'а :)

    >существует мнение что в будущем компьютеры будут как
    >раз содержать 1-2 типа памяти, возможно даже энергонезависимой. И быстрой. И
    >никаких медленных дисков. Вообще. Глядя на рост размеров оперативы и флеша

    Просто ___шикарнейшее___ подтверждение моих подозрений ! :)

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

    Кроме того имею напокобелимую уверенность - если бы статью написал не один из разработчиков FreeBSD, а кто нить из линуксовых - Ыксперт с таким же неиствовством и пренебрежением здравым смыслом доказывал бы РеволюЧионность и "неимение мировых аналогов" :)

    За сим торжественно присваиваю User294 пожизненный тиул ЫкспертЪ с занесением в грудную клетку :)))) Амба.

     

  • 1.6, avatar (ok), 15:53, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Надо выключать swap тогда такие проблемы возникать не будут.
     
     
  • 2.10, Tav (ok), 16:14, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, и пусть OOM Killer убивает всех несогласных с таким решением.

    Серьезно: если вы хотите, чтобы своп использовался только в крайнем случае, установите соответствующие параметры VM (как минимум, swapinness), но имейте в виду, что в Линуксе оперативная память не простаивает зря, даже когда она не занята пользовательскими процессами, поэтому все время держать данные неактивных процессов в оперативной памяти нерационально.

     
     
  • 3.13, avatar (ok), 16:44, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Ага, и пусть OOM Killer убивает всех несогласных с таким решением.
    >
    >Серьезно: если вы хотите, чтобы своп использовался только в крайнем случае, установите
    >соответствующие параметры VM (как минимум, swapinness), но имейте в виду, что
    >в Линуксе оперативная память не простаивает зря, даже когда она не
    >занята пользовательскими процессами, поэтому все время держать данные неактивных процессов в
    >оперативной памяти нерационально.

    Это где это у акселератора неиспользуемые данные для выгрузки в своп?

     
  • 3.22, User294 (ok), 20:05, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >поэтому все время держать данные неактивных процессов в
    >оперативной памяти нерационально.

    Ну извините, или времена реакции, или экономия оперативки. Диски штука медленная, да.

     

  • 1.7, zomg (?), 16:02, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Wikia?
    Может Wikipedia? Wikimapia?
     
     
  • 2.15, Аноним (-), 16:53, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Wikia?
    >Может Wikipedia? Wikimapia?

    нет, wikia.com

     

  • 1.8, hostmaster (??), 16:05, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для тех кто в танке замечу что описанные изменения есть пока только в trunk/
     
  • 1.12, Аноним (-), 16:21, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наглая ложь.
    В статье ни слова о btree.

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

    // pppp

     
     
  • 2.17, Аноним (-), 18:13, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    "локальные по памяти программы работают существенно эффективнее наиболее оптимальных с теоретической точки зрения" = "огурцы ложкой банка майонеза"
     
  • 2.18, tn (?), 18:29, 15/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Наглая ложь.
    > В статье ни слова о btree.

    8-ой абзац:

    > A quick browse of the mental catalog flipped up the binary-heap card, which....

    http://en.wikipedia.org/wiki/Binary_heap :

    > A binary heap is a heap data structure created using a binary tree.

     
     
  • 3.34, Аноним (-), 11:16, 16/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Наглая ложь.
    >> В статье ни слова о btree.
    >
    >8-ой абзац:
    >
    >> A quick browse of the mental catalog flipped up the binary-heap card, which....
    >
    >http://en.wikipedia.org/wiki/Binary_heap :
    >
    >> A binary heap is a heap data structure created using a binary tree.

    binary tree != b-tree

    Ваш КО

    // pppp

     

  • 1.21, аноним (?), 19:02, 15/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кстати - Varnish сам по себе целиком и полностью на парадигме "Нет дисков и RAM'ы - есть VM!" И надо сказать продугд удался ...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру