打开 APC 时出现会话问题
当我们的服务器上启用 APC 时，我们遇到 PHP 会话问题。
该应用程序在没有 APC 的情况下也能正常工作。然而，由于我们启用了 APC，当服务器负载过重时，会话似乎会变得混乱，即用户随机以另一个身份登录。一旦我们禁用 APC，一切都会恢复正常。我们似乎找不到任何有同样问题的人，除了这些人的相关问题（set-cookie 被缓存在 MS ASP 中）： http://msdn.microsoft.com/en-us/magazine/cc163577.aspx#S2
还有人有类似的经历吗？你能推荐一些建议吗？
PS：我们所有的会话都由 php.ini 中的文件处理。我们还运行 apache2。
We have a problem with PHP session when APC is enabled on our server.
The app works great without APC. However, since we enabled APC, the sessions seems to be getting mixed up when the server experiences heavy load, i.e. users are randomly logging on as another. Everything reverts back to normal once we disabled APC. We can't seem to find anyone with the same problem, except a related problem with these guys (set-cookie was being cached in MS ASP): http://msdn.microsoft.com/en-us/magazine/cc163577.aspx#S2
Anyone else has similar experience? Can you recommend any suggestions?
PS: We have all our sessions handled by files in php.ini. We are also running apache2.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我们这里也有类似的问题。 APC 目前只是主要嫌疑人，因为它很难重现。
我们使用带有会话管理的 Zend Framework，其理论是 Zend 的代码缓存在 APC 中，当系统负载严重时，代码将使用之前缓存的 SID，而不是当前的 SID。
我们的保护措施是将会话 ID 保存在会话数据中，并在检索会话时比较这些值。如果 ID 不同，我们将销毁会话并退出。
We're having a similar issue here. APC is only a primary suspect at this point because it's been difficult to reproduce.
We're using Zend Framework w/ session management and the theory is that Zend's code is cached in APC and when the system is under severe load the code is using a previously cached SID instead of the current one.
Our safeguard is to save the session ID inside the session data and compare the values when the session is retrieved. If the IDs are different we destroy the session and exit.
好吧，请验证 apc 是否真的混淆了数据......
我能想到的唯一可能发生的情况是当它变满并发生堆栈溢出时。
请检查使用情况并可能增加缓存大小。
well please verify that apc really mixes up data...
the only possible i can think of when this could happen is when it gets full and does a stackoverflow.
please check the usage and maby increase the cache size.
APC 会出现一个问题，即自定义会话处理对象在保存会话数据之前就被销毁了。它可能与您的问题无关，但在常规 PHP 关闭之前显式调用
session_write_close可以修复该问题。虽然您的问题听起来有点不同，但我可以确认问题确实存在。
There is a problem that crops up with APC where custom session handling objects get destroyed before the session data is saved. It could be unrelated to your problem, but an explicit call to
session_write_closebefore the regular PHP shutdown fixes that one.Your problem sounds a bit different though, but I can confirm that issues do exist.
为了完成这篇文章，我们通过三件事成功地减少了这个问题：
1）我们进行了额外的检查以确保 IP 与会话 ID 匹配，否则注销用户。然后我们可以用它来跟踪问题发生的频率。
2) 我们切换到 XCache 并立即发现混淆会话 ID 的数量减少了。然而，在非常重的负载下，问题再次出现。
3) 然后我们在 php 配置中将 Xcache 的内存加倍（xcache.size 和 xcache.var_size），现在问题就消失了。
因此我们怀疑 APC 或 Xcache 内存不足是问题所在。我们仍在等待，看看这是否是一个永久的解决方案。
Just to complete the post, we had success in reducing this problem with three things:
1) We made extra checks to make sure that the IP is matched to the session ID, and logout the user otherwise. We could then use this to track how often the problem occurs.
2) We switched to XCache and immediately saw lower number of confused session IDs. However, under very heavy load the problem rears its ugly head again.
3) We then double the memory for Xcache in the php config (xcache.size and xcache.var_size) and now the problem is gone.
So we suspect either APC or Xcache running out of memory was the problem. We're still waiting to see if this is a permanent solution.