@mengzhuo
对 WP 不熟，题主的确是自己写 SQL 了，他说自己写的有 memcache 缓存，别的都没。
依据题主的说法为了练习 memcache ，没用 WP 的自带缓存功能。
（曾想进入后台确认插件配置情况，无账号，无解）

WP 自身的索引在那个页面看过，并不完全，所以第一时间加上了，但是改善不明显。
调用次数太多，没细调。即便有缓存也可以保证没触发。
单表数据较多， 700 多条数据做 INNER JOIN, 后面 WHERE 的时候还有两个 IN 上 10 个 id 的参数。。
ORDER BY t.name ，也算是性能巨坑。

磁盘是 SSD ，应该能抗住，但是双核 CPU 已跪

补充一下 其实在看到 ALTER 的时候还有一段时间的源码排查，原因是这个类似的代码我只能在
/wp-admin/includes/upgrade.php 里面找到，这个文件按理说不会调用到才对。
分析调用链耗费大量的时间，最终只能询问题主是否有见过类似的东西或者做过类似的操作。。。

论架构熟悉的重要性
论排查事项优先级对效率的影响
论 BUG 的 XX 程度对排查时间的影响
。。。。。

事实情况是楼主在模板里面调用了这个文件
至于功能。。没细看

给大家说说昨天的排查过程吧，因为干扰源存在，问题未最终解决。

开头时候服务器环境的不熟悉浪费大量时间。。
找配置文件，塞个 htop ，塞个 iftop ，因为 CentOS 仅仅在内网用过（无外网访问权限），傻乎乎的就去找包了，结果 CentOS 7 ，半天没找着，最后 yum 发现都能用

翻查 mysql 的实际调用配置文件位置浪费了不少时间。。

======================================

刚开始看在本页页头的日志文件，感觉应该是 PHP-FPM/MySQL 阻塞 /挂掉，所以从这个地方入手。
先把看起来有问题的性能参数都给改了， MySQL 的查询缓存开大点。（ 4G 内存，大着呢）
压测发现 PHP-FPM 稳定承受所有请求， CPU 占用率未有明显异常，无错误报告。
但同时 MySQL CPU 占用跑满，遂排查。。

首先把 MySQL 的慢查询开了，超时 1 秒，记录日志
压测 50 线程，力求打满。。。然并卵，机器的带宽就 4M ，折算下来理论 512KB/S
（事实上跑了 3M 的带宽，结果还是个位数的每秒响应）
MySQL 占用继续跑满，但是慢查询没任何异常（未有任何一条数据输出）。
多次测试情况一致。。。页面几乎无反应（ 20 秒+）

压测过程中 show processlist; 命令查看当前 SQL 字串，存在大量查询正在 Creating sort index.
"SELECT t.*, tt.*, tr.object_id FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id ........."
（说好的缓存呢？）

翻查数据库，数据是分类类目、 tag 之类的东西
遂翻查代码，首页大量调用 get_post_meta / get_the_category, 对 WP 不熟，但至少反查上去这两个嫌疑最大，结合上面那条 SQL 提到的那些表的数据，看上去，似乎，首页的大部分文章，都调用了一次。。。

传说中的 97 次 SQL ？

这个算是其一，另外在 show processlist;过程中存在大量的 ALERT TABLE 请求。。。
逻辑告诉我，大概是楼主在导数据吧。。。

。。。。。
。。。。
。。。
。。
。


但是在多次压测的时候我还能看到这东西。。。囧
复制一行，问楼主：
"ALTER TABLE vp_msg CHANGE COLUMN Status Status TINYINT NOT NULL"
"长这样的 mysql 语句你有印象么"

"我知道，这是我自己创建的数据表"
"这句有问题吗"

"...为啥我每次访问首页都能看到这行东西 囧"

..............

屏蔽过后，压测稳定了，至少能稳稳当当的在我可接受的时间内跑完全程，并发 10 （但依旧占用 100%）
在那堆查询问题解决之前，无法进入下一步排查，算是干扰源。

以上就是昨日下午排查的结果。

@hoythan
把 QQ 加上再说。。囧

@murusu
p.php 是他自己的探针

@hoythan
其实，要是你愿意放多点信息，估计很多人无偿都愿意给你搞。。囧

其实现在思路感觉挺明确的：
首先，排查 PHP-FPM 问题，在运行过程中 HTOP 查看是否进程数过多造成瓶颈(处理完了没释放)。
接着，排查 MYSQL 的连接问题，看多连接并发是否会阻塞或者断掉。

这两点先行排查。
不管有没有问题把过程放出来。
这样至少能知道你现在的排查状态，也能在提问中体现出自身的努力。

建议：
1 、检查 PHP-FPM 配置
2 、检查 MySQL 配置

具体项目都是子进程连接数等并发处理能力相关的部分。
刚刚的某几个无法访问是我用 ab 压出来的， 10 个并发挂掉（响应速度不到 10 个）
测试目标地址就是首页

@hoythan
结合错误日志， ab 压力测试
别的不知道，至少知道一件事：你的数据库配置有问题

@abscon
说实在的，无论一二，现在的问题是对于外界而言信息不足。想帮都没法帮。。。

现在等待时间 500-600ms 还算正常

@hoythan
那么现在的问题是：
环境反应没问题，探针加载极其迅速，但是应用上线以后在一段时间过后会出现等待时间极长的问题。

这样？

我觉得你直接找个人给你排查还更快一些。。
或者自己尝试把应用搬到别的机器进行测试。。

别买青轴！别买青轴！别买青轴！
重要的事情说三次。。。

原因：太重，需要几乎触底触发，推荐红轴
补充：现用 Cherry G80 青轴

1. 精通 Linux 下的 PHP/C/C++开发；
2. 熟悉 Mysql 数据库，熟悉 redis 、 mogondb 等 NoSQL 技术；
3. 熟悉 TCP/IP 、 HTTP 等网络协议；
4. 具备大容量、高性能系统设计能力；
5. 对开发工作富有激情，保持开放好学的心态；

自我评价：
1 、 PHP 个人使用了 10 年（包括在校），暂未写过扩展（没需求）， C/C++ 只写过小功能，算不上精通。
语言技能（按熟练程度由|分割） PHP 、 Python 、 HTML 、 CSS 、 JS 、 SQL| C# | JAVA | C | C++

2 、数据库经常使用， B-Tree 原理熟悉一二，但调优依靠工具报告
（至少列表中的都用过，各个数据库的适应场景也是熟悉的）

3 、 TCP 能写出整个协议栈（包括拥塞控制算法）基于 Python ， HTTP 严格需求下状态码需要查表。

4 、如果有实际需求，可以从底层的硬件配置网络架构开始分析。（但没有实际系统的经验）
（因缺少实际的数据经验支持，即便是分析也仅仅是定个方向，具体选型必须测试）


（附：有企业级网络设备的配置经验 [在校期间的竞赛经验] ）


学历：专科
请问能投简历吗？

@lecher
文件同步开销并不小

采到是啥就发啥，注意 TCP 的拥塞问题， UDP 的丢包问题。在某些状态下二者都不靠谱，每次新建连接的开销务必考虑，缓存队列务必考虑超时问题。

原则是：不给应用服务器增加负担.

至于处理系统，原始数据先记录，分析处理开另一个任务处理。
用处理时间换日志完整性.

楼主，别告诉我你选的是阿里云 1M 带宽的机器，下载极其缓慢。。。
另外，一开始的 WAIT 特别长，需要排除可以试试放个静态页看看问题出在哪。排查看看哪个地方有问题。

才 3 台虚拟机，开个 Win7 装个 VMware Workstation 都行。

负责任的说一句， ESXI 是所有底层虚拟化平台里面最简单易用的平台。
安装麻烦只是因为硬件不兼容问题占多数
这点在 HP 的服务器上没任何问题，因为 HP 就提供官方的 ESXI ISO 可供安装。

在这其中最重要的一点：易用

至于其他那些， KVM 没好用的面板。
XenServer 调用 ISO 的方式极其坑爹
（需要网络远程读取，仅支持 NFS 或者 CIFS, 可能是我使用的方式不对）
至于 Docker ， Docker 的设计初衷是容器，不是虚拟机。
（有虚拟机需求不如使用 OpenVZ 更加合适）

@n37r06u3 慢性病的康复时间以年计算。。。