proxy cache stampede

Евгений 'Rush' Непомнящий rush.zlo на gmail.com
Чт Сен 22 11:13:53 UTC 2011


22 сентября 2011 г. 12:36 пользователь Alex Vorona <voron на amhost.net> написал:
> Это проблема медленной ФС, а не проблема slowfs_cache, до включения которого
> подразумевается что кроме этой медленной ФС вообще нет другого хранилища.

Alex, либо я вас не понял, либо вы меня. Постараюсь перефразировать, а
вы меня поправьте в чём не согласны (впрочем всё, что я напишу - не
только теория, но и практика):

1. Если nginx читает файл с "медленной" ФС (на самом деле важна не
скорость чтения, а скорость отклика - тут то и начинается попа) то
страдают _все_ клиенты данного воркера. В своё время долго гадали
почему сервер с 12Gbit/s каналом не может отдать хотя бы 10Mbit/s
локального файла - доходило до того, что сессия разваливалась. А всё
потому, что в том же воркере nginx отдавал несколько файлов с nfs.
2. Гляньте на код модуля slowfs. В случае большого файла (а именно тут
и будут затыки в п1.) он _сразу_ отдаётся клиенту, без
предварительного копирования в кеш.

Вывод - пока не будет закеширован весь популярный контент (в моём
случае это десятки терабайт) nginx будет _СТРАШНО_ тормозить и тУпить,
вплоть до разрыва сессий (Либо воркеров надо будет сделать столько,
сколько соединений, что в мойм случае нереально). Ну и опять же про
мой случай - закешировать контент _нереально_, он каждый день
изменяется (не по 10Тб конечно, но всё равно) и slowfs cache мне
принёс больше геморроя, чем пользы. Если точнее ещё раз (не он первый
не он последний, конечно) оттянул момент заглядывания в исходники
nginx для принятия решения об отказе совмещения медленных (читай -
сетевых, медленной наши ФС назвать тяжело при 1-20Gbit/s) и nginx. Так
что slowfs cache - только для небольших объёмов кешируемого контента
(несколько гигабайт), быстрых каналах (от сотенки) и/или статического
контента.

-- 
Cogito ergo sum


Подробная информация о списке рассылки nginx-ru