Windows iis 7.0 上的 APC 不稳定
我的 IIS 非常不稳定,因为它总是由于某种与 APC 相关的原因而重新启动。
服务器的规格低于
Intel R Xeon CPU 3GHZ 3GHZ
2GB RAM
64bit
APC &服务器规范
3.1.7-dev
PHP Version 5.3.6
APC Host localhost
Server Software Microsoft-IIS/7.5
Shared Memory 1 Segment(s) with 1024.0 MBytes
(IPC shared memory, File Locks locking)
extension=php_apc.dll
apc.shm_size=1024M
apc.num_files_hint=10000
apc.user_entries_hint=10000
apc.max_file_size=5M
PHP LOG 文件出错
28-Jul-2011 09:23:14] PHP Fatal error: Unknown: apc_fcntl_lock failed errno:6 in Unknown on line 0
[28-Jul-2011 09:23:14] PHP Fatal error: Unknown: apc_fcntl_lock failed errno:6 in Unknown on line 0
[28-Jul-2011 09:24:23] PHP Notice: Undefined index: SERVER_ADDR in C:\inetpub\wwwroot\apc.php on line 68
[28-Jul-2011 09:24:24] PHP Notice: Undefined index: SERVER_ADDR in C:\inetpub\wwwroot\apc.php on line 68
[28-Jul-2011 09:24:24] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for '8.0/no DST' instead in C:\inetpub\wwwroot\apc.php on line 1122
[28-Jul-2011 09:24:24] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for '8.0/no DST' instead in C:\inetpub\wwwroot\apc.php on line 1123
[28-Jul-2011 09:24:24] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for '8.0/no DST' instead in C:\inetpub\wwwroot\apc.php on line 1124
[28-Jul-2011 09:24:30] PHP Notice: Undefined index: SERVER_ADDR in C:\inetpub\wwwroot\apc.php on line 68
[28-Jul-2011 09:24:30]
我无法弄清楚导致 IIS 重新启动的错误或导致 apc_fcntl_lock failed errno:6 的错误。 我的项目存储了高达 1gb 的缓存数据,因此解释了 shm 设置为 1024M
另外,当我在浏览器上重新加载 apc.php 页面时,问题似乎更频繁地发生 HTTP 错误 500.0 - 内部服务器错误 C:\PHP\php-cgi.exe - FastCGI 进程意外退出
我的缓存被重置,我必须再次重新缓存我的数据。
它在我的 LINUX 服务器上运行良好。我的 APC 配置有问题吗?
I've very unstable IIS, as it always get restarted for some reason it is APC related.
The specs of the server is below
Intel R Xeon CPU 3GHZ 3GHZ
2GB RAM
64bit
APC & Server specification
3.1.7-dev
PHP Version 5.3.6
APC Host localhost
Server Software Microsoft-IIS/7.5
Shared Memory 1 Segment(s) with 1024.0 MBytes
(IPC shared memory, File Locks locking)
extension=php_apc.dll
apc.shm_size=1024M
apc.num_files_hint=10000
apc.user_entries_hint=10000
apc.max_file_size=5M
PHP LOG File On Error
28-Jul-2011 09:23:14] PHP Fatal error: Unknown: apc_fcntl_lock failed errno:6 in Unknown on line 0
[28-Jul-2011 09:23:14] PHP Fatal error: Unknown: apc_fcntl_lock failed errno:6 in Unknown on line 0
[28-Jul-2011 09:24:23] PHP Notice: Undefined index: SERVER_ADDR in C:\inetpub\wwwroot\apc.php on line 68
[28-Jul-2011 09:24:24] PHP Notice: Undefined index: SERVER_ADDR in C:\inetpub\wwwroot\apc.php on line 68
[28-Jul-2011 09:24:24] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for '8.0/no DST' instead in C:\inetpub\wwwroot\apc.php on line 1122
[28-Jul-2011 09:24:24] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for '8.0/no DST' instead in C:\inetpub\wwwroot\apc.php on line 1123
[28-Jul-2011 09:24:24] PHP Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for '8.0/no DST' instead in C:\inetpub\wwwroot\apc.php on line 1124
[28-Jul-2011 09:24:30] PHP Notice: Undefined index: SERVER_ADDR in C:\inetpub\wwwroot\apc.php on line 68
[28-Jul-2011 09:24:30]
I cannot figure out what's the error that is causing IIS to restart or what is causing apc_fcntl_lock failed errno:6 .
My project stores up to 1gb cache data and hence explains the shm set at 1024M
Also problem seems to happen more often when i reload apc.php page on browser
HTTP Error 500.0 - Internal Server Error
C:\PHP\php-cgi.exe - The FastCGI process exited unexpectedly
My cache gets reset and i've to re-cached my data again.
It works fine with my LINUX Server. Is is something wrong with my APC configuration or such?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我认为这不是 APC 配置本身的问题,而更可能是 Windows 上处理文件锁定的方式有问题。我在APC源代码中查找了apc_fcntl_lock,它非常简单,并且已经好几个月没有改变了。
如果您只运行一个工作进程,您可以尝试设置 apc.write_lock = 0 并查看是否有帮助。
否则,您可以尝试旧版本的 PHP(或 5.3.7RC3),以防问题出在 APC 与 PHP 交互的方式上(尽管可能性不大)。
最后,如果这不起作用,也许可以尝试不同的操作码缓存;例如 xcache。
I don't think it's a problem with your APC configuration per se, but more likely a problem with the way that file locking is handled on Windows. I looked up the apc_fcntl_lock in the APC source code, and it's pretty straightforward and hasn't been changed for months.
If you're only running one worker process, you might try setting apc.write_lock = 0 and see if that helps.
Otherwise, you might try an older version of PHP (or either 5.3.7RC3) in case the problem is with the way APC is interacting with PHP (probably unlikely, though).
Finally, if that doesn't work, maybe try a different opcode cache; xcache for instance.