Mysql
最大記憶體要求
maxscale 對記憶體/cpu 的預期生產要求是多少
我們有一個配置了 4 GB 記憶體的伺服器，將 maxscale 作為查詢 r/w 路由器執行，並在同一台伺服器上執行複制管理器。
我發現在單個事務中進行大量插入，數百萬行。具有 1000 萬行的 5G 文件使用 LOAD 數據 infile。針對後端伺服器直接執行相同的數據 infile 負載，沒有任何問題。
這是後端伺服器上的 max_allowed_packet。
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet'\G *************************** 1. row *************************** Variable_name: max_allowed_packet Value: 16777216後端伺服器有 32 GB 的記憶體，目前沒有服務在使用它，因為我們仍在對其進行測試和調整配置。
最大規模伺服器記憶體不足。如此大的插入集會導致 maxscale 崩潰。
我在客戶端看到以下錯誤。
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query ERROR 2013 (HY000) at line 1: Lost connection to MySQL server at 'reading initial communication packet', system error: 111 ERROR 2013 (HY000) at line 1: Lost connection to MySQL server at 'reading initial communication packet', system error: 111在伺服器端，我在最大比例日誌中看到以下內容。
2017-10-16 19:06:32 notice : Started MaxScale log flusher. 2017-10-16 19:06:32 notice : MaxScale started with 7 server threads. 2017-10-16 19:15:14 notice : Waiting for housekeeper to shut down. 2017-10-16 19:15:15 notice : Finished MaxScale log flusher. 2017-10-16 19:15:15 notice : Housekeeper shutting down. 2017-10-16 19:15:15 notice : Housekeeper has shut down. 2017-10-16 19:15:15 notice : MaxScale received signal SIGTERM. Exiting. 2017-10-16 19:15:15 notice : MaxScale is shutting down. 2017-10-16 19:15:15 notice : MaxScale shutdown completed. 2017-10-16 19:15:15 MariaDB MaxScale is shut down. ---------------------------------------------------- MariaDB MaxScale /var/log/maxscale/maxscale.log Mon Oct 16 19:15:17 2017 ---------------------------------------------------------------------------- 2017-10-16 19:15:17 notice : Working directory: /var/log/maxscale 2017-10-16 19:15:17 notice : MariaDB MaxScale 2.1.5 started 2017-10-16 19:15:17 notice : MaxScale is running in process 21067 2017-10-16 19:15:17 notice : Configuration file: /etc/maxscale.cnf 2017-10-16 19:15:17 notice : Log directory: /var/log/maxscale 2017-10-16 19:15:17 notice : Data directory: /var/cache/maxscale 2017-10-16 19:15:17 notice : Module directory: /usr/lib64/maxscale 2017-10-16 19:15:17 notice : Service cache: /var/cache/maxscale 2017-10-16 19:15:17 notice : Loading /etc/maxscale.cnf. 2017-10-16 19:15:17 notice : /etc/maxscale.cnf.d does not exist, not reading. 2017-10-16 19:15:17 notice : Loaded module ccrfilter: V1.1.0 from /usr/lib64/maxscale/libccrfilter.so 2017-10-16 19:15:17 notice : [cli] Initialise CLI router module 2017-10-16 19:15:17 notice : Loaded module cli: V1.0.0 from /usr/lib64/maxscale/libcli.so 2017-10-16 19:15:17 notice : [readwritesplit] Initializing statement-based read/write split router module. 2017-10-16 19:15:17 notice : Loaded module readwritesplit: V1.1.0 from /usr/lib64/maxscale/libreadwritesplit.so 2017-10-16 19:15:17 notice : [mysqlmon] Initialise the MySQL Monitor module. 2017-10-16 19:15:17 notice : Loaded module mysqlmon: V1.5.0 from /usr/lib64/maxscale/libmysqlmon.so 2017-10-16 19:15:17 notice : Loaded module MySQLBackend: V2.0.0 from /usr/lib64/maxscale/libMySQLBackend.so 2017-10-16 19:15:17 notice : Loaded module MySQLBackendAuth: V1.0.0 from /usr/lib64/maxscale/libMySQLBackendAuth.so 2017-10-16 19:15:17 notice : Loaded module maxscaled: V2.0.0 from /usr/lib64/maxscale/libmaxscaled.so 2017-10-16 19:15:17 notice : Loaded module MaxAdminAuth: V2.1.0 from /usr/lib64/maxscale/libMaxAdminAuth.so 2017-10-16 19:15:17 notice : Loaded module MySQLClient: V1.1.0 from /usr/lib64/maxscale/libMySQLClient.so 2017-10-16 19:15:17 notice : Loaded module MySQLAuth: V1.1.0 from /usr/lib64/maxscale/libMySQLAuth.so 2017-10-16 19:15:17 notice : No query classifier specified, using default 'qc_sqlite'. 2017-10-16 19:15:17 notice : Loaded module qc_sqlite: V1.0.0 from /usr/lib64/maxscale/libqc_sqlite.so 2017-10-16 19:15:17 notice : Encrypted password file /var/cache/maxscale/.secrets can't be accessed (No such file or directory). Password encryption is not used. 2017-10-16 19:15:17 notice : [MySQLAuth] [Read-Write_Service] Loaded 227 MySQL users for listener Read-Write_Listener. 2017-10-16 19:15:17 notice : Listening for connections at [10.56.229.60]:3306 with protocol MySQL 2017-10-16 19:15:17 notice : Listening for connections at [::]:6603 with protocol MaxScale Admin 2017-10-16 19:15:17 notice : Started MaxScale log flusher. 2017-10-16 19:15:17 notice : MaxScale started with 7 server threads. 2017-10-16 19:15:17 notice : Server changed state: tmsdb-isa-01[10.56.228.64:3306]: new_master. [Running] -> [Master, Running] 2017-10-16 19:15:17 notice : Server changed state: tmsdb-isa-02[10.56.228.65:3306]: new_slave. [Running] -> [Slave, Running] 2017-10-16 19:15:17 notice : Server changed state: tmsdb-rp-01[10.21.228.65:3306]: new_slave. [Running] -> [Slave, Running] 2017-10-16 19:15:17 notice : [mysqlmon] A Master Server is now available: 10.56.228.64:3306我執行 VMSTAT 並註意到伺服器記憶體不足
[root@maxscale-isa-02 ~]# vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 1485828 0 356652 0 0 1 0 0 0 0 0 100 0 0 [root@maxscale-isa-02 ~]# vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 368000 0 356496 0 0 1 0 0 0 0 0 100 0 0 [root@maxscale-isa-02 ~]# vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 173388 0 356512 0 0 1 0 0 0 0 0 100 0 0 [root@maxscale-isa-02 ~]# vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 1 0 103660 0 308088 0 0 1 0 0 0 0 0 100 0 0 [root@maxscale-isa-02 ~]# vmstat -bash: fork: Cannot allocate memory [root@maxscale-isa-02 ~]# vmstat -bash: fork: Cannot allocate memory [root@maxscale-isa-02 ~]# vmstat -bash: fork: Cannot allocate memory [root@maxscale-isa-02 ~]# vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 2478676 0 323508 0 0 1 0 0 0 0 0 100 0 0編輯
我們為最大規模伺服器添加了額外的 4G RAM，總共 4GB 到 8GB。
我們現在可以看到，它可以在導入過程中讀取高達 5G 的記憶體而不會崩潰。
這表明執行 maxscale 的伺服器將需要與通過伺服器執行查詢的所有服務在峰值記憶體使用時所需的記憶體一樣多。使用ReadWriteSplit路由器時。
我們將測試ReadConnRoute路由器，看看我們是否可以降低記憶體使用要求。
更新：
MaxScale 用於數據緩衝的記憶體量可以通過
writeq_high_water和writeq_low_water參數來限制。這是在 MaxScale 中處理過多記憶體使用的推薦方法。MaxScale 應該
LOAD DATA LOCAL INFILE直接將數據流式傳輸到伺服器而不緩衝它。由於 MaxScale 使用非阻塞 IO，如果客戶端網路的吞吐量高於後端網路，則可能會發生一些緩衝。如果發生這種情況，可能是 MaxScale 被迫緩衝數據，直到後端的網路緩衝區被清空。
我使用 1.5GB CSV 文件和具有 1GB 記憶體的 VM 進行了快速測試。我正在使用 readconnroute 路由器執行 MaxScale。從同一台機器載入文件導致 MaxScale 程序的記憶體使用峰值約為 90%。這讓我相信這要麼是 MaxScale 中的錯誤，要麼是 MaxScale 緩衝數據方式的固有限制。
我建議在 MaxScale 項目下打開有關 MariaDB Jira 的錯誤報告以跟踪此問題：https ://jira.mariadb.org/browse/MXS
就目前而言，我會說添加更多記憶體似乎是一個可以接受的解決方法。