Здравствуйте, All!

Использую nginx 1.19.10 из официального репозитория на сайте nginx.org,
без сторонних модулей. При этом в логах наблюдаются такие строки:

[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

Насколько я понимаю - это означает что worker-процесс nginx аварийно
завершил свою работу. Можно ли как-то настроить nginx или систему
таким образом, чтобы в этот момент создавался дамп памяти процесса,
чтобы можно было бы найти причину этого аварийного завершения работы?

Дальше в логе наблюдаются такие строки:

[alert] 3459906#3459906: ignore long locked inactive cache entry
de41775189dd3dbc95ae14cfa9fa5813, count:2

Насколько я понимаю - это означает, что worker-процесс nginx аварийно
завершил свою работу в момент обновления записи в cache, и эта запись
осталась залоченной в памяти. Можно ли сделать так, чтобы в разделяемой
памяти в качестве признака блокировки использовался бы PID процесса?

Т.е. если 0 - то запись не заблокирована, если какое-то ненулевое
значение - значит она заблокирована worker-процессом nginx с таким PID.

И в случае обнаружения long locked inactive cache entry можно было бы
проверить - существует ли в системе worker-процесс nginx с таким PID,
и если нет - тогда просто разблокировать эту cache entry и продолжить
нормальную работу.

Альтернативный вариант - это сделать так, чтобы nginx не падал,
но насколько я понимаю, программ без ошибок не бывает
и они есть даже и в nginx в настоящий момент времени.

Конфиг бекенда, на котором была эта ошибка, примерно такой:

aio threads;
aio_write on;

sendfile on;
sendfile_max_chunk 1M;

server {
listen 80;

server_name example.com;

root /home/www/example.com/static.www/;

location / {
error_page 404 = @php;
location ~ \.xml$ { log_not_found off; }
location ~ \. { expires 24h; }
return 404;
}

location @php {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME
/home/www/example.com/engine/index.php;
fastcgi_param HTTPS $http_x_forwarded_https if_not_empty;
fastcgi_pass unix:/run/php-fpm/www.sock;

fastcgi_cache one;
fastcgi_cache_key "$request_method $scheme://$host$request_uri";
fastcgi_cache_min_uses 1;

fastcgi_cache_valid 200 301 302 404 10m;

fastcgi_cache_use_stale error timeout invalid_header updating
http_500 http_503;
fastcgi_cache_lock on;
fastcgi_cache_revalidate on;
fastcgi_cache_background_update on;
add_header X-Cache-Status $upstream_cache_status;

fastcgi_cache_bypass $http_update_nginx_cache;
fastcgi_cache_bypass $cookie_no_nginx_cache;
fastcgi_no_cache $cookie_no_nginx_cache;
}

location /static/ {
root /home/www/example.com;
add_header Access-Control-Allow-Origin *;
add_header Cache-control public;
expires 1y;
error_page 404 = @static;
log_not_found off;
}

location @static {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME
/home/www/example.com/engine/static.php;
fastcgi_param HTTPS $http_x_forwarded_https if_not_empty;
fastcgi_pass unix:/run/php-fpm/www.sock;
}
}

Возможно получится воспроизвести эту ошибку и падение воркер-процесса
nginx с таким конфигом с помощью рандомного нагрузочного тестирования?

Память на сервере ECC и в /var/log/messages нет информации про ошибки
памяти, так что вероятность того, что это hardware related проблема -
близка к нулю.

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru