maxscaleのメモリ要件
Maxscaleのメモリ/ CPUに期待される生産要件は何ですか
Maxscaleをクエリのr/wルーターとして実行するために、4 GBのメモリが構成されたサーバーがあり、同じサーバーでレプリケーションマネージャーが実行されています。
数百万行の単一トランザクションで多数の挿入を実行することを発見しました。 1000万行の5GファイルLOADデータ入力ファイルを使用。これと同じ負荷のデータファイルをバックエンドサーバーに対して実行すると、問題が発生することなく直接動作します。
これは、バックエンドサーバー上のmax_allowed_packetです。
MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet'\G
*************************** 1. row ***************************
Variable_name: max_allowed_packet
Value: 16777216
バックエンドサーバーには32 GBのRAMがあり、テストして構成を調整しているため、現在使用しているサービスはありません。
最大スケールサーバーでメモリが不足しています。この大きな挿入セットにより、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
サーバー側では、maxスケールのログに次のように表示されます。
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のRAMを読み取ることがわかります。
このシームは、maxscaleを実行するサーバーが、サーバーを介してクエリを実行するすべてのサービスがピーク時のメモリ使用量で必要とするのと同じ量のメモリを必要とすることを示します。 ReadWriteSplit ルーターを使用する場合。
ReadConnRoute ルーターをテストして、メモリ使用量の要件を下げることができるかどうかを確認します。
更新：
MaxScaleがデータバッファリングに使用するメモリの量は、 writeq_high_water および writeq_low_water パラメータで制限できます。これは、MaxScaleでの過度のメモリ使用に対処する推奨方法です。
MaxScaleはLOAD DATA LOCAL INFILEをバッファリングせずにサーバーに直接ストリーミングする必要があります。
MaxScaleは非ブロッキングIOを使用するため、クライアント側のネットワークのスループットがバックエンド側のネットワークよりも高い場合、一部のバッファリングが発生する可能性があります。これが発生した場合、バックエンド側のネットワークバッファーが空になるまで、MaxScaleがデータを強制的にバッファーする可能性があります。
1.5GBのCSVファイルとVM 1GBのメモリを使用して簡単なテストを行いました。readconnrouteルーターでMaxScaleを実行していました。同じマシンからファイルをロードすると、ピーク時のメモリ使用量が発生しましたMaxScaleプロセスの90％これは、これがMaxScaleのバグであるか、MaxScaleがデータをバッファーする方法の固有の制限のいずれかであると私に思わせます。
この問題を追跡するには、MaxScaleプロジェクトでMariaDB Jiraのバグレポートを開くことをお勧めします： https://jira.mariadb.org/browse/MXS
とりあえず、メモリを追加することは、これに対する許容可能な回避策のように思えます。
サーバーに4GのRAM=があり、LOAD infileに5Gのデータがあった場合、メモリ不足は理にかなった概念です。あまりいいとは言えませんが、合理的です。PREを実装することをお勧めします。 LOAD infileを複数の小さなファイルに分割して処理するためのPROCESSING、またはmaxscaleに拡張リクエストを送信します。