### mysql系統結構_3_Mysql_Learning_Notes

時間  2019-11-15
標籤 mysql 系統 結構 learning notes 欄目 MySQL 简体版
原文   原文鏈接

mysql系統結構_3_Mysql_Learning_Notes

存儲層,內存結構

  • 全局(buferpool)
    • 只分配一次
    • 全局共享
  • 鏈接/會話(session)
    • 針對每一個會話/線程分配
    • 按需動態分配,查詢結束後釋放
    • 用於處理(緩衝,中轉)查詢結果
    • 每一個會話的緩衝區大小都不同

Alt text

mysql 內存佔用主要分層狀況

引擎層(內存部分):
  • innodb buffer
  • innodb log buffer

  • key buffer(是myisam使用,具體參數爲myisam_sort_buffer_size)mysql

    mysql server 層(內存,也叫SQL層):
  • query cache(默認禁用)
  • table(def)cache(全局表的緩存)
    • 首先嚐試從table cache中取table
    • 當找到的TABLE實例是nam-locked的，或者一些線程正在flush tables，咱們須要等待，直到鎖釋放
    • 若是不存在這樣的TABLE，咱們須要建立TABLE，並將其加入到cache中這些操做都須要全局鎖：LOCK_open,來保護table cache和磁盤上的表定義
  • thread cache

  • mdl cache (metadata_locks_cache_size)git

    鏈接/會話層(內存):
  • net/read/join/sort/bulk insert buffer
  • tmp/heap table (系統產生的臨時表和用戶建立的)

  • binlog cachegithub

    mysqld 進行消耗內存估算因素(大多數不會把全部算滿,只是作最極端狀況):
  • global buffers(相似於SGA):
    • innodb buffer pool
    • innodb log buffer
    • key buffer
    • query cache
    • table cache
    • thread cache
  • 會話/線程級分配的all thread buffers(相似於PGA)
    • max_threads * (read buffer+
    • read rnd buffer+
    • sort buffer+
    • join buffer+
    • tmp table+
    • binlog cache)
  • 有時系統提示:buffer pool設置太大不能啓動,這是一個通用報錯,好多時候多是由於版本問題等.
  • 如何查看buffer pool 是否夠用?
    • show engine innnodb status,結果中專門有一段是:"BUFFER POOL AND MEMORY",能夠從free buffers.
    • show global status like 'innodb%buffer%';中能夠innodb_buffer_pool_pages_free<10或innodb_buffer_pool_wait_free>0就表明嚴重不足.
    • show global status like '%table%';中opened_tables和open_tables的數是不差距很大,若是大就表明table cache不夠用,監控時,主要觀測固定週期的opened_tables數量的增長狀況.
    • show global status like '%thread%';中thread_created、thread_connected的數是不差距很大,若是大就表明thread cache不夠用.能夠觀測固定週期的thread_created數量的增長狀況.
    • show global status like '%sort%merg%';中sort_merge_passes的數量.
    • show global status like '%tmp%table%';中created_tmp_tables的數量.更嚴重的是created_tmp_disk_tables
  • 兩個容易被設置很大的內存選項:
    • 都是session級
    • max_heap_table_size限制MEMORY表的最大容量,無論其餘執行SQL產生的臨時表,若內存不夠用,則不容許寫入新的數據,MEMORY表也不會轉成磁盤表,只會告警超限後拒絕寫入.
    • tmp_table_size 不限制MEMORY表最大容量,若是執行SQL產生臨時表超過tmp_table_size或max_heap_table_size,則會產生基於磁盤的臨時表.
    • 這2個選項特別容易分配較大,如有須要,可臨時調大,不要修改全局值.

  • 觀察SQL執行過程(有沒有建立臨時表等):
    1.設置set profiling=1&set profiling_history_size=2
    2.執行SQL(select benchmark(100000,pow(2,10));)
    3.use information_schema;
    3.select Query_ID,state,DURATION from PROFILING order by query_id desc limit 1;(8.0之前能夠直接用show profiles;查詢)算法

root@localhost [information_schema]>select benchmark(100000,pow(2,10));
+-----------------------------+
| benchmark(100000,pow(2,10)) |
+-----------------------------+
|                           0 |
+-----------------------------+
1 row in set (0.02 sec)

root@localhost [information_schema]>select Query_ID,state,DURATION from PROFILING order by query_id desc limit 1;
+----------+-------+----------+
| Query_ID | state | DURATION |
+----------+-------+----------+
|        3 | init  | 0.000024 |
+----------+-------+----------+
1 row in set, 1 warning (0.00 sec)
root@localhost [information_schema]>show profiles;
+----------+------------+------------------------------------------------------------------------------+
| Query_ID | Duration   | Query                                                                        |
+----------+------------+------------------------------------------------------------------------------+
|        3 | 0.01043275 | select benchmark(100000,pow(2,10))                                           |
|        4 | 0.00082200 | select Query_ID,state,DURATION from PROFILING order by query_id desc limit 1 |
+----------+------------+------------------------------------------------------------------------------+
2 rows in set, 1 warning (0.00 sec)

關於huge page

  • 使用大頁是爲了提升內存管理效率.RHEL6\SLES11\UEK2起默認是啓動的.
  • 透明大頁能夠動態調整,無需重啓便可生效
  • 相似innodb data page 概念
  • 但啓用透明大頁可能反而致使MySQL(TokuDB)更容易發生內存泄漏\OOM等問題,因此建議關閉
  • 查看是否關閉
    • cat /sys/kernel/mm/transparent_hugepage/enabled
    • cat /sys/kernel/mm/transparent_hugepage/defrag
    • grep AnonHugePages /proc/meminfo AnonHugePages > 0 一樣表示啓用了透明大頁
    • 如何禁用透明大頁：
      方法一:在 /etc/grub.conf 中添加一行記錄：transparent_hugepage=never
      方法二：配置/etc/rc.local 而後重啓服務器:
      if test -f /sys/kernel/mm/redhat_transparent_hugepage/enabled; then
      echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
      fi
      if test -f /sys/kernel/mm/redhat_transparent_hugepage/defrag; then
      echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
      fi

不一樣引擎對比

主要可瞭解存儲引擎:Innodb\TokuDB\MyRocks
|引擎名|特色|使用建議|
|-|-|
|InnoDB|支持事務,基於MVCC設計,索引組織表,只能有一個聚焦索引|在絕大多數場景建議使用此引擎,尤爲是OLTP|
|tokudb|支持事務,高壓縮,高速寫入|適用於基於時間有序數據的海量數據環境|
|MyIsam|早期版本引擎,堆表。在MariaDB用Aria替代,官方版本中也在減少對MyiSAM的使用|儘可能少使用MyISQL,MyISQL對CPU,內存,內存利用率不高,併發支持很差|
|inforbright,infinidb|列式存儲引擎,高壓縮,快速加載數據.|適用於OLAP環境|
|Memory|之內存爲存儲介質,請求速度高,但數據不安全|適用於數據安全要求不高的環境,如:臨時記數等|sql

plugin 管理

1.查看plugin
查看plugin-dir參數設置,查找到plugin的存放位置(mysqladmin var|grep plugin_dir).
/usr/local/mysql/lib/plugin/
2.安裝plugin
mysql>install plugin rpl_semi_sync_master soname 'semisync_master.so'
3.刪除plugin
uninstall plugin rep_semi_sync_master;緩存

其餘plugin

  • rockdb安全

  • tokudb
    percona 公司收購,開源GPL協議,大數據存儲引擎,高速數據寫入\追加的業務場景,高效壓縮(10倍)\成本節省一半以上的備選方案.支持MVCC\Online DDL(大規模數據1T+,須要歸檔,頻繁增減字段等場景適合)
    • 此外Xenon TokuDB是對Percona公司的TokuDB進行Patch優化。
    • 項目地址： https://github.com/XeLabs/tokudb
    • 引入的優化點：
    • 支持xtrabackup直接備份 https://github.com/XeLabs/tokudb-xtrabackup 針對TokuDB備份的Patch的分支。
    • 加入ZST壓縮算法（From MyRocksDB）
    • 支持binlog group commit

引入性能計數器 show engine tokudb status ，更多選項。服務器

  • spider
  • handlersocket

統計表DML狀況

  • use syssession

  • 統計根據索引的DML狀況:
    select index_name,rows_selected,rows_inserted,rows_updated,rows_deleted from schema_index_statistics where table_schema='world' and table_name='city' and index_name='Conuntrycode';
    |index_name|rows_selected|rows_inserted|rows_updated|rows_deleted|
    |-|-|-|-|-|
    |ID|18131|0|0|0|
    |countrycode|2|0|0|0|併發

  • 查看某個表的DML狀況:

root@localhost [sys]>select table_name,rows_fetched,rows_inserted,rows_updated,rows_deleted,io_read,io_read_requests,io_write,io_write_requests from schema_table_statistics where table_schema='wenyz' and table_name='t2';
+------------+--------------+---------------+--------------+--------------+-----------+------------------+----------+-------------------+
| table_name | rows_fetched | rows_inserted | rows_updated | rows_deleted | io_read   | io_read_requests | io_write | io_write_requests |
+------------+--------------+---------------+--------------+--------------+-----------+------------------+----------+-------------------+
| t2         |        68282 |             0 |            0 |            0 | 48.85 KiB |               10 | 0 bytes  |                 0 |
+------------+--------------+---------------+--------------+--------------+-----------+------------------+----------+-------------------+
1 row in set (0.01 sec)
  • 查看冗餘索引.
select * from schema_redundant_indexes\G
  • 查看全表掃描的狀況
root@localhost [sys]>select * from schema_tables_with_full_table_scans limit4;
+---------------+-------------+-------------------+---------+
| object_schema | object_name | rows_full_scanned | latency |
+---------------+-------------+-------------------+---------+
| wenyz         | t2          |             68650 | 1.20 s  |
+---------------+-------------+-------------------+---------+
1 row in set (0.00 sec)
  • 查指定表buffer
root@localhost [sys]>select * from schema_table_statistics_with_buffer  where table_schema='wenyz' and table_name='t2'\G;
*************************** 1. row ***************************
              table_schema: wenyz
                table_name: t2
              rows_fetched: 68866
             fetch_latency: 1.21 s
             rows_inserted: 0
            insert_latency: 0 ps
              rows_updated: 0
            update_latency: 0 ps
              rows_deleted: 0
            delete_latency: 0 ps
          io_read_requests: 10
                   io_read: 48.85 KiB
           io_read_latency: 2.10 ms
         io_write_requests: 0
                  io_write: 0 bytes
          io_write_latency: 0 ps
          io_misc_requests: 11
           io_misc_latency: 111.24 us
   innodb_buffer_allocated: 16.00 KiB
        innodb_buffer_data: 14.36 KiB
        innodb_buffer_free: 1.64 KiB
       innodb_buffer_pages: 1
innodb_buffer_pages_hashed: 0
   innodb_buffer_pages_old: 1
 innodb_buffer_rows_cached: 362
1 row in set (0.05 sec)
  • 查看MDL鎖
select * from schema_table_lock_waits limit 4\G

percona toolkit(pt)

  • pt-summary、pt-mysql-summary 主機和mysql通常信息採集
  • pt-mext show global status 結果輸出對比,發現差別
  • pt-variavle-advisor 配置參數建議
  • pt-ioprofile 相似ioprofile工具,檢查mysql中哪些文件I/O壓力大.
  • pt-kill 殺掉符合某些特徵的查詢,如慢查詢或SQL注入等
  • pt-online-schema-change nline DDL爲足的替代/補充工具
  • pt-query-digest 查詢分析日誌
  • pt-pmp 分析pstack的日誌信息
#ps aux |grep mysql 
mysql     4279  9.4 80.9 23140516 19853348 ?   Sl   Sep12 7553:31 /usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/mysql3306/my3306.cnf

#pstack 4279> /tmp/pstack.txt 

### pt-pmp /tmp/pstack.txt

pstack

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程