服务器 Gind.cn
  1. 服务器 Gind.cn
  3. WordPress（nginxcaching+ Apache + fcgid）挂钩所有8个CPU
Intereting Posts
Exchange Web服务器exception：“连接失败。 稍后再试。” Linux目录移动 在其他AWS实例上无法到达munin端口 为SQL Server启用AWE Apache安全configuration – Ubuntu 12 如何启用与iptables的Windows共享？ 通过外部方式断开与TCP服务器的连接 如何防止nginx从反向代理特定的子目录 Domino始终服务器在第一次尝试时无法发送SMTP电子邮件 IP KVM切换器，还是用于远程pipe理的串行控制台盒？ Windows客户端PowerShell报告 SQL Server访问日志 请求证书在其他站点失败 nginx try_files混淆 客户端邮件归档

WordPress（nginxcaching+ Apache + fcgid）挂钩所有8个CPU

我有一个WordPress多用户网站，以90％以上的使用率embedded我的所有CPU： 

top - 12:02:58 up 55 days, 5:25, 10 users, load average: 20.51, 15.66, 14.90 Tasks: 294 total, 24 running, 270 sleeping, 0 stopped, 0 zombie Cpu0 : 87.5%us, 8.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 4.5%si, 0.0%st Cpu1 : 97.9%us, 1.9%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu2 : 96.0%us, 3.5%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.5%si, 0.0%st Cpu3 : 97.6%us, 2.1%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu4 : 97.1%us, 2.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu5 : 97.9%us, 1.9%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu6 : 97.9%us, 1.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.5%si, 0.0%st Cpu7 : 96.0%us, 3.5%sy, 0.0%ni, 0.3%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 14369424k total, 11903548k used, 2465876k free, 402360k buffers Swap: 4063200k total, 3594784k used, 468416k free, 1484116k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30658 apache 16 0 274m 97m 6304 R 62.1 0.7 0:12.49 php-cgi 30686 apache 16 0 213m 92m 6040 R 52.2 0.7 0:03.27 php-cgi 30685 apache 15 0 211m 87m 5764 S 50.3 0.6 0:04.50 php-cgi 28217 apache 16 0 529m 405m 6748 S 49.0 2.9 3:54.72 php-cgi 30468 apache 16 0 414m 291m 6452 R 48.5 2.1 0:49.78 php-cgi 29604 apache 15 0 258m 135m 6464 S 47.4 1.0 2:16.22 php-cgi 28308 apache 16 0 584m 408m 6724 R 43.9 2.9 3:43.07 php-cgi 28266 apache 16 0 550m 374m 6728 R 43.7 2.7 3:58.38 php-cgi 29573 apache 16 0 584m 407m 6592 R 36.8 2.9 1:59.88 php-cgi 30470 apache 16 0 219m 95m 6452 S 36.5 0.7 0:39.66 php-cgi 29138 apache 15 0 513m 334m 6528 S 33.6 2.4 2:03.14 php-cgi 30472 apache 17 0 441m 318m 6272 R 31.7 2.3 0:50.45 php-cgi 28283 apache 16 0 414m 291m 6580 R 29.3 2.1 3:53.06 php-cgi 29858 apache 16 0 251m 127m 6628 R 24.8 0.9 1:15.53 php-cgi 28253 apache 18 0 550m 374m 6580 R 24.5 2.7 4:08.05 php-cgi 30666 apache 15 0 217m 94m 5996 R 24.5 0.7 0:04.68 php-cgi 28208 apache 20 0 584m 407m 6436 R 24.2 2.9 4:36.36 php-cgi 29085 apache 25 0 358m 182m 6488 R 22.6 1.3 2:19.76 php-cgi 28258 apache 25 0 530m 407m 6512 R 22.4 2.9 3:58.70 php-cgi 29574 apache 16 0 530m 406m 6540 S 21.6 2.9 2:19.26 php-cgi 28947 apache 16 0 524m 401m 6476 R 14.1 2.9 2:32.33 php-cgi 28238 apache 15 0 488m 312m 6852 S 12.3 2.2 4:24.34 php-cgi 30464 apache 15 0 274m 151m 6176 R 11.2 1.1 0:19.67 php-cgi 28293 apache 16 0 269m 146m 6460 R 9.9 1.0 3:57.17 php-cgi 28205 apache 25 0 530m 407m 6496 R 9.6 2.9 4:05.49 php-cgi 30471 apache 19 0 263m 140m 6440 R 6.9 1.0 0:47.42 php-cgi

输出结果显示，单个进程使用的CPU最多占60％，但是有些时候我使用了超过90％cpu的多达7个进程。

该网站运行如下：

  1. nginx作为一个反向代理，为每一个可以通过proxy_cache指令caching页面的静态文件提供服务。

  2. 当需要PHP脚本时，它委托给Apache。 这些通过使用ExecCGI选项的mod_cgi运行

  3. Apache和nginx都对每个可读文件进行压缩

  4. 为了避免一直触发MySQL，我们将HTML片段保存在memcached中，目前caching在2到4MB之间，正如telnet连接中的stats命令所报告的

  5. Redis数据库中还有一些计数器，主要是为每个post计算页面浏览量。

  6. 没有WP超级caching（nginx做caching），没有XCache。

我不知道如何确定每个php-cgi进程需要如此高的CPU需求 – 在我们开始维护之前，这个站点已经被几个不同的软件团队大量修改了。

PHP错误日志主要显示这些错误：

  1. “无法重新声明类FacebookRestClientException”
  2. “调用未定义函数e_（）”
  3. 无效的SQL语法，主要在这里：“WHERE post_id = xxxxx AND blog_id =”
  4. “允许内存大小268,435,456字节耗尽”
  5. “调用未定义的方法Services_JSON :: encodeUnsafe（）”

这些实际上没有执行任何计算，所以他们不能成为CPU问题的来源。

我试图跟踪系统调用，看到lstat，读取，写入和访问，这将产生等待，而不是CPU负载是他们的问题（正确？）。 此外，还有调查和select。

有人能指点下一步要检查什么吗？

你的问题在这里：

没有WP超级caching（nginx做caching），没有XCache。

安装APC Zend OPcache和W3总caching，并观察你的CPU使用率下降到几乎没有。

APC Zend OPcache单独应该给你一些喘息的空间。

请注意，W3 Total Cache不是完全支持多站点的，因此必须在每个站点上单独configuration。 它可以设置为使用现有的memcached进行caching。

你也可以摆脱Apache。 这对你来说绝对没有什么。

（注意：APC已被弃用，在实践中被certificate是不可靠的，我现在推荐使用Zend的OPcache）。

从你看到的其他错误来看，如果没有一些潜伏的代码潜伏着，代码审查将是解决问题的最好方法，这将是非常令人惊讶的。 

 Cannot redeclare class FacebookRestClientException

我们知道这个类是成功加载的，所以我首先找出脚本正在调用哪个外部API，它们是否失败，以及它们在运行（或运行失败）时绑定了多长时间 – 一个认真对待外部API的呼叫（或一系列呼叫）可能是负责任的。

内存caching肯定会有所帮助，特别是对于WordPress的内部对象caching。 正如Michael所说的，W3 Total Cache并不是完全支持多站点的，它相当全面/复杂/繁重，所以我推荐一个更纯净，更简单的select，它与wordpress.com上的设置非常相似： APC Object Cache比单个服务器的memcached更快），对象caching和Batcache进行整页内存caching。 请注意每个的安装说明，它们与标准插件不同。

很显然，如果你还没有安装APC，你需要安装APC，并且适当调整它。 例如，stat = 0会显着加快速度，但是如果你设置了这个，那么当任何PHP文件改变时（例如在插件和wordpress核心升级时），你都需要重新启动你的PHP procs。 确保你安装了apc.php面板（根据你的操作系统的包，你可能需要从APC源代码包中获得），这对于debugging和debugging非常有用。 （locking/密码保护，介意。）

或者，因为已经安装了memcached，所以有Memcached Redux插件，它提供与APC对象caching相同的function。 这可能是更容易的路线。

您可能无法从Batcache中获得大量的好处，因为您已经使用nginx来实现基于文件的proxy_cache，但是如果您有一些空余的内存，并且可以通过弥合文件caching之间的差距并直接打Apache，所以这是值得一试。

看你的观点3.我强烈build议禁用Apache和PHP中的gzip，即禁用mod_deflate，并在php.ini中更改zlib.output_compression = Off 。 Nginx是你的前端，因此无论如何都会为你做压缩，所以不需要做两次–nginx可能会更快，更高效地完成压缩，它将保存你的Apache / PHP进程的CPU。

有多less个插件被激活？ 他们都是必不可less的？ 你可以逐个禁用它们，看看每个有什么不同吗？ 我看到一些严重编码的插件彻底瘫痪了网站，所以如果可以的话，请审核这些插件。

您提到该网站已经被几个不同的软件团队大量修改过。 有没有任何版本控制，所以你可以看到已经做了什么改变？ 他们是直接的核心，主题还是插件？ 如果他们的核心，你可以分歧的东西得到一个更好的图片，或者是太大的改变？ 向前走，重构从核心到网站的主题functions.php和离散插件的变化可能会让你的生活更容易，如果你能做到这一点。