• 个人经验~ 利用5.7的sys库更好的排查问题


    一 简介:今天我们讲讲如何利用5.7的sys新库进行问题的排查
    二 描述
       1 Sys库所有的数据源来自:performance_schema和information_schema。目标是把performance_schema的把复杂度降低,让DBA能更好的阅读这个库里的内容。让DBA更快的了解DB的运行情况。
      2 mysql对于系统性能和sql语句状态的收集是非常少的,基本排查手段都要靠经验判断,5.7的sys特性能周期性的收集系统状况和sql的状态,有利于DBA更好的对问题进行判断,集成了视图,本身不存储数据
    三 具体sql语句应用
      一 IO相关
        1查看表访问量前10top信息
          select table_schema,table_name,sum(io_read_requests+io_write_requests) io from schema_table_statistics group by table_schema,table_name order by io desc limit 10;
        2 查看文件访问量前10top信息
         select file,avg_read+avg_write as avg_io from io_global_by_file_by_bytes order by avg_io desc limit 10;
       3 查看具体表的操作类型延迟统计
        select * from schema_table_statistics where table_schema ='' and table_name=''(增删查改操作延时)
       4 慢查询扫描全表
        select * from schema_tables_with_full_table_scans(最新的全表扫描相关信息)

      5 通过mysql线程 ID 来跟算

           1 iotop定位具体的mysql线程 获得线程的PID

           2 select name,type,thread_id,processlst_id from performance_schema.threads where thread_os_id='PID'; ->一般用户导致的调研的线程就是one_connections

           3 select * from sys.processlist where processlist_id='' 或者直接show processlist过滤
        小结 可以代替pt-iopfile工具,直接查询非常方便定位IO问题
    二 内存相关
        select * from innodb_buffer_stats_by_table
        select * from innodb_buffer_stats_by_schema
       1 分别从库和表角度分析占用内存比,分析内存问题

         select event_name, SUM_NUMBER_OF_BYTES_ALLOC from  pefromance_schema.memory_summary_by_thread_by_event_name  order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 20;

      2 从线程角度分析内存占用 

         event_name | SUM_NUMBER_OF_BYTES_ALLOC | 
      +-------------------------------------------+---------------------------+ 
      | memory/sql/Filesort_buffer::sort_keys | 13942381710536 | 
      | memory/memory/HP_PTRS | 5413962191080 | 
      | memory/sql/thd::main_mem_root | 1095525347280 | 
      | memory/mysys/IO_CACHE | 471119309576 | 

        注意点:1 mysql默认是无法查询到相关内存数据的,需要打开数据收集,具体执行语句              

                     UPDATE setup_instruments SET ENABLED = 'YES',TIMED = 'YES'  where NAME like '%memory%';

                  2 配置文件添加

                    performance_schema=1

                   performance_schema_instrument='%=on'    

      三 等待操作
      1 select * from waits_global_by_latency(事件等待)
      2 select * from innodb_lock_waits (锁等待,未来information的相关表将被废弃)
    四 应用程序角度
       select * from  host_summary order by (file_io_latency,total_connections,current_memory)
      小结 这个视图可以从内存 IO,sql执行延迟等角度综合进行排查,定位具体的应用主机
    五 总结
      1 定位具体的host,user,schema,table,DML操作 能帮你快速的解决大多数问题
      2 从用户和系统内存两方面来分析内存问题
      3 缺少cpu级别的信息收集,比较遗憾

  • 相关阅读:
    Codeforces 946D
    Codeforces 817F
    Codeforces 931F
    Codeforces 932D
    Graph HDU
    Chef and Graph Queries CodeChef
    Lucky Array Codeforces
    Calculation 2 HDU
    洛谷 P3455 [POI2007]ZAP-Queries || 洛谷P2522,bzoj2301
    洛谷 P2398 GCD SUM || uva11417,uva11426,uva11424,洛谷P1390,洛谷P2257,洛谷P2568
  • 原文地址:https://www.cnblogs.com/danhuangpai/p/10660989.html
Copyright © 2020-2023  润新知