莫名其妙感觉你说话很有喜感

又是你这个老毕登

@4kingRAS 是的，正常这块的大小可能只有几百 KB ，700M 是明显不正常的，这个文章里的这几个类我也找过了，代码里是没有用的，所以就卡在没法定位具体代码这里了

@fiveStarLaoliang 堆内存是正常的，也就是 dump 文件是看不出啥的

看不到阿尔萨斯的图了，从堆外内存泄漏着手吧

@Znemo try try see ， 试出来的

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

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

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

@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%

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

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

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

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

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

@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]

@ArthurKing 看不出问题