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"?>
    <!-- - - Licensed under the Apache License, Version 2.0 (the "License");
            - you may not use this file except in compliance with the License. - You
            may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0
            - - Unless required by applicable law or agreed to in writing, software -
            distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT
            WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the
            License for the specific language governing permissions and - limitations
            under the License. -->
    <!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>
                    <!--默認是65535 64K 用於sql解析時最大文本長度 -->
            <property name="maxStringLiteralLength">65535</property>
                    <!--<property name="sequnceHandlerType">0</property>-->
                    <!--<property name="backSocketNoDelay">1</property>-->
                    <!--<property name="frontSocketNoDelay">1</property>-->
                    <!--<property name="processorExecutor">16</property>-->
                    <!--
                            <property name="mutiNodeLimitType">1</property> 0：開啟小數量級（默認） ；1：開啟億級數據排序
                            <property name="mutiNodePatchSize">100</property> 億級數量排序批量
                            <property name="processors">32</property> <property name="processorExecutor">32</property>
                            <property name="serverPort">8066</property> <property name="managerPort">9066</property>
                            <property name="idleTimeout">300000</property> <property name="bindIp">0.0.0.0</property>
                            <property name="frontWriteQueueSize">4096</property> <property name="processors">32</property> -->
            <property name="defaultSqlParser">druidparser</property>
            </system>
            <!--
            <user name="root">
                    <property name="password">root</property>
                    <property name="schemas">test</property>
            </user>

            <user name="root_read">
                    <property name="password">root_read</property>
                    <property name="schemas">test</property>
                    <property name="readOnly">true</property>
            </user>
            -->
            <user name="test">
                    <property name="password">test</property>
                    <property name="schemas">test</property>
            </user>

            <!-- <cluster> <node name="cobar1"> <property name="host">127.0.0.1</property>
                    <property name="weight">1</property> </node> </cluster> -->
            <!-- <quarantine> <host name="1.2.3.4"> <property name="user">test</property>
                    </host> </quarantine> -->

    </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
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！