@Tuisku
别浪费青春，要是能力没问题赶紧跑。
这地方就是燃烧热情，然后啥都得不到。
（钱够了另说）

我们公司也是 FTP 传代码，但至少每个人都有账号。
其他人别瞎掰 GIT\SVN 之类的，我们根本没有额外的服务器做这件事。
测试服务器都没，别给我说在生产环境搭个 SVN ，那服务器环境我们得向运维申请。
也别给我说运维部署，我们的运维只管开机、关机、重启，走流程装程序（装他们认为可以装的程序）
（因为运维根本不是我们公司，原则上他们是空间商一样的存在）

至于备份、调试、 review ？
每周手工备份全站文件到自己带的笔记本上面（没看错，咱们连硬盘都不够）
调试全靠生产环境（删错了咋办？我们数据库每天都有备份）

认吧，这类公司只能离职了。

楼上说生产测试分离，看来是没被这类公司的架构虐过。。（无论软件、硬件、人事）
另外搭一个环境这个说法估计也是没体会过 10 年以上老代码服务器环境强耦合的情况。

放心，题主要个 FTP 权限并不会多承担什么责任，毕竟。。。即便没权限，出问题还是题主背锅。
所以做好备份放心去干，不给权限。。。。。逃吧
(就那么几个技术还不搞短平快的开发模式脑袋抽了么？！)

接上：
其实这算是我的锅，一开始我就要了个账户就去挖信息了。
脚本路径不明其实是我自己不明而已，题主还是知道的
中途并不肯定我看到的文件是否就是调用的那个，这得确认一遍。
毕竟 @lairdnote 在我之前已经折腾过一次了，给题主的结论是 MySQL 的锅。
但题主也没给我细节，所以我又从头折腾了一次。。

（说实在的题主在问问题的时候给出的信息也是少得可以）

@xuboying
一键脚本搞出来的环境

@demo
的确就是看文档去了
然后时间就耗在查找，对比，修改上面了。。。

不得不说真心累，特别是在网络不给力的时候

@demo
一开始就用了，得到了类似这样的输出

Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf

一个个找下去，就差最后一个~/.my.cnf （在 root 的 home 目录找到）
但是 MySQL 的配置文件与实际的选项相比极度缩略，又花了点时间去找一个样本。。

@demo
事实上 mysql 的配置文件调用是有优先级顺序的，在一个限定的位置中顺序查找
whereis 是针对特殊文件的，例如可执行文件。
对于 my.cnf 这个配置文件，正确的选择是用 find

虽然没领到。。但是。。开心就好。。

其实那个凌晨崩溃问题还没找到。。
日志是 out of memory, 但是平常访问理应不会出现这种情况。
这个坑就留着重做系统看有没有改善吧。。
遇上没法解决的系统问题，最简单懒惰的做法就是重配。。。

论环境整洁的重要性

@Infernalzero
这回是 WP 的锅，大概。。。囧
不得不说这个帖子开头的那个日志非常具有误导性(大概)。
事实情况是两个连接都没问题，查询堵了。
（最终因为查询问题没解决开头这个问题没法排）

内存占用高有可能是缓存的原因，而且 PHP 获取的缓存并不等于实际使用量。
所以一开始没从查询方面的问题来考虑。

所以最大的锅还是：说好的缓存呢？

估计列表里面不会有腾讯管家

设备多只要条件允许就用多点多频段覆盖
别忘了无线网络是共享信道，各个客户端在上行的时候需要冲突避免，下行的时候就靠广播

@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 压力测试
别的不知道，至少知道一件事：你的数据库配置有问题