关于 MySQL 的一个问题，希望得到排查思路

我在服务器端执行了一个简单的 sql,通过 show profiles 查看他的执行进度， 是卡在 sending data 阶段

监控下服务器性能，cpu 、内存、io 、网络

mysql 版本是:5.7.38-log
环境是 docker ，容器化部署的 request 0.1 核 4G ，limit 给的 16 核 32G

存储用的是 ceph


我就想知道可能因为哪些原因会导致整个库都没法正常访问，cpu 在最高点也只到了两核，内存只用到了 6G ， 磁盘 I/O 最高点 30M/S

@ArthurKing 看不出问题

innodb_buffer_pool_size 小不小

小的话改大点，改到内存的 75%-80%，重启 MySQL 再试试

@zhangkunkyle

BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 4397727744
Dictionary memory allocated 1803515
Buffer pool size 262112
Free buffers 8241
Database pages 250582
Old database pages 92339
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 2896024, not young 149994356
0.00 youngs/s, 0.00 non-youngs/s
Pages read 2396803, created 975730, written 1883403
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 250582, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]

4G ，我觉得原因可能不在这

查看 MySQL 进程列表

卡死的话，建议打印下线程栈

@James2099 进程列表， 指的是 show full processlist 吗， 这个我看了， 没什么问题

8215 是我执行的单表查询，已经卡死了，上面四个是视图的 SQL

图片好像没贴上来呢
<img src="https://x.imgs.ovh/x/2023/09/12/650055143df7e.jpg" alt="20230912-200924.jpg" title="20230912-200924.jpg" />

mysql 日志，加贴配置文件，会跟踪系统调用的话，直接看调用卡在哪里

docker 对 mysql 容器做 limit 是有坑的，容器里是读到物理机实际内存和 cpu 数的，与 limit 不一样会卡，而且内存超限 mysql 可能直接崩掉。

建议取消 docker limit ，限制参数改到 mysql 配置里。

@cmai 可能问题出在 docker limit 上，去掉试试

@cmai 如果部署在 k8s 上，需要调整 mysql 配置，以匹配 k8s 的 limit

另外，ceph 读写性能是否足够，通常最佳配置下的 ceph 速度也只有 sata ssd 速度，与 NVMe ssd 差 5-10 倍的速度。

问题大概率是 ceph 的读写速度和延时跟不上导致的。

with no lock

换 oracle

可以先升级到 5.7.44 看看。看起来像 bug https://dev.mysql.com/doc/relnotes/mysql/5.7/en/

@cmai 别用 Ceph 这类块存储延迟表现极其差劲……

不要用视图

@zoharSoul 旧系统的改造，没法约束

@yinmin 好的，我会关注下这个问题，其实出现问题的第一时间就怀疑是磁盘的问题了， 但是做存储这块的同学很肯定的告诉我不是磁盘的问题 0.0 ， 给我了一份测试报告





2G 文件 ，4K 随机读，10 线程，异步，磁盘测试，IOPS=73.6K
Starting 10 threads
Jobs: 10 (f=10): [r(10)][100.0%][r=338MiB/s,w=0KiB/s][r=86.6k,w=0 IOPS][eta 00m:00s]
mytest: (groupid=0, jobs=10): err= 0: pid=3370: Mon Sep 11 09:36:20 2023
read: IOPS=73.6k, BW=288MiB/s (302MB/s)(16.9GiB/60001msec)
clat (nsec): min=733, max=122800k, avg=133663.23, stdev=560820.67
lat (nsec): min=761, max=122801k, avg=133786.51, stdev=560824.85
clat percentiles (nsec):
| 1.00th=[ 1464], 5.00th=[ 2024], 10.00th=[ 2416],
| 20.00th=[ 2960], 30.00th=[ 3440], 40.00th=[ 3888],
| 50.00th=[ 4320], 60.00th=[ 4896], 70.00th=[ 5600],
| 80.00th=[ 6944], 90.00th=[ 544768], 95.00th=[ 946176],
| 99.00th=[ 1843200], 99.50th=[ 2605056], 99.90th=[ 6258688],
| 99.95th=[ 8159232], 99.99th=[13565952]
bw ( KiB/s): min= 2336, max=51544, per=9.98%, avg=29408.46, stdev=6697.04, samples=1193
iops : min= 584, max=12886, avg=7352.08, stdev=1674.25, samples=1193
lat (nsec) : 750=0.01%, 1000=0.10%
lat (usec) : 2=4.59%, 4=37.73%, 10=43.12%, 20=2.04%, 50=0.68%
lat (usec) : 100=0.12%, 250=0.02%, 500=1.19%, 750=2.96%, 1000=3.03%
lat (msec) : 2=3.59%, 4=0.59%, 10=0.21%, 20=0.03%, 50=0.01%
lat (msec) : 100=0.01%, 250=0.01%
cpu : usr=1.78%, sys=5.45%, ctx=519504, majf=0, minf=3494
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=4418208,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
READ: bw=288MiB/s (302MB/s), 288MiB/s-288MiB/s (302MB/s-302MB/s), io=16.9GiB (18.1GB), run=60001-60001msec
Disk stats (read/write):
rbd24: ios=511432/6, merge=0/2, ticks=541535/21, in_queue=256375, util=99.84%

@yinmin 调整 limit 这个我等下会尝试下，有结果了来这里回复，哈哈

这磁盘的 read 小了点啊。

连接因为某种原因断开了，查询的时候在重连。

@Znemo 啊，这是怎么看出来的

@cmai #30
知道你问题解决了
但是，视图赶紧全删了……

@cmai innodb_thread_concurrency 这是怎么看出来的

@realpg 没办法，不是我写的， 虽然我也很想删掉他，我们制定的使用标准已经回收了视图和存储过程的权限， 这个 mysql 是从旧的虚拟机上迁移到容器里， 业务组不改我们也只能迁就

@Znemo try try see ， 试出来的