PHP пишет новые сессии (пусто) непрерывно

Question

У меня есть балансировщик нагрузки и два экземпляра ec2 с php-fpm + nginx для обслуживания моего сайта и я настроил redis для хранения сессий php. Запустив команду «keys *» в redis-cli, я понял, что php создает много пустых сессий, помимо правильных. Даже если я закрываю браузер, очищаю все куки и не запускаю команду php или открываю URL, он продолжает создавать пустые сеансы. Проблема в том, что время истечения сеанса составляет 15 часов, поэтому он создаст больше сеансов, чем удалит за это время, поскольку он создает около 30 пустых сеансов в час. Единственный способ остановить создание новых сессий - остановить php-fpm в моих экземплярах.

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

keys *
1) "PHPREDIS_SESSION:22u4tot1ilj2jn2pegsvsa9455"
2) "PHPREDIS_SESSION:u9c530pk3h0kr0moigf9a030c7"
...
316) "PHPREDIS_SESSION:d3t36ou13ljuj5ntt2l2b6sne0"
317) "PHPREDIS_SESSION:5kbn03dn01qdn405pg43bbd1i3"

Заполнен только 1 сеанс, остальные 316 пусты. Запустив "ключ ttl", я вижу, что время истечения совпадает с тем, которое я установил на php.ini.

Мой php-код просто session_start (); для тестовых целей.

Мой php.ini:

session.use_strict_mode = 0
session.use_cookies = 1
session.cookie_secure = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.cookie_lifetime = 54000
session.cookie_path = /
session.cookie_domain = .domain.xxx
session.cookie_httponly = 1
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 50
session.gc_maxlifetime = 54000
session.cache_limiter = nocache
session.cache_expire = 900
session.use_trans_sid = 0

Я проверил phpinfo () и эти конфиги ничего не перезаписывают

nginx.conf:

#This is the block that responds to loadbalancer requests and serves the website
server {
    listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  localhost;
        root         /var/www/html;

        upstream php-fpm {
        server 127.0.0.1:9000;
        }

        location /nginx-health {
           access_log off;
           return 200 "healthy\n";
       }

        try_files $uri $uri/ @rewrite;
        location @rewrite {
           rewrite ^/(.*)$ /index.php?param=$1;
       }

    location ~ \.php$ {
     try_files $uri =404;
     fastcgi_intercept_errors on;
     fastcgi_index  index.php;
     include        fastcgi_params;
     fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
     fastcgi_pass   php-fpm;
    }

}

#this is the block to serve a websocket listener. It handles conections directly to the node, no passing by load balancer.
server {
        listen       443 ssl http2;
        listen       [::]:443 ssl http2;
        server_name  sub.domain.xxx;
        root         /var/www/html;

        ssl_session_cache shared:SSL:1m;
        ssl_session_timeout  720m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP;
        ssl_prefer_server_ciphers on;

    location / {
        proxy_set_header Host $host;
        proxy_pass http://127.0.0.1:4555;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
    }

    ssl_certificate /etc/letsencrypt/live/sub.domain.xxx/fullchain.pem; 
    ssl_certificate_key /etc/letsencrypt/live/sub.domain.xxx/privkey.pem;
}

Я пытался создать cronjob, чтобы получить ключи redis, проверить его значение и удалить пустые, но я увидел, что запуск команды «keys» действительно вреден для рабочей среды. У кого-нибудь есть идеи, как решить эту проблему?

Answer 1

Я не могу точно сказать вам, что происходит, но у меня есть несколько предложений:

1. Да, выполнение keys является операцией O (n), но если ваш экземпляр небольшой, то он тривиален. Следите за своим медленным журналом и посмотрите, действительно ли какая-либо из ваших операций keys занимает слишком много времени, но я предполагаю, что это не так.
2. Если вы считаете, что дополнительные сеансы создаются проверками работоспособности nginx, возьмите пик в журналах доступа, вы должны увидеть все обращения к вашему сайту.
3. Я также вижу, что вы используете http2. Я не очень много знаю о том, как http2 взаимодействует с php, но подумайте о том, чтобы вернуться к http 1.1 и посмотреть, будете ли вы вести себя так же.