主页 / dba / 问题 / 188589
Accepted
nelaaro
Asked: 2017-10-17 09:37:05 +0800 CST

最大内存要求

  • 772

maxscale 对内存/cpu 的预期生产要求是多少

我们有一个配置了 4 GB 内存的服务器，将 maxscale 作为查询 r/w 路由器运行，并在同一台服务器上运行复制管理器。

我发现在单个事务中进行大量插入，数百万行。具有 1000 万行的 5G 文件使用 LOAD 数据 infile。针对后端服务器直接运行相同的数据 infile 负载，没有任何问题。

这是后端服务器上的 max_allowed_pa​​cket。

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路由器，看看我们是否可以降低内存使用要求。

mysql performance

2 个回答

  1. Best Answer

    更新：

    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

    就目前而言，我会说添加更多内存似乎是一个可以接受的解决方法。

    • 3

  2. 当您的服务器中只有 4G 的 RAM 并且您的 LOAD infile 有 5G 的数据时，内存不足是一个合理的概念。不是很好，但很合理。您可能希望实施 PRE PROCESSING 将 LOAD infile 拆分为多个较小的文件进行处理。或者向 maxscale 提交增强请求。

    • 1

相关问题