Re: fastcgi_cache в nginx

[Maxim Dounin]

Hello!

On Sat, Mar 20, 2010 at 06:41:10PM +0200, Alex Vasilenko wrote:

[...]

> Все верно - load avg это количество процессов, которые стоят в очереди на
> выполнение. Неужели 30 рандомных запросов это много для диска?

30 запросов к диску - это не много, типичный SATA диск легко 
выдаёт 100 операций случайного чтения в секунду.  Но один запрос к 
nginx'у - это обычно больше одного запроса к диску.

Ну и диски опять же бывают разные.

> Софтварных вариантов оптимизации я вижу 2:
> 
>    1. перейти на фс, оптимизированную для мелких файлов, например reiserfs.
>    2. подтюнить параметры ядра.
> 
> 1. Что скажете про переход на reiserfs? У кого-нибудь есть опыт работы с ним
> в связке с nginx cache?
> 2. Тут я в полном неведении. Кроме очевидного noatime. Подскажите, куда хоть
> смотреть.

AFAIK, в первую очередь в линуксе нужно тюнить io scheduler 
(всмысле - поставить правильный).  Но про линукс тут вообще мало 
специалистов, и я к ним точно не отношусь.

В nginx'е в зависимости от среднего размера ответа - скорее всего имеет 
смысл поднять output_buffers и отключить sendfile.  Это позволит 
несколько снизить нагрузку на диск за счёт чтения большими 
блоками.

[...]

> > В случае большого количества worker'ов это также может быть lock
> > contention (симптом - воркеры жрут 100% CPU, видно в top'е,
> > наблюдалось если мне не изменяет память на 30 или около того).
> > Лечить уменьшением количества воркеров до разумного.
> 
>  Спасибо, помогло. Правда симптомов, вами указанных не было. Уменьшил
> количество воркеров с 64 до 20 (4х ядерный сервер), load avg теперь не так
> скачет.
> Дальнейшее тестирование покажет.

Если 100% CPU не было - то и lock contention не было.  А то что 
load avg при уменьшении количества воркеров скакать стал меньше - 
это естественное следствие, ибо процессов стало меньше.  Вопрос в 
первую очередь как изменилось среднее время ответа на запрос.

Maxim Dounin