Здравствуйте, 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

Ответить