Re: Проблема при >1500 одновременных коннектов.

[Igor Sysoev <is@xxxxxxxxxxxxx>]

On Tue, Feb 10, 2009 at 11:51:57AM +0100, ArjLover wrote:

> И я сижу и думаю второй день - что же делать. Действительно в какой-то
> момент (все же очень резко!) падает _эффективность_ чтения. Диски трудятся
> на полную, а практически на выходе имеем 100 мегабит. Может стоит читать
> меньшими блоками? Если при этом я получу загрузку не 30%, а 60% при моих
> стандартных 400 мегабитах - ну и черт с ними, главное что все не будет
> сворачиваться в черную дырку.
> Стоит уменьшить kern.ipc.sfreadahead=524288? или sendfile_max_chunk 128k;?
> упс. 128к. когда это я его туда нарисовал... :)
> 
> http://film.arjlover.net/problem2/02p.html
> Вот. Мой живой mrtg - можно посмотреть на все диски - три последних sata и
> дальше параметры системы. Вчера день назывался "на пределе" с явно хандрящим
> nsbuff, который ушел в пике в 19-30 и в 20-30 я сделал nginx restart. От
> полуночи - нормальная жизнь. в 4 и 10 часов у меня плановые рестарты.
> 
> Начинаю верить что проблема в настройке патча. Ширина канала величина
> фиксированная, чем больше народу - тем меньше достается каждому, а диски
> читают большими блоками. К сожалению до конца не понял как это работает,
> какими блоками и куда читается с диска и как это потом кормится клиенту в
> соединение. Но  действительно несложно предположить что в какой-то момент
> наступает перелом - читается много, а отдается мало. Кстати давно хотел
> спросить - можно эту эффективность увеличить за счет использования
> оперативки? Сейчас в 4ГБ живет практически один nginx и 117M Active при моих
> проблемах смотрятся издевательски.

Идея патча + MAXPHYS состоит в следующем.

Современные SATA диски не могут сделать больше 50-120 seek'ов в секунду.
Дефолтный MAXPHYS = 128K. Это означает 6-15Mbyte/s. Увеличив MAXPHYS
до 1M, мы можем теоретически получить 50-128Mbyte/s. Но только теоретически:
там есть другие физические ограничения.

Следующий вопрос - где хранить прочитанное, если клиент не успевает
его читать (а он, как правило, не успевает). Тут есть такие варианты

1) юзерспэйс,
2) в ядре в uma (часть Wired),
3) в ядре в кэше страниц файлов (часть Active и Incactive/Cache).

Вариант номер раз - это выключить в nginx'е sendfile и увеличить
output_buffers (опционально включить directio).

Вариант номер два - zfs и патч gcache. Проблема в том, что до недавнего
времени uma была очень мала.

Вариант номер три - использовать sendfile. Но с ним беда, он больше 64К
не читает. Для этого был написан патч.

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

> 2009/2/10 Igor Sysoev <is@xxxxxxxxxxxxx>
> 
> > On Tue, Feb 10, 2009 at 12:20:07PM +0300, Artemiev Igor wrote:
> >
> > > On Tue, Feb 10, 2009 at 10:27:00AM +0300, Igor Sysoev wrote:
> > > > Симптомы другие: здесь - 100% загрузка sata'шных дисков.
> > > Симптомы всё те же - резкое падение отдачи по сети. C диска читается на
> > пределе, а по сети отдаётся на порядок меньше.
> >
> > Цитата:
> >
> > ОС видит один физический диск. На самом контроллере 224MB памяти, доступной
> > для
> > кеширования, имеется поддержка disconnect и tagging queueing.  Проблема не
> > в
> > том, что грузится контроллер и тормозит, этого как раз нет, проблема в
> > черезвычайно низкой эффективности патченного sendfile(2).
> >
> >
> > --
> > Игорь Сысоев
> > http://sysoev.ru
> >
> >
> 
> 
> -- 
> Best regards,
> Anton Kuznetsov.

-- 
Игорь Сысоев
http://sysoev.ru