这几天遇到了一个很多人都遇到过的问题,这个问题在google上有太多的人都遇到,但很少有指出最终的解决方案,大部分是解决了AcceptEx failed,但引起了内存的疯狂增加(“memory leak”)。这几天遇到这个问题后也费了不少功夫,但没有从网上找到最根本的解决办法,幸运的是,最终探索出了一个解决方案,在这里写出来,希望能帮助后来遇到问题的难友们尽早解决问题。
遇到的问题比较曲折,大体经过是:
某天,不能访问apache的页面,检查得知,apache在疯狂写日志,而且大部分是一句话:“winnt_accept: Asynchronous AcceptEx failed”,最多的时候写到了200M以上。经各方探索,最终在apache的手册上找到了一个解决方法:
在http.conf配置中设置Win32DisableAcceptEx参数。这样做的原因是,apache在某些Windows版本上可能兼容性不足,在调用AcceptEx接收请求时可能有问题,使用上面的参数禁用后,apache会使用另一套方案替代(BSD),这种方案效率稍微低些。详见:
http://httpd.apache.org/docs/2.0/mod/mpm_winnt.html#win32disableacceptex
当时修改完该设置后,重启apache,测试了一段时间,感觉原来的问题确实消除了,不过当时感觉内存占用量非常明显,但测试一段时间没有问题就放过去了,直到今天下午:
今天下午发现又不能访问页面了,然后检查apache发现它已经crash了。然后打开日志发现最后一句:“Out of memory!”--内存不足了。
然后对内存进行测试,发现一直按住F5键不停,apache的内存就不停上涨,似乎有一直吃光内存的意思,停止刷新后只能下降到500M左右了(刚启动时是20M)。如果不使用Win32DisableAcceptEx参数则明显没有这个问题,停止刷新后能回落到20M。看来是这个参数的原因。
于是从google上寻找答案,但可惜的是没有太多有价值的东西。只能看到apache的官方网站已经把这个问题列为了一个bug,甚至有些人又退回到不使用那个参数(忍受AcceptEx failed的风险?)。最后看到了一个说法,将ThreadsPerChild 设为170以下就可以,可为什么是170以下呢?作者没有很多描述。于是自己探索如下,使用一个简单的页面,不停的按住F5刷新:
如果将Threadsperchild 设为50,无论怎么刷新内存最多到150M左右,但不会再长了。停止刷新后,会降到55M左右;如果将ThreadsPerChild 设为100, 内存峰值:282M,能降到92M左右;如果将ThreadsPerChild设为550,内存峰值2G,停止后到500M左右……。
按照上述规律,基本上找到了问题的原因,因为我的配置中原来使用的是ThreadsPerChild 550,这样也就是内存很可能会长到2G以上(复杂页面比简单页面耗用量大),而机器的内存设置不能支持这么大,因此应该就是这个问题了。
所以最终的解决方法就是保留Win32DisableAcceptEx的同时修改了ThreadsPerChild 150。解决完成后我推测内存疯狂增长的原因:
首先,ThreadsPerChild的意思是系统启动时默认启动的等待线程数,用来等待处理客户的请求。在使用AcceptEx时内存增长不明显并且可以降回20M左右,可能是因为用户来了请求线程分配了一些资源,此时内存增长,但用户访问完成后,这些资源都释放了(这些资源很可能都和用户相关,没法留着下个用户使用,所以都释放了)。但禁用了AcceptEx后,由于apache每个线程需要处理网络事件,因此每个线程的资源需要就多了,并且处理完一个用户的请求后,有些资源不想释放,是可以对下个用户重用的,这样就留在了里面。由于我的线程数设了550(估计网上很多人遇到这个类似于“memory leak”问题的可能也都设的比较大或者机器虚拟内存较小),这样当线程较多时就会出现达到最大内存的情况,而且这种现象给人的感觉就是有内存泄漏,因为初始时是20M,来一个请求后线程分配一些资源(暂时不释放的),这样可能就变成了21M,如果同时有10个人访问,可能等他们访问完后就变成了50M,感觉是有内存泄漏。
这样也就解释了为什么有人说设到170以下就不再出现内存不足了,可能因为他的机器这个配置比较合适。不过知道了上述的规律和一些推测,这个结论应该是根据自己机器的情况合理调配。
我很少接触apache等linux上的东西,所知较少,只是遇到了问题才开始了解的上述信息,可能有很多的理解错误。如果能给别人一些帮助我会比较欣慰,如果误导甚至帮了倒忙,也希望能够理解!
如果在Win下使用Apache,而你又必须要开防火墙之类的软件,那么如果你的Apache运行有问题,比如文件下载不完全或者损坏、未知错误信息、防火墙冲突等等,请参考如下:
打开你的 httpd.conf 配置文件,看是否如下修改可以解决问题:
EnableSendfile Off
EnableMMAP Off
Win32DisableAcceptEx
转帖 (2):
【现象:】
访问apache静态的http内容,有时候比较慢,有时候“找不到网页”404错误;另外在error.log里也报错:[Mon May 26 10:11:47 2008] [warn] (OS 64)指定的网络名不再可用。 : winnt_accept: Asynchronous AcceptEx failed.
【原因:】
winnt(MPM) - Apache 2.2 参考手册有下列描述
Apache MPM winnt
说明 专门为Windows NT优化过的MPM 状态 MPM 模块名 mpm_winnt_module 源文件 mpm_winnt.c 概述
该多路处理模块(MPM)是Windows NT上的默认值。它使用一个单独的父进程产生一个单独的子进程,在这个子进程中轮流产生多个线程来处理请求。
Win32DisableAcceptEx 指令
说明 使用accept()代替AcceptEx()接受网络链接 语法 Win32DisableAcceptEx
默认值 AcceptEx()
是默认的,使用这个指令将禁用它。作用域 server config 状态 MPM 模块 mpm_winnt 兼容性 仅在 Apache 2.0.49 及以后的版本中可用
AcceptEx()
是一个微软的WinSock2 API ,通过使用BSD风格的accept()
API提供了性能改善。一些流行的Windows产品,比如防病毒软件或虚拟专用网络软件,会干扰AcceptEx()
的正确操作。如果你遇到类似于如下的错误:
[error] (730038)An operation was attempted on something that is not a socket.: winnt_accept: AcceptEx failed. Attempting to recover.
你就需要使用这个指令来禁止使用
AcceptEx()
。
【解决办法:】
问题一、在httpd.conf文件中添加 Win32DisableAcceptEx 标记,如下:
ThreadsPerChild 150
MaxRequestsPerChild 10000
Win32DisableAcceptEx
这样可以允许并发连接更大一些。同时性能上也不会有明显的降低。
如果Apache的error.log还是出现大量的:Sat Dec 24 17:21:28 2006] [warn] (OS 64)指定的网络名不再可用。 : winnt_accept: Asynchronous AcceptEx failed。可以参考下列配置:
1、网上邻居->本地连接->属性->internet协议(TCP/IP)->属性->高级->wins标签->去掉启用LMhosts查询前的勾.
2、控制面版->windows防火墙->高级标签->本地连接设置->服务的标签里勾选安全Web服务器(HTTPS)。
3、然后退出Apache,再打开启动就可以了 ,一开始我没有退出,直接在那重启,就是不可以,一定要先停止,在开启即可
转帖 (3):
[warn] (OS 64)指定的网络名不再可用。 : winnt_accept: Asynchronous AcceptEx failed.
以前也看到,但忽略了。这回不能再放过她了。
看了几篇(winnt(MPM) - Apache 2.2 中文版参考手册),说是因为一些流行的视窗系统产品,比如防病毒软件或虚拟专用网络软件,会干扰
AcceptEx()
的正确操作。于是在apache设置文件中添加如下语句:
ThreadsPerChild 1000
MaxRequestsPerChild 10000
Win32DisableAcceptEx停止Apache,再启动。确实新设置起作用了:
[notice] Disabled use of AcceptEx() WinSock2 API
[notice] mod_python: Creating 8 session mutexes based on 0 max processes and 1000 max threads.
[notice] Child 2380: Child process is running
[notice] Child 2380: Acquired the start mutex.
[notice] Child 2380: Starting 1000 worker threads.okay,似乎错误不再来了。