帮我看下这些日志吧好心人

2016-03-08 10:10:41 +08:00
 hoythan
我是昨天发帖子说:救命,我可能要被老板砍死了。的那位。我经过一天的尝试,基本已经刨除了带宽的问题。因为现在网站的图片内容都已经在云上依旧是会卡的。
而且在深夜 3 点也会死机。我今天拿出了服务器的日志文件,求大家帮我看看 。跪谢了

服务器环境是 php7 和 mysql5.7 4GB 4MB 独立带宽的阿里云 4 核服务器。

另外我发誓一分积分没赚,不论是吐槽还是帮忙的所有人我都点了感谢。跪谢跪谢,不然就真的死了。已经被点名批评。

http://pan.baidu.com/s/1qXrUhGg

yr6t
14784 次点击
所在节点    Linux
109 条回复
mhycy
2016-03-09 10:20:41 +08:00
补充一下 其实在看到 ALTER 的时候还有一段时间的源码排查,原因是这个类似的代码我只能在
/wp-admin/includes/upgrade.php 里面找到,这个文件按理说不会调用到才对。
分析调用链耗费大量的时间,最终只能询问题主是否有见过类似的东西或者做过类似的操作。。。

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

事实情况是楼主在模板里面调用了这个文件
至于功能。。没细看
mhycy
2016-03-09 10:25:59 +08:00
@mengzhuo
对 WP 不熟,题主的确是自己写 SQL 了,他说自己写的有 memcache 缓存,别的都没。
依据题主的说法为了练习 memcache ,没用 WP 的自带缓存功能。
(曾想进入后台确认插件配置情况,无账号,无解)

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

磁盘是 SSD ,应该能抗住,但是双核 CPU 已跪
Infernalzero
2016-03-09 10:37:37 +08:00
看了 LS 的回复,看来原因和前天 LZ 刚发帖是我的猜测几乎一致
内存吃了那么多, 8 成是因为自己写了比较坑的 sql 然后又没有合适的索引导致 file sort
大多数把网站搞跪都是存储层出现了问题,虽然 po 主没有对静态资源进行优化,但那也仅仅是某些时刻访问慢些,更何况带宽还没吃光
mhycy
2016-03-09 10:49:56 +08:00
@Infernalzero
这回是 WP 的锅,大概。。。囧
不得不说这个帖子开头的那个日志非常具有误导性(大概)。
事实情况是两个连接都没问题,查询堵了。
(最终因为查询问题没解决开头这个问题没法排)

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

所以最大的锅还是:说好的缓存呢?
gdtv
2016-03-09 11:08:26 +08:00
原来是 wordpress 啊,楼主你开了 memcache 缓存吗?
开 memcache 缓存,再装个 supercache 插件(忘记是不是这个名字),前台图片弄小些,可以考虑用七牛缓存图片和 js css 文件。
digimoon
2016-03-09 11:28:29 +08:00
学习一下排查思路
edsgerlin
2016-03-09 14:00:13 +08:00
@mhycy 结果是 SQL 没写好的问题么, 233
linxl
2016-03-09 15:46:40 +08:00
这是个好贴,收藏先。
laoyuan
2016-03-10 09:59:55 +08:00
一般网站跪了,我就在 mysql shell 里不停的 show processlist;

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/261839

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX