阿里云 ECS 上安装的 MySQL 卡

2018-01-01 20:05:10 +08:00
 studentht

如题: 一台 ECS,2G 内存,1M 带宽,Centos 7,安装了 MySQL 5.7,其他的主要就有运行了一个 wordpress。 系统负载很低,

[root@...... ~]# uptime
 19:00:00 up 14 days, 00:00,  1 user,  load average: 0.07, 0.08, 0.06
[root@...... ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           1839         978         156           2         704         690
Swap:             0           0           0

现在有一个问题,就是用 mysql 客户端(主要是 workbench,其他的 Navicat Essentials 和 SQLyog Community 都有试过)远程连接 ECS 上的 MySQL Server(直接 TCP 端口连接,不是 ssh 登陆后连 localhost),每隔一段时间后,运行一句 sql 就会卡半天,等这一句执行完了,后面一段时间运行 sql 就会很快。再休息一段时间不执行 sql,过一段时间再执行一句 sql 又会卡,像 MySQL Server 休眠了一样。
我观察 workbench 显示卡的 sql,显示:

Duration / Fetch  
0.047 sec / 0.000 sec  

就是说其实执行这条 sql 并没有花多少时间,但是问题是整个查询过程确实费了不少时间,界面一直卡着。
万能的 V 友,大家有遇到这种情况吗?

4302 次点击
所在节点    MySQL
16 条回复
kohos
2018-01-01 21:13:54 +08:00
你试一下去 Edit - Preferences - SQL Editor - MySQL Session 中的 DBMS connection keep-alive interval 设置改成 30 试试。我觉得是时间长了连接丢失了
tt0411
2018-01-01 21:43:17 +08:00
最好在服务器上对比测试一下, 确定延时是查询造成的还是网络造成的
likuku
2018-01-01 21:47:18 +08:00
远程直连数据库...国内网络这种尿性,生产环境 /正式环境,也没人这么用
opengps
2018-01-02 08:38:01 +08:00
首先提醒一句,所有的云服务器都是虚拟机,其硬盘性能( iops )都低于笔记本硬盘的十分之一(估算)
这也是我给他人介绍云服务器时候常见的误区,这么理解把,虚拟机里的是虚拟硬盘,毕竟是浪费了一层效率的,iops 下降是必然,甚至 ssd 的云服务器才等同于普通 5400 转的笔记本硬盘 iops 参数
studentht
2018-01-02 10:08:26 +08:00
@opengps ECS 是 io 优化型实例,硬盘是 SSD (阿里云宣称的),而且 ECS 上没有什么大量 io 读写的程序,监控 io 读写频率和数据量都很低
studentht
2018-01-02 10:14:08 +08:00
@kohos 补充一下,在 osx 上,sequel-pro 也会出现卡的症状,服务器端'wait_timeout', '28800'。
不过有可能是 @likuku 说到的外网复杂的网络环境导致丢包的,我调整这个客户端配置试试看
opengps
2018-01-02 10:40:15 +08:00
@studentht io 优化型不等于 ssd,io 优化是通过其他方式,比如阵列来实现的提高 iops,你可以测试下,实际上还是低于物理 5400 转磁盘。优化的结果确实是高于普通机械盘的虚拟硬盘文件,人家没说错,但也回避了效率低的问题
opengps
2018-01-02 10:41:23 +08:00
说完才反映过来,你的情况是数据盘 ssd,系统盘优化型 io 吧。
数据盘的 ssd 可能只等于普通电脑装普通 ssd 的效果
liuzhedash
2018-01-02 10:57:37 +08:00
@kohos #1
根据描述的情况看,1 楼百分之九十九答对了
xbdsky
2018-01-02 12:37:47 +08:00
1g 小内存,mysql 经常崩溃
studentht
2018-01-03 10:38:34 +08:00
@kohos @liuzhedash 我测试了,应该就是连接丢失的问题。有个问题,为什么连接丢失了,会导致 mysql 客户端卡这么久了,是因为 `DBMS connection time out (in seconds)` 这个选项设置有关吗?
studentht
2018-01-03 11:03:17 +08:00
@opengps 我觉得应该不是你理解的那样,io 优化实例是针对 ECS,与使用什么硬盘无关。
kohos
2018-01-03 11:32:55 +08:00
@studentht 应该是,我刚刚把 timeout 改成了 10 秒,长时间空闲之后的查询就只卡了 10 多秒,但我还是宁愿改 keep-alive 为 30 秒,没这耐心。因特网上哪个节点会那么好维持一个 10 多分钟都没有数据传输的 TCP 连接
studentht
2018-01-03 15:27:39 +08:00
@kohos 😀。奇怪 workbench 默认 keep-alive 时间为什么设置的这么长
kohos
2018-01-03 15:33:48 +08:00
@studentht 因为一般都是连接本机……其实现在连互联网 linux 系统的 MySQL 服务器最好是通过 Standard TCP/IP over SSH,SSH 用密钥文件登录,客户端经过 SSH 之后再本机连接 MySQL,这样是最安全的
kohos
2018-01-03 15:37:14 +08:00
@kohos 补充一下其实也不是最安全,是比较安全。往上还有 SSL 证书登录等

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

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

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

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

© 2021 V2EX