mycat 優化

時間 2019-12-05

標籤 mycat 優化简体版

原文原文鏈接

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。 https://blog.csdn.net/u014180504/article/details/76595247
show @@datanode;
該命令用於顯示MyCAT的數據節點的列表，對應schema.xml配置文件的dataNode節點

其中，「NAME」表示dataNode的名稱；「dataHost」表示對應dataHost屬性的值，即數據主機；「ACTIVE」表示活躍鏈接數；「IDLE」表示閒置鏈接數；「SIZE」對應總鏈接數量。

顯示後端物理庫鏈接信息，包括當前鏈接數，端口
Show @@backend

Show @@connection
顯示當前前端客戶端鏈接狀況，已經網絡流量信息

Show @@threadpool
當前線程池的執行狀況，是否有積壓(active_count)以及task_queue_size，後者爲積壓的待處理的SQL，若積壓數目一直保值，則說明後端物理鏈接可能不夠或者SQL執行比較緩慢。

Show @@heartbeat
當先後端物理庫的心跳檢測狀況,RS_CODE爲1表示心跳正常

Show @@datanode
顯示數據節點的訪問狀況，包括每一個數據節點當前活動鏈接數(active),空閒鏈接數（idle）以及最大鏈接數(maxCon) size，EXECUTE參數表示從該節點獲取鏈接的次數，次數越多，說明訪問該節點越多。

Show @@processor
顯示當前processors的處理狀況，包括每一個processor的IO吞吐量(NET_IN/NET_OUT)、IO隊列的積壓狀況(R_QUEY/W_QUEUE)，Socket Buffer Pool的使用狀況BU_PERCENT爲已使用的百分比、BU_WARNS爲Socket Buffer Pool不夠時，臨時創新的新的BUFFER的次數，若百分比常常超過90%而且BU_WARNS>0，則代表BUFFER不夠，須要增大，參見性能調優手冊。

Show @@datasource
顯示數據源的信息，是不是讀寫節點等。

show @@cache
顯示緩存的使用狀況，對於性能監控和調優頗有價值
MAX爲緩存的最大值（記錄個數），CUR爲當前已經在緩存中的數量，ACESS爲緩存讀次數，HIT爲緩存命中次數，PUT 爲寫緩存次數，LAST_XX爲最後操做時間戳，比較重要的幾個參數：CUR：若CUR接近MAX，而PUT大於MAX不少，則代表MAX須要增大，HIT/ACCESS爲緩存命中率，這個值越高越好。

Kill @@connection
殺掉客戶端的鏈接，參數爲鏈接的ID值，經過show @@connection，能夠展現當前鏈接到MyCAT的全部客戶端進程，若某個進程異常，則能夠經過該命令殺掉鏈接，如
KILL @@CONNECTION 1;

JVM調優：

內存佔用分兩部分:Java堆內存+直接內存映射（DirectBuffer佔用），建議堆內存

適度大小，直接映射內存儘量大，兩種一塊兒佔據操做系統的1/2-2/3的內存。

下面以服務器16G內存爲例，Mycat堆內存4G，直接內存映射6G，JVM參數如

下：

-server -Xms4G –Xmx4G   XX:MaxPermSize=64M -XX:MaxDirectMemorySize=6G

用mycat console等命令啓動MyCAT的，JVM參數都在conf\wrapper.con文件中，下面是一段實例：

# Java Additional Parameters

wrapper.java.additional.5=-XX:MaxDirectMemorySize=2G wrapper.java.additional.6=-Dcom.sun.management.jmxremote # Initial Java Heap Size (in MB) wrapper.java.initmemory=2048 # Maximum Java Heap Size (in MB) wrapper.java.maxmemory=2048 操做系統調優：

最大文件句柄數量的修改，設置爲5000-1萬，在Mycat Server和MySQL數據庫的機器上都設置。Linux操做系統對一個進程打開的文件句柄數量的限制(也包含打開的SOCKET數量,可影響mysql的併發鏈接數目).這個值可用ulimit命令來修改，但ulimit命令修改的數值只對當前登陸用戶的目前使用環境有效,系統重啓或者用戶退出後就會失效。

Mysql調優：

最大鏈接數設置爲2000

[mysqld]中有參數

max_connections = 2000

mysql> show global status like 'Max_used_connections';

MySQL服務器過去的最大鏈接數是245，沒有達到服務器鏈接數上限256，應該沒有出現1040錯誤，比較理想的設置是：

Max_used_connections / max_connections * 100% ≈ 85%

最大鏈接數占上限鏈接數的85%左右，若是發現比例在10%如下，MySQL服務器鏈接上線就設置得太高了。

Mycat調優：

Conf/log4j.xml中，日誌級別調整爲至少info級別，默認是debug級別，用於排查錯誤，不能用於性能測試和正式生產中。

conf/server.xml中有以下參數能夠調整： <system>

<!— CPU核心數越多，能夠越大，當發現系統CPU壓力很小的狀況下，能夠適當調大此參數，如4核心的4CPU，能夠設置爲16，24核心的能夠最大設置爲128——>

<property name="processors">1</property>

下面這個參數爲每一個processor的線程池大小，建議能夠是16-64，根據系統能力來測試和肯定。

<property name="processorExecutor">16</property>

</system>

System中如下重要參數也根據狀況進行調整

processorBufferPool ：每一個processor分配的Socket Direct Buffer，用於網絡通訊，每

個processor上管理的全部鏈接共享，processorBufferChunk爲Pool的最小分配單元，每一個POOL的容量即爲processorBufferPool/processorBufferChunk，默認前者爲1024 * 1024 * 16=16M，後者爲4096字節。processorBufferPool參數的調整，須要觀察show @@processor的結果來肯定：

BU_PERCENT爲已使用的百分比、BU_WARNS爲Socket Buffer Pool不夠時，臨時創新的新的BUFFER的次數，若百分比常常超過90%而且BU_WARNS>0，則代表

BUFFER不夠，須要增大processorBufferPool。基本上，鏈接數越多，併發越高，須要的POOL越大，建議BU_PERCENT最大在40-80%之間。

conf/schema.xml中有以下參數能夠調整：

<schema name="TESTDB" checkSQLschema="true"> ，checkSQLschema屬性建議設置爲false，要求開發中，不能在sql中添加數據庫的名稱，如select * from TESTDB.company，這樣能夠優化SQL解析。

<dataHost name="localhost1" maxCon="500" minCon="10" balance="0"

dbType="mysql" dbDriver="native" banlance="0">

<!—最大鏈接池maxCon，能夠改成1000至2000，同一個Mysql實例上的全部datanode節點的共享本dataHost 上的全部物理鏈接à

性能測試的時候，建議minCon=maxCon= mysql max_connections

設爲2000左右。

另外，讀寫分離是否開啓，根據環境的配置來決定。

緩存優化調整：

Show @@cache命令展現了緩存的使用狀況，常常觀察其結果，須要時候進行調整：

通常來講：若CUR接近MAX，而PUT大於MAX不少，則代表MAX須要增大， HIT/ACCESS爲緩存命中率，這個值越高越好。從新調整緩存的最大值之後，觀測指標都會跟隨變化，調整是否有效，主要觀察緩存命中率是否在提高，PUT則降低。

目前緩存服務的配置文件爲：cacheservice.properties，主要使用的緩存爲enhache，enhache.xml裏面設定了enhance緩存的全局屬性，下面定義了幾個緩存：

#used for mycat cache service conf

factory.encache=org.opencloudb.cache.impl.EnchachePooFactory

#key is pool name ,value is type,max size, expire seconds

pool.SQLRouteCache=encache,10000,1800

pool.ER_SQL2PARENTID=encache,1000,1800

layedpool.TableID2DataNodeCache=encache,10000,18000

layedpool.TableID2DataNodeCache.TESTDB_ORDERS=50000,18000

l SQLRouteCache爲SQL 解析和路由選擇的緩存，這個大小基本相對固定，就是全部 SELECT語句的數量。

l ER_SQL2PARENTID爲ER分片時候，根據關聯SQL查詢父表的節點時候用到，沒有用到 ER分片的，這個緩存用不到

l TableID2DataNodeCache，當某個表的分片字段不是主鍵時，緩存主鍵到分片ID的關係，這個是二層的緩存，每一個表定義一個子緩存，如」TEST_ORDERS」，這裏命名爲 schema_tableName（tablename要大寫），當有不少的根據主鍵查詢SQL時，這個緩存每每須要設置比較大，才能更好的提高性能。

Mycat大數據量查詢調優：

1.返回結果比較多

建議調整 frontWriteQueueSize 在系統許可的狀況下加大，默認值*3

這個緣由是由於返回數據太多

這裏作了一個改進，就是超過POOL之後，仍然建立臨時的BUFFER供使用，但這些不回收。。   這樣的狀況下，須要增長BUFFER參數

調整 processorBufferPool = 默認值*2

不夠的狀況下，繼續加大。

配置processors的具體大小。例如，配置processor的個數爲16： server.xml文件中定義

<property name="processors">16</property>

    1

    1

還有一個要討論的就是buffer pool。由於，全部的NIOProcessor共享一個buffer pool。
咱們在server.xml中提到過：
BufferPool的總長度 = bufferPool / bufferChunk
咱們能夠鏈接到Mycat管理端口上，使用show @@processor命令列出全部的processor狀態。
查看列： FREE_BUFFER、TOTAL_BUFFER、BU_PERCENT。
若是FREE_BUFFER的數值太小，則說明配置的buffer pool大小可能不夠。這時候就要手動配置根據公式這個屬性了，pool的大小最好是bufferChunk的整數倍。例如，配置buffer pool的大小爲：5000 server.xml文件中定義

<property name="processorBufferPool">20480000</property>

    1

    1

另外一個buffer pool是線程內buffer pool，這個值能夠根據processors的數值計算出來。具體看server.xml配置詳解。

MySQL通用調優

首先MySQL要絕對避免使用Swap內存，網上有多種辦法，能夠參考。
這裏是MySQL5.6及以上的調優參數，主要是提高多個database/table的寫入和查詢性能：
[mysqld]
當Order By 或者Group By等須要用到結果集時，參數中設置的臨時表的大小小於結果集的大小時，就會將該表放在磁盤上，這個時候在硬盤上的IO要比內銷差不少。所耗費的時間也多不少，mysql 會取min(tmp_table_size, max_heap_table_size)的值，所以兩個設置爲同樣大小，除非是大量使用內存表的狀況，此時max_heap_table_size要設置很大。
max_heap_table_size=200M
tmp_table_size=200M
下面這部分是Select查詢結果集的緩存控制，query_cache_limit表示緩存的Select結果集的最大字節數，這個能夠限制哪些結果集緩存，query_cache_min_res_unit表示結果集緩存的內存單元大小，若須要緩存的SQL結果集很小，好比返回幾條記錄的，則query_cache_min_res_unit越小，內存利用率越高，query_cache_size表示總共用多少
內存緩存Select結果集，query_cache_type則是控制是否開啓結果集緩存，默認0不開啓，1開啓，2爲程序控制方式緩存，好比SELECT SQL_CACHE …這個語句代表此查詢SQL纔會被緩存，對於執行頻率比較高的一些查詢SQL，進行指定方式的緩存，效果會最好。
FLUSH QUERY CACH命令則清理緩存，以更好的利用它的內存，但不會移除緩存，RESET QUERY CACHE 使命從查詢緩存中移除全部的查詢結果。

    #query_cache_type =1
    #query_cache_limit=102400
    #query_cache_size = 2147483648
    #query_cache_min_res_unit=1024

    1
    2
    3
    4

    1
    2
    3
    4

MySQL最大鏈接數，這個一般在1000-3000之間比較合適，根據系統硬件能力，須要對Linux打開的最大文件數作修改
max_connections =2100
下面這個參數是InnoDB最重要的參數，是緩存innodb表的索引，數據，插入數據時的緩衝，儘量的使用內存緩存，對於MySQL專用服務器，一般設置操做系統內存的70%-80%最佳，但須要注意幾個問題，不能致使system的swap空間被佔用，要考濾你的系統使用多少內存，其它應用使用的內在，還有你的DB有沒有myisa引擎，最後減去這些纔是合理的值。
innodb_buffer_pool_size=4G
innodb_additional_mem_pool_size除了緩存表數據和索引外,能夠爲操做所需的其餘內部項分配緩存來提高InnoDB的性能。這些內存就能夠經過此參數來分配。推薦此參數至少設置爲2MB，實際上，是須要根據項目的InnoDB表的數目相應地增長
innodb_additional_mem_pool_size=16M
innodb_max_dirty_pages_pct值的爭議，若是值過大，內存也很大或者服務器壓力很大，那麼效率很下降，若是設置的值太小，那麼硬盤的壓力會增長.
innodb_max_dirty_pages_pct=90
MyISAM表引擎的數據庫會分別建立三個文件：表結構、表索引、表數據空間。咱們能夠將某個數據庫目錄直接遷移到其餘數據庫也能夠正常工做。然而當你使用InnoDB的時候，一切都變了。InnoDB 默認會將全部的數據庫InnoDB引擎的表數據存儲在一個共享空間中：ibdata1，這樣就感受不爽，增刪數據庫的時候，ibdata1文件不會自動收縮，單個數據庫的備份也將成爲問題。一般只能將數據使用mysqldump 導出，而後再導入解決這個問題。innodb_file_per_table=1能夠修改InnoDB爲獨立表空間模式，每一個數據庫的每一個表都會生成一個數據空間。
獨立表空間
優勢：

    每一個表都有自已獨立的表空間。
    每一個表的數據和索引都會存在自已的表空間中。
    能夠實現單表在不一樣的數據庫中移動。
    空間能夠回收（drop/truncate table方式操做表空間不能自動回收）
    對於使用獨立表空間的表，無論怎麼刪除，表空間的碎片不會太嚴重的影響性能，並且還有機會處理。

缺點：

    單表增長比共享空間方式更大。

結論：
共享表空間在Insert操做上有一些優點，但在其它都沒獨立表空間表現好。
實際測試，當一個MySQL服務器做爲Mycat分片表存儲服務器使用的狀況下，單獨表空間的訪問性能要大大好友共享表空間，所以強烈建議使用獨立表空間。
當啓用獨立表空間時，因爲打開文件數也隨之增大，須要合理調整一下 innodb_open_files 、table_open_cache等參數。

    innodb_file_per_table=1
    innodb_open_files=1024
    table_open_cache=1024

    1
    2
    3

    1
    2
    3

Undo Log 是爲了實現事務的原子性，在MySQL數據庫InnoDB存儲引擎中，還用Undo Log來實現多版本併發控制(簡稱：MVCC)。Undo Log的原理很簡單，爲了知足事務的原子性，在操做任何數據以前，首先將數據備份到Undo Log，而後進行數據的修改。若是出現了錯誤或者用戶執行了 ROLLBACK語句，系統能夠利用Undo Log中的備份將數據恢復到事務開始以前的狀態。所以Undo Log的IO性能對於數據插入或更新也是很重要的一個因素。因而，從MySQL 5.6.3開始，這裏出現了重大優化機會：
As of MySQL 5.6.3, you can store InnoDB undo logs in one or more separate undo tablespaces outside of the system tablespace. This layout is different from the default configuration where the undo log is part of the system tablespace. The I/O patterns for the undo log make these tablespaces good candidates to move to SSD storage, while keeping the system tablespace on hard disk storage. innodb_rollback_segments參數在此被重命名爲innodb_undo_logs
所以總共有3個控制參數：innodb_undo_tablespaces代表總共多少個undo表空間文件，innodb_undo_logs定義在一個事務中innodb使用的系統表空間中回滾段的個數。若是觀察到同回滾日誌有關的互斥爭用，能夠調整這個參數以優化性能，默認是128最大值，官方建議先設小，若發現競爭，再調大注意這裏的參數是要安裝MySQL時候初始化InnoDB引擎設置的，innodb_undo_tablespaces參數沒法後期設定。
innodb_undo_tablespaces=128
innodb_undo_directory= SSD硬盤或者另一塊硬盤，跟數據分開
innodb_undo_logs=64
下面是InnoDB的日誌相關的優化選項
innodb_log_buffer_size這是 InnoDB 存儲引擎的事務日誌所使用的緩衝區。相似於 Binlog Buffer，InnoDB 在寫事務日誌的時候，爲了提升性能，也是先將信息寫入 Innofb Log Buffer 中，當知足 innodb_flush_log_trx_commit 參數所設置的相應條件(或者日誌緩衝區寫滿)以後，纔會將日誌寫到文件(或者同步到磁盤)中。innodb_log_buffer_size 不用太大，由於很快就會寫入磁盤。innodb_flush_log_trx_commit的值有0：log buffer中的數據將以每秒一次的頻率寫入到log file中，且同時會進行文件系統到磁盤的同步操做1：在每次事務提交的時候將log buffer 中的數據都會寫入到log file，同時也會觸發文件系統到磁盤的同步; 2：事務提交會觸發log buffer 到log file的刷新，但並不會觸發磁盤文件系統到磁盤的同步。此外，每秒會有一次文件系統到磁盤同步操做。對於非關鍵交易型數據，採用2便可以知足高性能的日誌操做，若要很是可靠的數據寫入保證，則須要設置爲1，此時每一個commit都致使一次磁盤同步，性能降低。
innodb_log_file_size此參數肯定數據日誌文件的大小，以M爲單位，更大的設置能夠提升性能，但也會增長恢復故障數據庫所需的時間。innodb_log_files_in_group分割多個日誌文件，提高並行性。innodb_autoextend_increment對於大批量插入數據也是比較重要的優化參數（單位是M）

    innodb_log_buffer_size=16M
    innodb_log_file_size =256M
    innodb_log_files_in_group=8
    innodb_autoextend_increment=128
    innodb_flush_log_at_trx_commit=2
    #建議用GTID的並行複製，如下是須要主從複製的狀況下，相關的設置參數。
    #gtid_mode = ON
    #binlog_format = mixed
    #enforce-gtid-consistency=true
    300
    #log-bin=binlog
    #log-slave-updates=true

文件簡介：
server.xml：保存了有關MyCAT的配置信息，包括MyCAT對外暴露的schema（包含這個schema對應的帳戶名和密碼），MyCAT server的鏈接池等參數配置
cacheservice.properties：緩存區的配置

server.xml示例：

點擊(此處)摺疊或打開

    <?xml version="1.0" encoding="UTF-8"?>
    
    <!DOCTYPE mycat:server SYSTEM "server.dtd">
    <mycat:server xmlns:mycat="http://org.opencloudb/">
            <system>
            <property name="processors">32</property>
            <property name="processorExecutor">256</property>
            <property name="processorBufferPool">204800000</property>
            <property name="processorBufferChunk">40960</property>
                    
            <property name="maxStringLiteralLength">65535</property>
                    
                    
                    
                    
                    
            <property name="defaultSqlParser">druidparser</property>
            </system>
            
            <user name="test">
                    <property name="password">test</property>
                    <property name="schemas">test</property>
            </user>

            
            

    </mycat:server>

PS：MyCAT對外暴露的schema，是可使用readonly模式的，如上面配置文件中的加紅部分；

processors：用於指定可用線程數，實際上因爲如今的多核CPU和超線程技術，這個值能夠酌情調高，這裏調到了虛擬機核數的八倍，感受稍稍有點高了，實際上四倍or五倍就差很少了

processorExecutor：相似於線程池大小的參數，酌情修改便可，在1.4以後，這個線程池是用來作異步處理邏輯的時候用的，對併發能力的影響相對較小了

processorBufferPool：BufferPool的大小，原則上來講，調高一些會比較好

processorBufferChunk：每個Buffer塊的大小，processorBufferPool/processorBufferChun能夠獲得buffer塊的數量

server調整總結：
processors+processorExecutor會影響到MyCAT可用的線程數，雖然調高點會比較好，可是調的過高會致使頻繁的上下文切換和軟中斷，在實際調整中，用top觀察sys和si的百分比，若是服務器/虛擬機並無什麼不乾淨的後臺程序和其餘的服務在運行，sys在10%-15%以內，si在5%以內是比較理想的狀態；

processorBufferPool+processorBufferChunk影響的server緩存，保持processorBufferChunk大小合理的狀況下，增長buffer塊的數量纔是關鍵；

cacheservice.properties示例：

點擊(此處)摺疊或打開

    #used for mycat cache service conf
    factory.encache=org.opencloudb.cache.impl.EnchachePooFactory
    #key is pool name ,value is type,max size, expire seconds
    pool.SQLRouteCache=encache,1500000,60
    pool.ER_SQL2PARENTID=encache,2000,180
    layedpool.TableID2DataNodeCache=encache,3000,18000
    layedpool.TableID2DataNodeCache.TESTDB_ORDERS=10000,18000

cacheservice是SQL的緩存服務，

SQLRouteCache：sql路由緩存，經過緩存SQL語句的路由信息，下次查詢，不用再路由了，直接從緩存中獲取路由信息，而後發到各個節點執行；
TableID2DataNodeCache ：表主鍵ID的路由緩存，爲每個表建一個緩存池，命名爲TableID2DataNodeCache.TESTDB_表名,緩存的key是id的值，value是節點名；
ER_SQL2PARENTID ： ER關係的緩存目前只是在Insert語句中才會使用緩存，子表插入數據的時候，根據joinKey的值，判斷父表所在分片，從而定位子表分片，分片信息put緩存，以便下次直接獲取

因爲在測試的時候並無對測試表是簡單的區域劃分，因此在測試中對後兩個緩存是沒有利用到的，具體對緩存大小的調整能夠參考SQLRouteCache；

首先貼出結論：SQLRouteCache的大小對具體的QPS有比較大的影響（廢話......._(:з」∠)_），在實際的測試過程當中，保持線程併發不變的狀況下，從100W-300W都有調整過，大概每增長50W，有約15%的增長，直觀來看的話,從100W-300W的增長過程當中，128線程，5張表x5000W行/表的狀況下，QPS範圍從1W5-2W5，然而有一個問題很重要，當這個值增長到比較高後，會頻繁出現極高的sys佔用率，同時vmstat命令下，proc列會有很是高的r和b，直接後果就是MyCAT server自己會出現劇烈的性能波動，在基準測試中，QPS的低谷會降到3000-4000；可是free查看內存使用的時候，並無出現內存不足的狀況，推斷爲MyCAT自己的緩存設計中存在不完善的地方；

具體的設置值，在不斷的測試中，以以前的虛擬機的配置（4核，32G）爲參考，當SQLRouteCache的值設置到180W以上的時候，就會不定時的出現性能波動，爲了保證穩定運行，在基準測試時採用了較低的150W

6.支持內存和外存並存的排序方式，結果集排序能夠達上億規模。此時應注意:

    a.此時前端和後端空閒鏈接超時檢測時間應該設置大些，避免空閒檢測關閉front或者backend
    connection,形成Mysqlclient鏈接丟失時結果集沒法正確。
    b.設置-Xmn值儘量大些，新生代使用UseParallelGC垃圾回收器，-Xss設置512K比較合適，物理內存足夠時，MaxDirectMemorySize儘量設置大些，能夠加快結果集處理時間，

例如:

-Xmx1024m -Xmn512m -XX:MaxDirectMemorySize=2048m -Xss256k -XX:+UseParallelGC

3 processors屬性
這個屬性主要用於指定系統可用的線程數，默認值爲機器CPU核心線程數。
主要影響processorBufferPool、processorBufferLocalPercent、processorExecutor屬性。NIOProcessor的個數也是由這個屬性定義的，因此調優的時候能夠適當的調高這個屬性。
4 processorBufferChunk屬性
這個屬性指定每次分配Socket Direct Buffer的大小，默認是4096個字節。這個屬性也影響buffer pool的長度。若是一次性獲取的數過大buffer不夠用常常出現警告，則能夠適當調大。
5 processorBufferPool屬性
這個屬性指定bufferPool計算比例值。因爲每次執行NIO讀、寫操做都須要使用到buffer，系統初始化的時候會創建必定長度的buffer池來加快讀、寫的效率，減小創建buffer的時間。
Mycat中有兩個主要的buffer池:
- BufferPool
- ThreadLocalPool
BufferPool由ThreadLocalPool組合而成，每次從BufferPool中獲取buffer都會優先獲取ThreadLocalPool中的buffer，未命中以後纔會去獲取BufferPool中的buffer。也就是說ThreadLocalPool是做爲BufferPool的二級緩存，每一個線程內部本身使用的。固然，這其中還有一些限制條件須要線程的名字是由$_開頭。然而，BufferPool上的buffer則是每一個NIOProcessor都共享的。
默認這個屬性的值爲：默認bufferChunkSize(4096) * processors屬性 * 1000
BufferPool的總長度 = bufferPool / bufferChunk。
若bufferPool不是bufferChunk的整數倍，則總長度爲前面計算得出的商 + 1
假設系統線程數爲4，其餘都爲屬性的默認值，則：
bufferPool ＝ 4096 * 4 * 1000
BufferPool的總長度 : 4000 = 16384000 / 4096
這裏寫圖片描述
6 processorBufferLocalPercent屬性
前面提到了ThreadLocalPool。這個屬性就是用來控制分配這個pool的大小用的，但其也並非一個準確的值，也是一個比例值。這個屬性默認值爲100。
線程緩存百分比 = bufferLocalPercent / processors屬性。
例如，系統能夠同時運行4個線程，使用默認值，則根據公式每一個線程的百分比爲25。最後根據這個百分比來計算出具體的ThreadLocalPool的長度公式以下：
ThreadLocalPool的長度 = 線程緩存百分比 * BufferPool長度 / 100
假設BufferPool的長度爲 4000，其餘保持默認值。
那麼最後每一個線程創建上的ThreadLocalPool的長度爲： 1000 = 25 * 4000 / 100
7 processorExecutor屬性
這個屬性主要用於指定NIOProcessor上共享的businessExecutor固定線程池大小。mycat在須要處理一些異步邏輯的時候會把任務提交到這個線程池中。新版本中這個鏈接池的使用頻率不是很大了，能夠設置一個較小的值。
8 sequnceHandlerType屬性
指定使用Mycat全局序列的類型。0爲本地文件方式，1爲數據庫方式，2爲時間戳序列方式，3爲分佈式ZK ID生成器，4爲zk遞增id生成。
從1.6增長兩種ZK的全局ID生成算法。

2 maxCon屬性
指定每一個讀寫實例鏈接池的最大鏈接。也就是說，標籤內嵌套的writeHost、readHost標籤都會使用這個屬性的值來實例化出鏈接池的最大鏈接數。
3 minCon屬性
指定每一個讀寫實例鏈接池的最小鏈接，初始化鏈接池的大小。

Benchmark屬性 Benchmark:mycat鏈接服務降級處理： benchmark 基準, 當前端的總體connection數達到基準值是, 對來自該帳戶的請求開始拒絕鏈接，0或不設表示不限制例如

<property name="benchmark">1000</property>
---------------------
做者：u014180504
來源：CSDN
原文：https://blog.csdn.net/u014180504/article/details/76595247
版權聲明：本文爲博主原創文章，轉載請附上博文連接！前端

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。