我怎样才能防止大量的Apache进程产卵，当我启动Apache并继续杀死我的机器？
我有一个高度trafficked应用程序在一台debian机器和Apache已经开始performance奇怪。
每次启动apache时，都会产生大量的apache进程，应用程序根本无法加载，整个机器很快冻结，必须重新启动。
这是我刚刚开始Apache之后得到的顶部：
顶部 - 20:14:44上午1:16，2个用户，平均负载：0.48，0.10，0.03 任务：共330次，5次跑步，325次睡眠，0次停止，0次僵尸 Cpu：12.0％us，21.4％sy，0.0％ni，65.7％id，0.2％wa，0.1％hi，0.7％si，0.0％st Mem：总计8179920k，使用404984k，使用7774936k，使用60716k缓冲区 交换：总计2097136k，使用0k，2097136k免费，43424kcaching 10251 www-data 15 0 467m 8100 4016 S 6 0.1 0：00.04 apache2 10262 www-data 15 0 467m 8092 4012 S 6 0.1 0：00.05 apache2 10360 www-data 15 0 468m 8296 4016 S 6 0.1 0：00.05 apache2 10428 www-data 15 0 468m 8272 3992 S 6 0.1 0：00.05 apache2 10241 www-data 15 0 467m 8256 4012 S 4 0.1 0：00.03 apache2 10259 www-data 15 0 467m 8092 4012 S 4 0.1 0：00.04 apache2 10274 www-data 15 0 467m 8056 4012 S 4 0.1 0：00.03 apache2 10291 www-data 15 0 468m 8292 4012 S 4 0.1 0：00.03 apache2 10293 www-data 15 0 468m 8292 4012 S 4 0.1 0：00.03 apache2 10308 www-data 15 0 468m 8296 4016 S 4 0.1 0：00.02 apache2 10317 www-data 15 0 468m 8292 4012 S 4 0.1 0：00.02 apache2 10320 www-data 15 0 468m 8292 4012 S 4 0.1 0：00.04 apache2 10325 www-data 15 0 468m 8292 4012 S 4 0.1 0：00.04 apache2
等等..更多的apache2进程。
不到一分钟后，你可以看到下面的负载已经从0.48到2.17。 如果我不停止阿帕奇在这一点上，负载继续上升几分钟或更less，直到机器死亡。
顶部 - 20:15:34上午1:17，2个用户，平均负载：2.17，0.62，0.21 任务：总共1850，跑5，1845睡，0停，0僵尸 Cpu：0.3％us，2.1％sy，0.0％ni，96.4％id，0.0％wa，0.1％hi，1.0％si，0.0％st Mem：8179920k共计，1938524k使用，6241396k自由，60860k缓冲区 交换：总计2097136k，使用0k，2097136k免费，44196kcaching
我们有一个防火墙，我们将我们知道允许访问的地址列入我们的网站。
任何有关这个问题的想法都是非常受欢迎的。
谢谢！
你可能犯了configurationApache的错误，远远超过你所有的内存。 这是一个容易犯的错误。
我假设您正在使用Prefork Apache和一个进程内应用程序服务器（如PHP或mod_perl）。 在这个模型中，最终将使用最大（每个进程的MaxClients * max应用程序的最大内存使用量）内存。 如果你没有那么多，现在是时候减less一个，另一个或两个。
在一般情况下，这意味着将MaxClients减less到您的服务器有足够的内存来处理。
如果您使用的是Prefork模式（大多数应用程序服务器不支持或不鼓励使用），则通常用于MaxClients的默认值（典型值为150）不适合在适中机器上运行进程内重量级应用程序服务器线程模型）。
但是，减lessMaxClients最终会导致应用程序变得不可用，特别是当您保持活动并且保持活动超时时间过长时。 正在保持连接的进程（服务器状态下的状态K）仍然使用大量的RAM，这可能是一个问题 – 尽量减lesskeepalive超时，或完全closures它。
您需要关注服务器状态（由mod_status提供）。
当然，如果你明白其后果，你只应该做出任何这些改变。 仔细想想，一次更改configuration。 如果您有能力使用类似的非生产机器上的模拟负载来testing更改，请这样做。
使用ps -aux | grep apache找出apache运行的进程数。 注意“RSS”列，它给出了每个进程使用的内存估计值。 或者，您可以使用“top”，在这里您转换+ f，然后select％MEM列按内存使用情况对进程进行sorting。
进程数由apache.conf文件中的“MaxClients”指令决定。 你来到这个数字的方式如本页所述 ;
- 以root身份login到您的服务器。
- 运行顶部。
- 按shift + m。
- 请注意httpd使用的最高RES内存。
- 点击Q退出顶部。
- 执行：service httpd stop（在debian中，
sudo service apache2 stop） - 一旦httpd停止，执行：free -m
- 请注意“used”下列出的内存。
- 为您的VPS计划find有保证的内存。 支持可以告诉你有多less保证，如果你不能find它。
- 从您的计划保证的内存中减去使用的内存。 这会给你你的基础免费记忆池。
- 将你的FREE MEMORY POOL的值乘以0.8，find你的平均可用APACHE POOL（这将允许你在爆发期间保留20％的内存）。
- 将您的AVAILABLE APACHE POOL除以httpd使用的最高RES内存。 这将为您提供应该为您的系统设置的MaxClients值。 （如果它有一个分数组件，则将其舍入到小于此值的最近整数。）
“MaxClients”的正确值将确保您的apache服务器正确的内存分配。 这就是我解决这个问题的方法。
在Debian中，apache conf文件位于/etc/apache2/apache2.conf
你最近有没有改变你的configuration文件？ 如果是的话，我相信你保留旧版本的差异？
如果没有，请search“StartServers”，“MaxSpareServers”和“MinSpareServers”指令。 通常，您希望将这些设置保留为默认设置，但是由于configuration编辑错误，有可能将它们设置为高（坏主意）或意外设置。
如果这无济于事，那么现在是时候向Apache以外的地方看看，因为有些进程正在以一个快速的速度打开连接（可能是因为有一个testing过程被打乱了）。
第一步是访问日志。 第二步是运行netstat，查看连接可能来自哪里。 如果它运行在同一个系统上，你可以查看/ proc / * / fd来查找连接的两端。
如前所述（假设Prefork Apache） – MaxClients = max进程一次。
如果你发现你正在受到真正stream量的攻击（而不是错误configuration的StartServers / Min / MaxSpareServers），还有其他的一些你可以做的事情：
- 为您的静态内容设置一个单独的轻量级apache进程（或lighttpd）。 这样一来，所有小型，静态的东西都不会“污染”你的重量级应用程序。 这可以在同一台服务器上，也可以在不同的服务器上。 没关系。
- 把一个像Squid这样的反向代理放在你的Apache进程前面。 反向代理将迅速从Apache中抽取内容并将其存储在内存中，然后将其重新打包回客户端。 这样，14.4kb调制解调器上的AOL用户不会占用你的一个有价值的Apache插槽。 作为奖励，这样的设置可以configuration为caching一些内容，以减lessApache进程的负载。
你的'top'输出表明你有足够的可用内存，所以我不认为MaxClients是一个问题（除非Apache分配超过2GB的内存有问题吗？）如果你的错误日志是错误的有创造更多的孩子的问题。
很可能你的Apache进程真的在使用大量的资源。 如果您正在运行PHP应用程序，请尝试安装能够优化和cachingPHP代码的eAccelerator。 其他的事情可能包括严重的MySQL查询，缓慢的DNSparsing器等。除此之外，它更多地了解什么程序正在被打，他们在做什么。
这个问题是古老的，但我觉得不得不在这里增加一个答案，因为所有现有的答案都忽略了来自OP的关键信息：在负载开始上升几分钟后， top报告仍然有充足的CPU和内存资源可用。 通常还有一个罪魁祸首，那就是I / O。
用df -h检查是否有完整的分区。 如果不是，请查看您的应用程序是否使用vmstat 1 10或iostat 1 10 （这些由Debian / Ubuntu上的“sysstat”软件包提供）来颠簸磁盘。 如果您在那里仍然没有看到问题，则可能是networking装入存储的设备级I / O错误或networking问题。 检查系统和守护程序日志文件。
