我试过的事情：
>为根Apache进程调整oom_adj(以及所有子进程).这几乎没有效果.当Apache被重载时,它会使系统崩溃,因为系统在它杀死任何东西之前将所有其他内容分页.
>关闭交换.没有帮助,它将卸载内存分页到进程的二进制文件和/上的其他文件,从而产生相同的效果.
>将其置于内存限制的cgroup中(限制为512 MB RAM,占总数的1/4).这“工作”,至少在我自己的压力测试中 – 除了服务器在负载下不断崩溃(基本上停止所有其他进程,通过SSH无法访问等)
>以空闲I / O优先级运行它.这最终不是一个好主意,因为它只是导致系统负载无限期地(成千上万)几乎没有可见效果 – 直到你试图访问磁盘的无缓冲部分.这导致任务冻结. (那么好的I / O调度,嗯？)
>限制与Apache的并发连接数.将数量设置得太低会导致网站无法响应,因为大多数插槽都被长请求(文件下载)占用.
>我尝试了各种Apache MPM但没有取得多大成功(prefork,event,itk).
>从prefork / event php-cgi suPHP切换到itk mod_PHP.这改善了性能,但没有解决实际问题.
>切换I / O调度程序(cfq到截止时间).
只是强调这一点：我不关心Apache本身是否在负载下,我只是希望我的系统的其余部分保持稳定.当然,让Apache在短暂的密集加载后快速恢复将是很好的,但一步一步.
现在,我几乎都惊讶于人类如何在这个时代设计一个操作系统,在这个操作系统中,这样一个看似简单的任务(不允许一个系统组件崩溃整个系统)似乎几乎不可能 – 或者至少,非常难做.
请不要建议虚拟机或“购买更多RAM”之类的东西.
在朋友的帮助下收集了更多信息：
当调用cgroup oom killer时,进程挂起.这是呼叫追踪：
[<ffffffff8104b94b>] ? prepare_to_wait+0x70/0x7b [<ffffffff810a9c73>] mem_cgroup_handle_oom+0xdf/0x180 [<ffffffff810a9559>] ? memcg_oom_wake_function+0x0/0x6d [<ffffffff810aa041>] __mem_cgroup_try_charge+0x32d/0x478 [<ffffffff810aac67>] mem_cgroup_charge_common+0x48/0x73 [<ffffffff81081c98>] ? __lru_cache_add+0x60/0x62 [<ffffffff810aadc3>] mem_cgroup_newpage_charge+0x3b/0x4a [<ffffffff8108ec38>] handle_mm_fault+0x305/0x8cf [<ffffffff813c6276>] ? schedule+0x6ae/0x6fb [<ffffffff8101f568>] do_page_fault+0x214/0x22b [<ffffffff813c7e1f>] page_fault+0x1f/0x30
此时,apache内存cgroup几乎已死锁,并在系统调用中烧录cpu(所有内容都带有上述调用跟踪).这似乎是cgroup实现中的一个问题……
解决方法
这不是要阻止Apache关闭你的服务器,而是让你的网络服务器每秒提供更多的查询 – 足以让你没有问题.重新定义问题的答案的一部分是限制Apache,以便它不会在高负载下崩溃.
对于第二部分,Apache有一些限制你可以设置 – MaxClients是一个重要的配置.这限制了允许运行的孩子数量.如果您可以为Apache长时间运行的进程(例如下载大文件)加载,那么这是Apache中另一个能够为PHP提供服务的插槽.如果文件下载必须由PHP层验证,他们仍然可以这样做,并返回到更优化的网络服务器以获取静态内容,例如NginX sendfile
同时,在每一个请求中分配Apache,以最慢的方式运行PHP – 作为CGI(无论您使用的是什么apache MPM) – 也让机器花费大量时间不运行代码. mod_PHP显着更优化.
当Apache和PHP层得到适当优化时,PHP可以执行大量流量.例如,昨天,即2010年12月11日,我运行的那对PHP服务器在24小时内达到了近1900万次点击,其中大部分都是在早上7点到晚上8点的时间段内.
这里还有很多其他问题,以及其他关于优化Apache和PHP的文章,我认为你需要首先阅读它们,然后再归咎于Linux / Apache& PHP.
