MySQL線程池
MySQL線程池只在Percona,MariaDB,Oracle MySQL企業版中提供。Oracle MySQL社區版並不提供。
在傳統方式下,MySQL線程調度方式有兩種:每個串連一個線程(one-thread-per-connection)和所有串連一個線程(no-threads)。在實際生產中,一般用的是前者。即每當有一個用戶端串連到MySQL伺服器,MySQL伺服器都會為該用戶端建立一個單獨的線程。串連數越多,則相應的線程會越多。
如果大部分線程處於空閑狀態,則不會對伺服器的效能造成很大的影響。但如果同時執行的線程太多,會導致作業系統頻繁的環境切換。
引入線程池的目的,就是為了減少同時啟動並執行線程的數量,降低環境切換的次數。
線程池是MariaDB最先實現的,有兩種實現方式,分別對應Windows和Unix作業系統。其中,Windows系統上是直接利用作業系統的本地緩衝池功能,Unix系統上則是自己實現的。這導致兩個作業系統上的系統變數有所不同。
下面,基於Percona 5.6.31版本看看線程池的相關參數
thread_handling
預設是one-thread-per-connection,如果要使用串連池功能,則必須設定為pool-of-threads。
thread_pool_size
用於設定線程池中線程組的個數,預設為伺服器CPU的核心數。實現分組的目的是為了把每個分組對應到每個CPU核心上,這樣在同一時間點,每個分組可調用1個線程進行執行。
thread_pool_max_threads
控制線程池的最大線程數,若該值為1000,代表線程池中所能建立的最大線程數不能超過1000。
This variable can be used to limit the maximum number of threads in the pool. Once this number is reached no new threads will be created.
thread_pool_oversubscribe
用於控制單個CPU核心在同一時間活躍的線程數。類似於一種“超頻”的概念
The higher the value of this parameter the more threads can be run at the same time, if the values is lower than 3 it could lead to more sleeps and wake-ups
thread_pool_stall_limit
線程池中無可用線程時,thread_pool_stall_limit決定等待多久後建立新線程,單位為毫秒。預設是500。
在合適範圍內,該值越大,MySQL伺服器的整體處理效能就越好,因為較少數量的線程,會降低對於系統資源的徵用。但是,並不是越大越好,因為該值越大,新線程的建立將等待更長的時間,使用者的查詢延遲就會越明顯。
The number of milliseconds before a running thread is considered stalled. When this limit is reached thread pool will wake up or create another thread. This is being used to prevent a long-running query from monopolizing the pool.
thread_pool_idle_timeout
設定空閑線程銷毀前的等待時間,單位為秒,預設是60。
使用者可以根據自己的業務情境來調整該參數的值,如果設定得太短,會導致線程頻繁的銷毀與建立,如果設定的太長,則會導致線程池中的線程數長時間不會下降。
This variable can be used to limit the time an idle thread should wait before exiting.
extra_port
用於設定MySQL服務連接埠之外的連接埠,供管理員管理伺服器。
This variable can be used to specify additional port Percona Server will listen on. This can be used in case no new connections can be established due to all worker threads being busy or being locked when pool-of-threads feature is enabled.
extra_max_connections
用於設定extra_port連接埠允許的最大串連數,通過extra_port連接埠建立的串連,採用的是one-thread-per-connection的方式
This variable can be used to specify the maximum allowed number of connections plus one extra SUPER users connection on the extra_port. This can be used with the extra_port variable to access the server in case no new connections can be established due to all worker threads being busy or being locked when pool-of-threads feature is enabled。
除此之外,Percona還新增了兩個參數用於實現優先順序隊列。
thread_pool_high_prio_mode
線程池分組內的待處理任務會放到任務隊列中,等待worker線程處理。
每個分組有兩個隊列:高優先順序隊列和普通隊列,worker線程先從高優先隊列取event處理,只有當高優先隊列為空白時才從普通隊列取event處理。
通過優先順序隊列,可以讓已經開啟的事務或短事務得到優先處理,及時提交釋放鎖等資源。
該參數可設定三種模式:
transactions:預設的,只有一個已經開啟了事務的SQL,並且thread_pool_high_prio_tickets不為0,才會進入到高優先順序隊列中,每個串連在thread_pool_high_prio_tickets次被放到優先隊列中後,會移到普通隊列中。
statements:單獨的SQL總是進入高優先順序隊列
none:禁用高優先順序隊列功能,所有的串連都放到普通隊列中處理。
thread_pool_high_prio_tickets
給每個新的串連授予的tickets大小
This variable controls the high priority queue policy. Each new connection is assigned this many tickets to enter the high priority queue. Setting this variable to 0 will disable the high priority queue.預設為4294967295。
線程池的適用情境:
適用於有大量短查詢的業務情境
在該情境下,每個串連一個線程,過多的串連數很容易達到串連數的最大值,同時,過多的活躍線程會導致頻繁的環境切換。此時,可使用線程池,因為是短查詢,不會有某個串連長時間佔用線程池中的線程,所以幾乎不會影響用戶端請求的回應時間,並且,隨著串連數的增加,線程池中的線程數被控制都在一定範圍內,減輕了系統的壓力。
在有大量長查詢的業務情境下不適合使用線程池
在該情境下,長查詢可能會佔據線程池的所有線程,導致線程池出現效率低效的情況,用戶端設定不能進行串連。
本文永久更新連結地址: