MySQL运维系列 之 如何快速定位IO瓶颈

阅读全文请点击

MySQL的瓶颈,一般分为IO密集型和CPU密集型

CPU出问题的情况比较少,最近就遇到过一次比较大的故障,这个话题后面会有一篇专题介绍

今天主要聊聊IO密集型的应用中,我们应该如何快速定位到是谁占用了IO资源比较多

背景

  • 环境
1. MySQL 5.7 +
    低版本MySQL这边不再考虑,就像还有使用SAS盘的公司一样,费时费力,MySQL5.7+ 标配
2. InnoDB 存储引擎
3. Centos 6

实战

关于IO的问题,大家能想到的监控工具有哪些

  1. iostat
  2. dstat
  3. iotop

没错,以上都是神器,可以直接用iotop找到占用资源最多的进程

先上一张图

iotop

是的,根据这张图,你能发现的就是MySQL的某个io线程占用了比较多的disk资源,然后呢?

然后,就是去MySQL里面去找,有经验的DBA会去看slow log,或者processlist中去查找相关的sql语句

通常情况下,DBA只会一脸茫然的看到一堆MySQL的query语句,一堆slow log里面去分析,有如大海捞针,定位问题繁琐而低效

如果,你使用的是MySQL5.7+ 版本,那么你就会拥有一件神器(说了好多遍了),可以快速而精准的定位问题

  • 如何快速定位到IO瓶颈消耗在哪里

iotop + threads

dba:lc> select * from performance_schema.threads where thread_os_id=37012\G
*************************** 1. row ***************************
          THREAD_ID: 96
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 15
   PROCESSLIST_USER: dba
   PROCESSLIST_HOST: NULL
     PROCESSLIST_DB: sbtest
PROCESSLIST_COMMAND: Query
   PROCESSLIST_TIME: 0
  PROCESSLIST_STATE: query end
   PROCESSLIST_INFO: INSERT INTO sbtest1(k, c, pad) VALUES(25079106, '33858784348-81663287461-16031064329-06006952037-79426243027-69964324491-90950423034-40185804987-62166137368-06259615216', '47186118229-42754
696460-81034599900-41836403072-66805611739'),(24907169, '77074724245-16833049423-38868029911-54850236074-63700733526-39699866447-52646750572-85552352492-59476301007-32196580154', '79013412600-99031855741-696987
96712-65630963686-19653514942'),(24896311, '28403978193-66350947863-03931166713-97714847962-65299790981-39948912629-14070597101-63277652140-34421148430-61801121402', '05239379274-22840441238-37771744512-9234774
1972-52847679847'),(18489383, '89292717216-01584483614-67433536730-45584233994-29817613740-77179131661-10692787267-83942773303-14971155500-36206705010', '55201342831-85536327239-84383935287-06948377235-96437333
726'),(24790463, '99362943588-41160434740-62783664419-16002619743-04761662097-94273988379-52564232648-19738707042-79143532768-89687113917', '09717575620-89781830996-88443720661-19001024583-14971953687'),(2
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: Socket
       THREAD_OS_ID: 37012
1 row in set (0.00 sec)

你看,消耗资源的SQL语句立刻就呈现在你眼前,就是如此高效

好了,以上列出的,还只是全部功能的冰山一角,更多的玩法等待你去解锁。

以上定位的问题也比较的简单,还有一些复杂的IO问题,比如:binlog写入过大、binlog扫描过多、同步线程阻塞、临时表造成的IO过大,等等问题,都可以用此神器一窥究竟

阅读全文请点击

展开阅读全文

没有更多推荐了,返回首页