On 08.05.2021 0:36, Maxim Dounin wrote:
Скорее всего в данном случае дело в aio_write, см.
https://trac.nginx.org/nginx/ticket/2162.
Максим, Вы говорите в комментариях к этому тикету:
> It is not expected to affect real-world use cases,
> though probably worth fixing anyway.
У меня
Hello!
On Fri, May 07, 2021 at 10:40:52PM +0300, Gena Makhomed wrote:
> On 07.05.2021 21:19, Maxim Dounin wrote:
>
> >> [alert] 2569378#2569378: *449013402 open socket #29 left in connection 3
> >> [alert] 2569378#2569378: *449013403 open socket #32 left in connection 8
> >> [alert]
On 07.05.2021 21:19, Maxim Dounin wrote:
[alert] 2569378#2569378: *449013402 open socket #29 left in connection 3
[alert] 2569378#2569378: *449013403 open socket #32 left in connection 8
[alert] 2569378#2569378: aborting
[...]
Конфиг бекенда, на котором была эта ошибка, примерно такой:
abort;", то случится abort с последующей записью дампа
(http://nginx.org/r/debug_points).
> Дальше в логе наблюдаются такие строки:
>
> [alert] 3459906#3459906: ignore long locked inactive cache entry
> de41775189dd3dbc95ae14cfa9fa5813, count:2
>
> Насколько я понимаю - эт
завершения работы?
Дальше в логе наблюдаются такие строки:
[alert] 3459906#3459906: ignore long locked inactive cache entry
de41775189dd3dbc95ae14cfa9fa5813, count:2
Насколько я понимаю - это означает, что worker-процесс nginx аварийно
завершил свою работу в момент обновления записи в cache, и эта
Hello!
On Tue, Jul 31, 2018 at 02:03:47PM +0300, Иван wrote:
> Регулярно в логах (пару раз за 5 минут) вижу
>
> [alert] 17816#17816: ignore long locked inactive cache entry
> 9100488b2180c1fc582384712a73791d, count:1
>
> Две прокси на один бэкэнд. Бэкэнд - сервер nginx
Здравствуйте!
Регулярно в логах (пару раз за 5 минут) вижу
[alert] 17816#17816: ignore long locked inactive cache entry
9100488b2180c1fc582384712a73791d, count:1
Две прокси на один бэкэнд. Бэкэнд - сервер nginx, отдающий статику.
Прокси - два одинаковых сервера, в разных странах. Проявляется
У нас файлы не удаляются, если воркера убить SIGKILL. Сразу после кила
сыпятся ошибки(по ttl expire)
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,271068,272020#msg-272020
___
nginx-ru mailing list
nginx-ru@nginx.org
Нет, не падают. По крайней мере о падении должно сообщаться в лог.
Сообщений не было. Не было и ООМ-killer. Да, если стрельнуть в воркера
сигналом, то файлы отпускаются и удаляются cache-manager. Но вместе с этим
воркером мы теряем и запросы, которые этот воркер обрабатывал, а это уже
обидно.
16
Есть предположение, что у вас падают воркеры. А кеш менеджер думает, что
файл еще занят им.
Плюс, мы не можем зарепродюсить данную проблему на el7. Хотя на el6 без
проблем - достаточно лишь kill -9 воркера
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,271068,272018#msg-272018
А как узнать, что ответ от бэкенда медленный? По моим наблюдениям, объект в
кэше мог пролежать несколько дней. При этом сам бэкенд могли перезагрузить
по несколько раз за это время. Объект как был в кэше и был занят nginx, так
и продолжал это делать. На мой взгляд это как раз баг, который был
Спасибо! Попробуем!
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,271068,272013#msg-272013
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Hello!
On Mon, Jan 16, 2017 at 01:23:44PM +, Anton Kiryushkin wrote:
> Максим, я вас расстрою. В моем случае речь не может идти о websocket, так
> как их нет как технологии в проекте. Я не могу дать абсолютно все
> подробности. Но смысл кэширования в том, чтобы сохранять ответы, которые
>
Максим, я вас расстрою. В моем случае речь не может идти о websocket, так
как их нет как технологии в проекте. Я не могу дать абсолютно все
подробности. Но смысл кэширования в том, чтобы сохранять ответы, которые
генерируются бэкендом. Исключительно http/1.0. Даже не 1.1.
пн, 16 янв. 2017 г. в
Hello!
On Mon, Jan 16, 2017 at 11:07:38AM +, Anton Kiryushkin wrote:
> Спасает обновление минимум до 1.11.6. Жаль, что разработчики это никак не
> комментировали.
Если спасает - значит проблема была в том, что вы со включённым
кешированием пытались проксировать WebSocket'ы. Смысла в этом
Спасает обновление минимум до 1.11.6. Жаль, что разработчики это никак не
комментировали.
пт, 13 янв. 2017 г. в 13:38, liveder :
> Добрый день, Антон
>
> Решили ли вы в итоге проблему? Если да, то как?
>
> Спасибо
>
> Posted at Nginx Forum:
>
Добрый день, Антон
Решили ли вы в итоге проблему? Если да, то как?
Спасибо
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,271068,271981#msg-271981
___
nginx-ru mailing list
nginx-ru@nginx.org
xy_ignore_headers Expires Cache-Control;
>> proxy_cache_min_uses 2;
>> proxy_cache_valid 200 302 7d;
>> proxy_cache_key $uri;
>> proxy_force_ranges on;
>>
>>
>> Примерно через 4 часа после перезапуска в логе начинают появляться
>> сообщения типа:
>>
>
p=5ms;
> proxy_temp_path /path/to/temp/folder 1 2;
> proxy_ignore_headers Expires Cache-Control;
> proxy_cache_min_uses 2;
> proxy_cache_valid 200 302 7d;
> proxy_cache_key $uri;
> proxy_force_ranges on;
>
>
> Примерно через 4 часа после перезапуска в логе начинают появлятьс
;
proxy_cache_valid 200 302 7d;
proxy_cache_key $uri;
proxy_force_ranges on;
Примерно через 4 часа после перезапуска в логе начинают появляться
сообщения типа:
ignore long locked inactive cache entry e4717ba34b1d9f128e974fb692755202,
count:1
После чего свободного места в разделе не остается совсем. Если
День добрый.
В логе появляется много ошибок типа:
ignore long locked inactive cache entry 14e633f0cc0c31393f02b8e2845b4133,
count:1
Основной конфиг:
user nginx;
worker_processes 8;
worker_rlimit_nofile 819200;
error_log /var/log/nginx/error.log warn;
pid/var/run/nginx.pid;
events
21 matches
Mail list logo