Представлен (http://mailman.nginx.org/pipermail/nginx-announce/2014/00014...) новый выпуск основной ветки высокопроизводительного HTTP-сервера nginx 1.7.2 (http://nginx.org/), в котором продолжено развитие новых возможностей. В новой версии в блок конфигурации upstream добавлена (http://nginx.org/en/CHANGES) поддержка директивы "hash (http://nginx.org/en/docs/http/ngx_http_upstream_module.html#...)", предназначенной для организации балансировки нагрузки с привязкой клиента к серверу. Кроме того, реализован механизм дефрагментации свободных блоков разделяемой памяти.
URL: http://mailman.nginx.org/pipermail/nginx-announce/2014/00014...
Новость: http://www.opennet.me/opennews/art.shtml?num=40022
>Кроме того, реализован механизм дефрагментации свободных блоков разделяемой памяти.Это вообще важно для такой программы?
Как я понимаю это имеет смысл только при наличии большого количества данных, которые должны быть в памяти постоянно. Мне кажется у веб-сервера таких данных не много. Впрочем, сделали так сделали -- хуже точно не будет.
Ну ведь он может висеть в памяти годами без перезагрузки.
Ага. И если все 50 метров его личных данных станут чересчур фрагментированными, то небо окрасится в чёрный цвет и по телевизору будут показывать лишь пятую серию "санта-барбары"?
> Ага. И если все 50 метров его личных данных станут чересчур фрагментированными,
> то небо окрасится в чёрный цвет и по телевизору будут показывать
> лишь пятую серию "санта-барбары"?Ну ведь и Сысоев не IIS пишет
а как бэкенд прокси его уже не юзают?
> Ага. И если все 50 метров его личных данных станут чересчур фрагментированными,
> то небо окрасится в чёрный цвет и по телевизору будут показывать
> лишь пятую серию "санта-барбары"?Нет, тогда производительность просядет (большой блок придется долго выискикать в помойке из кучи мелочи) или в некотором случае совсем не удастся выкроить блок нужного размера из той вермишели которая образовалась.
Сильно фрагментированная куча плоха по нескольким причинам:
1. Внутреняя фрагментации страниц. Приводит к большему количеству используемых страниц.
2. Большее количество используемых страниц приводит к большей нагрузке на TLB, как следствие кеш становится менее эффективным, растет число промахов, что приводит в удалению строк из кеша и помещению туда новых, что в свою очередь приводит к снижению производительности(из-за необходимости выполнения новых virtual to physical address translation lookup'ов)
3. Опять же, из-за большего количества используемых страниц возрастает вероятность кеш миссов по L1/L2/L3 кешам. Что опять же приводит к потере производительности(время доступа к строке памяти возрастает на несколько порядков).Короче говоря, если вы отдаете на 1rps статикой одну страничку - вы наверное ничего не замете.
>[оверквотинг удален]
> 2. Большее количество используемых страниц приводит к большей нагрузке на TLB, как
> следствие кеш становится менее эффективным, растет число промахов, что приводит в
> удалению строк из кеша и помещению туда новых, что в свою
> очередь приводит к снижению производительности(из-за необходимости выполнения новых
> virtual to physical address translation lookup'ов)
> 3. Опять же, из-за большего количества используемых страниц возрастает вероятность кеш
> миссов по L1/L2/L3 кешам. Что опять же приводит к потере производительности(время
> доступа к строке памяти возрастает на несколько порядков).
> Короче говоря, если вы отдаете на 1rps статикой одну страничку - вы
> наверное ничего не замете.Ну и да, еще не стоит забывать про облегчение жизни юзерспейсному менеджеру памяти, как уже заметили тут.
>>Кроме того, реализован механизм дефрагментации свободных блоков разделяемой памяти.
> Это вообще важно для такой программы?
> Как я понимаю это имеет смысл только при""While this isn't a problem for nginx itself, it is known to be bad for various 3rd party modules.
http://mailman.nginx.org/pipermail/nginx-devel/2014-June/005...Гм, патч почти год http://mailman.nginx.org/pipermail/nginx-devel/2013-June/003... полировали. >> Может, и не очень важно...
> Как я понимаю это имеет смысл только при наличии большого количества данных, которые
> должны быть в памяти постоянно.Это имеет смысл в случае если программа долго работает и тасует достаточно много данных.
> Как я понимаю это имеет смысл только при наличии большого количества данных, которые должны быть в памяти постоянно.Неа. Читаем Кнута, просвещаемся. Фрагментация памяти склонна к развитию несмотря на освобождения памяти. Даже правильнее будет использовать вместо предлога "несмотря", предлог "благодаря." Динамическое выделение памяти -- это зло. И сборка мусора -- адепт его. Позволяющий победить фрагментацию, но требующий взамен глобал локов.
> Динамическое выделение памяти -- это злоДа, расскажи подробнее про это, теоретик диванный
>>Кроме того, реализован механизм дефрагментации свободных блоков разделяемой памяти.
> Это вообще важно для такой программы?
> Как я понимаю это имеет смысл только при наличии большого количества данных, которые должны быть в памяти постоянно. Мне кажется у веб-сервера таких данных не много.Если сам nginx от этого не сильно страдает, у него есть куча интересных модулей.
Встроенные perl, lua, обработчики на лету картинок, видео, и т.д.