php session_write_close 警告

我們所有的錯誤都記錄到 NewRelic，我們總是session_write_close在錯誤日誌中看到一些警告。然而，錯誤率增加了，它現在淹沒了我們的 24 小時日誌。

我們的伺服器人口眾多，同時有很多使用者登錄。這些使用者中的大多數都沒有看到這些session_write_close警告。有些人這樣做，這使我們幾乎不可能找到原因並解決它。

這是完整的錯誤消息：

Error message
E_WARNING: session_write_close(): Failed to write session data (files).    
Please verify that the current setting of session.save_path is correct        
(/opt/php55/var/lib/php/session-nginx)

所以我做了一個檢查，看看該目錄中有多少文件9431以及權限是什麼-rw------- 1 nginx nginx。

我看不出我的配置、文件權限等有什麼問題。

我們別無選擇。我可以做些什麼來解決這個問題？目前影響不到 1% 的使用者，我們只想將我們的費率保持在盡可能低的水平。

這是我的 php.ini 配置列表。

Directive   Local Value Master Value
session.auto_start  Off Off
session.cache_expire    180 180
session.cache_limiter   nocache nocache
session.cookie_domain   no value    no value
session.cookie_httponly Off Off
session.cookie_lifetime 0   0
session.cookie_path /   /
session.cookie_secure   Off Off
session.entropy_file    /dev/urandom    /dev/urandom
session.entropy_length  32  32
session.gc_divisor  1000    1000
session.gc_maxlifetime  1440    1440
session.gc_probability  1   1
session.hash_bits_per_character 5   5
session.hash_function   0   0
session.name    PHPSESSID   PHPSESSID
session.referer_check   no value    no value
session.save_handler    files   files
session.save_path   /opt/php55/var/lib/php/session-nginx    /opt/php55/var/lib/php/session-nginx
session.serialize_handler   php php
session.upload_progress.cleanup On  On
session.upload_progress.enabled On  On
session.upload_progress.freq    1%  1%
session.upload_progress.min_freq    1   1
session.upload_progress.name    PHP_SESSION_UPLOAD_PROGRESS PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix  upload_progress_    upload_progress_
session.use_cookies On  On
session.use_only_cookies    On  On
session.use_strict_mode Off Off
session.use_trans_sid   0   0

一些伺服器統計數據：CentOS 6.6 PHP 5.5.28 Nginx 1.6.2 歡迎任何幫助！

對於高負載的伺服器，我會使用memcached（甚至可能redis？）進行會話儲存。因此，如果我處於您的情況，我可能只是為了它自己而設置它，然後看看問題是否偶然消失了。

我也不會使用 php 的會話垃圾收集，它將垃圾收集掛起 Web 請求作業。我會設置自己的工作來處理這個問題，要麼從 cron 執行，要麼從某個作業排隊系統執行。

在 php 的會話垃圾收集之外，您是否已經有任何類型的會話清理系統？

發生這種情況的機率是 0.1%，這與您的session.gc_divisor設置相符嗎？

您的 php 程序是否以 nginx 使用者身份執行？根據session.gc_*設置進行清理的是 php 而不是 nginx。如果 php 作為 nginx 執行，這在訪問 php 會話文件方面很好，但在與 nginx 伺服器共享使用者 ID 方面可能不好。

您可能需要該會話目錄的執行權限，以便您的垃圾收集器可以看到要清理的內容。

session.save_path如果您沒有設置特定於您的應用程序的內容，我也會擔心。這意味著如果您有多個應用程序共享同一個會話目錄，那麼當垃圾收集執行時，到期時間最短的應用程序將獲勝，清除另一個應用程序的會話。

引用自：https://serverfault.com/questions/728821