问题描述
有关一些奇怪的原因，就在今天我们的服务器决定是会议开始时很慢。对于每一个在session_start，服务器或者超时30秒后，或将需要大约20秒就启动会话。这是很奇怪的，看到它没有这样做了很长一段时间（最后一次我们的服务器做了，这是约7个月前）。我试图改变通过数据库来运行，而不是会话，工作正常，但是，由于我们目前的网站建成后，它会需要几天去每个页面上，改变会议的加载，包括一个新的会话处理程序。因此，我的问题是：
For some odd reason, just today our server decided to be very slow during the starting of sessions. For every session_start, the server either times out after 30 seconds, or it'll take about 20 seconds for it to start the session. This is very weird, seeing as it hasn't done this for a very long time (the last time our server did this was about 7 months ago). I've tried to change the session to run through a database instead, and that works fine, however, as our current website is built, it'd take days to go on every page and change the loading of sessions to include a new session handler. Therefore my question remains:
为什么这么慢，为什么只是有时？
Why is it so slow, and why only sometimes?
我们与24GB的RAM的专用HETZNER服务器上运行，并且CPU速度不够快，只需运行一个简单的网络服务器（至强，我相信，但我不知道）。我们与Apache + FastCGI的PHP5 +安装在服务器上运行Debian。
We run on a dedicated hetzner server with 24GB's of ram, and a CPU fast enough to just run a simple webserver (a Xeon, I believe, but I'm not sure). We run debian on the server with an apache+fastcgi+php5 setup.
服务器并不大的负荷，既不通过服务器的状态，以及在顶命令汇报。 Vnstat 报告没有任何问题与我们的网络链接（同样，这不会导致一个缓慢的本地会话处理）。 IOtop 报告与进程接管整个硬盘没有问题。写入到会话文件所在的临时文件夹，如果通过vim的工作做得快。
The server doesn't report much load, neither through server-status as well as the top command. Vnstat reports no problem whatsoever with our network link (again, that wouldn't result in a slow local session handling). IOtop reports no problem with processes taking over the entire harddrive. Writing to the tmp folder where the session files are located works fast if done through vim.
此外，为了明确这一点，我主要在这里关注的不是我们是否应该切换到DB或会话的内存缓存的版本，它只是要问，为什么出现这种情况，因为一切我看看在似乎是做工精细，除了PHP本身。
Again, to make this clear, my main concern here isn't whether or not we should switch to a DB or a memory-cached version of the sessions, it's simply to ask why this happens, because everything I take a look at seems to be working fine, except for the PHP itself.
修改：
在我们的PHP tmp目录下的文件最大为2.9 MB，所以有什么话要给人眼前一亮的感觉，我相信。
EDIT:The maximum file in our PHP tmp directory is 2.9 MB, so nothing that should make an impact, I believe.
更新：我从来没搞清楚什么是错误的和/或如何解决它，但问题就消失了，我们切换到的memcached / DB会话之后
UPDATE: I did never figure out what was wrong and/or how to fix it, but the problem disappeared after we switched over to memcached/db sessions.
推荐答案
您是否尝试过 session_write_close（）; ？
这将禁用在会话变量写能力，但你仍然可以从中读取数据。后来，当你需要编写一个会话变量，重新打开它。
Have you tried session_write_close(); ?This will disable write-ability in session variables but you can still read data from them. And later when you need to write a session variable, reopen it.
我也遇到这个问题，但是这个东西的工作就像一个魅力。这是我做的：
I have also suffered from this problem but this thing worked like a charm. This is what i do:
session_start(); //starts the session
$_SESSION['user']="Me";
session_write_close(); // close write capability
echo $_SESSION['user']; // you can still access it
这篇关于在session_start似乎非常慢（但仅有时）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！