V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
cmai
V2EX  ›  MySQL

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

  •  1
     
  •   cmai · 172 天前 · 2424 次点击
    这是一个创建于 172 天前的主题,其中的信息可能已经有所发展或是发生改变。

    当我在并行执行几个复杂的视图的时候,mysql 整个库都会陷入到卡死的状态,所有的表都打不开,可以从哪方面排查呢?

    第 1 条附言  ·  171 天前
    最新消息,大概率不是 ceph 和 docker 的 request limit 的问题

    request 给到了 4 核 8G , 磁盘换成虚拟机的本地磁盘了, 还是一样会复现
    第 2 条附言  ·  171 天前
    破案了,下面这行配置导致的, 原理还在细看
    innodb_thread_concurrency = 4
    34 条回复    2023-09-14 10:10:00 +08:00
    cmai
        1
    cmai  
    OP
       172 天前
    我在服务器端执行了一个简单的 sql,通过 show profiles 查看他的执行进度, 是卡在 sending data 阶段
    ArthurKing
        2
    ArthurKing  
       172 天前
    监控下服务器性能,cpu 、内存、io 、网络
    cmai
        3
    cmai  
    OP
       172 天前
    mysql 版本是:5.7.38-log
    环境是 docker ,容器化部署的 request 0.1 核 4G ,limit 给的 16 核 32G

    存储用的是 ceph


    我就想知道可能因为哪些原因会导致整个库都没法正常访问,cpu 在最高点也只到了两核,内存只用到了 6G , 磁盘 I/O 最高点 30M/S
    cmai
        4
    cmai  
    OP
       172 天前
    @ArthurKing 看不出问题
    zhangkunkyle
        5
    zhangkunkyle  
       172 天前
    innodb_buffer_pool_size 小不小
    zhangkunkyle
        6
    zhangkunkyle  
       172 天前
    小的话改大点,改到内存的 75%-80%,重启 MySQL 再试试
    cmai
        7
    cmai  
    OP
       172 天前
    @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]
    cmai
        8
    cmai  
    OP
       172 天前
    4G ,我觉得原因可能不在这
    James2099
        9
    James2099  
       172 天前
    查看 MySQL 进程列表
    javaboy233
        10
    javaboy233  
       172 天前
    卡死的话,建议打印下线程栈
    cmai
        11
    cmai  
    OP
       172 天前
    @James2099 进程列表, 指的是 show full processlist 吗, 这个我看了, 没什么问题
    cmai
        12
    cmai  
    OP
       172 天前
    8215 是我执行的单表查询,已经卡死了,上面四个是视图的 SQL
    ![20230912-200924.jpg]( https://x.imgs.ovh/x/2023/09/12/650055143df7e.jpg)
    cmai
        13
    cmai  
    OP
       172 天前
    图片好像没贴上来呢
    <img src="https://x.imgs.ovh/x/2023/09/12/650055143df7e.jpg" alt="20230912-200924.jpg" title="20230912-200924.jpg" />
    devopsdogdog
        14
    devopsdogdog  
       172 天前 via Android
    mysql 日志,加贴配置文件,会跟踪系统调用的话,直接看调用卡在哪里
    yinmin
        15
    yinmin  
       172 天前 via iPhone
    docker 对 mysql 容器做 limit 是有坑的,容器里是读到物理机实际内存和 cpu 数的,与 limit 不一样会卡,而且内存超限 mysql 可能直接崩掉。

    建议取消 docker limit ,限制参数改到 mysql 配置里。
    yinmin
        16
    yinmin  
       172 天前 via iPhone
    @cmai 可能问题出在 docker limit 上,去掉试试
    yinmin
        17
    yinmin  
       172 天前 via iPhone
    @cmai 如果部署在 k8s 上,需要调整 mysql 配置,以匹配 k8s 的 limit
    yinmin
        18
    yinmin  
       172 天前 via iPhone
    另外,ceph 读写性能是否足够,通常最佳配置下的 ceph 速度也只有 sata ssd 速度,与 NVMe ssd 差 5-10 倍的速度。
    yinmin
        19
    yinmin  
       172 天前 via iPhone
    问题大概率是 ceph 的读写速度和延时跟不上导致的。
    opengps
        20
    opengps  
       172 天前 via Android
    with no lock
    voidmnwzp
        21
    voidmnwzp  
       172 天前 via iPhone
    换 oracle
    ericguo
        22
    ericguo  
       172 天前
    可以先升级到 5.7.44 看看。看起来像 bug https://dev.mysql.com/doc/relnotes/mysql/5.7/en/
    ccde8259
        23
    ccde8259  
       171 天前 via iPhone
    @cmai 别用 Ceph 这类块存储延迟表现极其差劲……
    zoharSoul
        24
    zoharSoul  
       171 天前
    不要用视图
    cmai
        25
    cmai  
    OP
       171 天前
    @zoharSoul 旧系统的改造,没法约束
    cmai
        26
    cmai  
    OP
       171 天前
    @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%
    cmai
        27
    cmai  
    OP
       171 天前
    @yinmin 调整 limit 这个我等下会尝试下,有结果了来这里回复,哈哈
    hefish
        28
    hefish  
       171 天前
    这磁盘的 read 小了点啊。
    Znemo
        29
    Znemo  
       171 天前
    连接因为某种原因断开了,查询的时候在重连。
    cmai
        30
    cmai  
    OP
       171 天前
    @Znemo 啊,这是怎么看出来的
    realpg
        31
    realpg  
       171 天前
    @cmai #30
    知道你问题解决了
    但是,视图赶紧全删了……
    Znemo
        32
    Znemo  
       171 天前
    @cmai innodb_thread_concurrency 这是怎么看出来的
    cmai
        33
    cmai  
    OP
       170 天前
    @realpg 没办法,不是我写的, 虽然我也很想删掉他,我们制定的使用标准已经回收了视图和存储过程的权限, 这个 mysql 是从旧的虚拟机上迁移到容器里, 业务组不改我们也只能迁就
    cmai
        34
    cmai  
    OP
       170 天前
    @Znemo try try see , 试出来的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1009 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 38ms · UTC 23:43 · PVG 07:43 · LAX 15:43 · JFK 18:43
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.