Re: Иногда кеш растет сверх лимита

[kpoxa]

Добрый день.

Вот сейчас воспроизвелась проблема, если сделать strace на cache manager,
то видно, что есть удаления файлов с одного из двух кешей, со второго нет,
иногда бывают
futex(0x7fec52473070, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
...
futex(0x7fec52473070, FUTEX_WAKE, 1)    = 0
...
futex(0x7fec52473070, FUTEX_WAKE, 1)    = 1

-HUP не помогает, несмотря на смену всех процессов, кроме рутового.



14 августа 2015 г., 14:28 пользователь kpoxa <kpoxa at kpoxa.net> написал:

> Добрый день.
>
> Просто так никто никаких сигналов не отправлял. Судя по логам процессы не
> умирали.
> На сервере debian, обновление конфига делается через -HUP мастер процессу
> (это в инит скрипте reload делает).
> И раз в сутки ротация логов с  kill -USR1 `cat /var/run/nginx.pid`
> Что можно для диагностики сделать в случае если замечу, что кеш
> переполняется?
>
> 13 августа 2015 г., 21:19 пользователь Maxim Dounin <mdounin at mdounin.ru>
> написал:
>
>> Hello!
>>
>> On Thu, Aug 13, 2015 at 06:41:44PM +0300, kpoxa wrote:
>>
>> > Добрый день.
>> >
>> > Есть сервер с 2 SSD под кеш
>> >
>> > Filesystem      Size  Used Avail Use% Mounted on
>> > /dev/sdb1       210G  167G   44G  80% /ssd2
>> > /dev/sda3       200G  157G   44G  79% /ssd
>> >
>> >  и следующий конфиг:
>> >
>> >     proxy_cache_path /ssd     levels=1:2 keys_zone=ssd1:2000m
>> > max_size=160000m inactive=7d loader_files=1000 use_temp_path=off;
>> >     proxy_cache_path /ssd2    levels=1:2 keys_zone=ssd2:2000m
>> > max_size=170000m inactive=7d loader_files=1000 use_temp_path=off;
>> >     split_clients $uri$is_args$args $disk {
>> >         56.3%     2;
>> >         *         1;
>> >     }
>> >
>> > server {
>> > ...
>> >  location / {
>> >     proxy_cache ssd$disk;
>> >
>> >  }
>> > }
>> >
>> > Периодически кеш разрастается выше лимита, пока не занимает весь диск.
>> > При рестарте nginx место очищается до максимально разрешенного
>>
>> Что при этом в логах?  Падения рабочих процессов, администраторы с
>> шаловливыми руками и правом отсылки сигналов nginx'у?  Проще всего
>> на такое наступить, если рабочий процесс упал и/или был
>> принудительно завершён, и не смог разблокировать элементы кеша.
>>
>> Ну и я просто оставлю эти ссылки тут, на всякий случай:
>>
>> http://mailman.nginx.org/pipermail/nginx-ru/2015-May/055936.html
>> http://mailman.nginx.org/pipermail/nginx-ru/2015-May/055937.html
>>
>> --
>> Maxim Dounin
>> http://nginx.org/
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Kpoxa
>



-- 
Kpoxa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150814/a06a0085/attachment.html>