Re: fastcgi_cache в nginx

[Alex Vasilenko]

Здравствуйте Максим,


> Без loader'а nginx как минимум не сможет следить за размером кеша.

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

Если мне не изменяет мой cклероз, на линуксе load avg включает

процессы ждущие диска. Вероятнее всего вы просто упёрлись в

диски. Решение - тюнить дисковую подсистему, добавлять дисков, ну

или просто перелезать на SSD.

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

   1. перейти на фс, оптимизированную для мелких файлов, например reiserfs.
   2. подтюнить параметры ядра.

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

disk cache сейчас 6гб, но он не сильно помогает, т.к. запросы зачастую
рандомны и все равно приходиться лезть на диск.
Боюсь, что хардварные решения пока что не подходят, в силу своей стоимости.

В случае большого количества worker'ов это также может быть lock

contention (симптом - воркеры жрут 100% CPU, видно в top'е,

наблюдалось если мне не изменяет память на 30 или около того).

> Лечить уменьшением количества воркеров до разумного.

 Спасибо, помогло. Правда симптомов, вами указанных не было. Уменьшил
количество воркеров с 64 до 20 (4х ядерный сервер), load avg теперь не так
скачет.
Дальнейшее тестирование покажет.

Спасибо

Alexandr Vasilenko
Web Developer
ICQ:284752117/JID:mente на jabber.kiev.ua <JID%3Amente на jabber.kiev.ua>
Skype:menterr
mob: +38097-611-45-99
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100320/2b0eb3a4/attachment.html>