这是一个创建于 3245 天前的主题，其中的信息可能已经有所发展或是发生改变。
网站环境是 LAMP ，是一个电商网站 A ，不定期出现了下面这种情况：
1. 浏览商品正常，下单，跳到支付宝支付页面，支付完成跳回，此时跳回的页面出现了一直加载无法响应的情况，这时候再打开一个标签页，浏览商品页也出现了一直加载的情况，等到支付跳回页面出现超时失败页面后，可以浏览商品。再次下单上述情况重现。
2. 与此网站共用 mysql 的另一个电商网站 B ，一切正常。 A 与 B 共用了包含用户余额的用户信息表，订单相关表都是分开的
3. 重启 mysql 后，问题不再出现
4. A 网站支付完成改变订单状态的数据库操作使用了事务， B 没有使用
求解。
1. 浏览商品正常，下单，跳到支付宝支付页面，支付完成跳回，此时跳回的页面出现了一直加载无法响应的情况，这时候再打开一个标签页，浏览商品页也出现了一直加载的情况，等到支付跳回页面出现超时失败页面后，可以浏览商品。再次下单上述情况重现。
2. 与此网站共用 mysql 的另一个电商网站 B ，一切正常。 A 与 B 共用了包含用户余额的用户信息表，订单相关表都是分开的
3. 重启 mysql 后，问题不再出现
4. A 网站支付完成改变订单状态的数据库操作使用了事务， B 没有使用
求解。
 |
1
fising 2015-12-23 11:39:59 +08:00
show processlist 看过了吗
|
 |
2
looyao 2015-12-23 11:53:47 +08:00
如果是 NGINX+PHP-FPM 的话
先看下 NGINX 的 error 日志，哪个链接出现了 timeout ，这样可以定位到功能。 PHP-FPM 如果没有配置慢日志，配置一下慢日志，这样可以方便看到具体哪里慢，可以定位到具体代码航。 MySQL 也可以配置下慢日志，这样方便分析问题。线上的话， show processlist 看下，具体那个 SQL 执行的慢。 还有，看下服务器性能， TOP 看下 CPU 占用，负载，如果负载值超过了 CPU 个数，说明有任务堆积，可能是某个逻辑慢，导致链接堆积处理不完，这就要看上边几个问题来分析了。其他感觉 I/O 应该没问题，不过也可以看下。 |
 |
3
Plumes OP |
|
4
looyao 2015-12-24 16:50:46 +08:00
@Plumes 感觉可能是 ty_member 、 shopjl_order_pay 更新操作有瓶颈了，不知道这两个表的记录数有多少，先看下 where 条件是否走索引，如果没有走索引可能就是问题所在了。还有就是，不知道你是否配置了从库，如果没有从库可以搭建一个从库，做一下读写分离，查询的都走从库。如果是因为表的记录数过多导致的话，可以考虑分表了，比如按月或者季度等。只是大概一个思路，希望能帮到你。
|
|
6
fising 2015-12-24 17:02:24 +08:00
order_pay updating 60s ，好好查查原因
|
|
7
fising 2015-12-24 17:03:35 +08:00
show full processlist 看看完整的 SQL 语句吧。记录数这么少，延迟这么高
|
|
8
looyao 2015-12-24 17:05:29 +08:00
@Plumes 数据这么少，性能应该不是问题，是不是 MySQL 没有关闭 DNS 反向解析导致的呢？ MySQL 配置文件有`skip-name-resolve`这个么，如果没有，可以加上试下，不过需要重启 MySQL 才会生效。还有一种就是，把前端要访问的主机名，就是 hostname ，加入到 MySQL 所在服务器的 host 里边。比如要连接到 MySQL 服务的机器 IP 是 10.10.0.10 ，主机名是 node1 ，那么直接在 MySQL 服务所在机器的 hosts 文件中加入
10.10.0.10 node1 可能是这个问题也可能不是，不过你可以试下。 |
Select Language