Mariadb 10.4 Galera 集群上缺少交换内存

如何解决Mariadb 10.4 Galera 集群上缺少交换内存

我有 3 个节点的 Galera 集群和 MariaDB 10.4.13。每个节点有 32GB RAM 和 2GB Swap。在我大约 1 个月前的 mysql 调优后，每个节点的内存几乎都满了，但我认为还可以。但是最近几天交换大小达到了最大值并且没有下降。我的 my.cnf 看起来像这样：

####记录缓慢

slow_query_log_file=/var/lib/mysql/mysql-slow.log
long_query_time=2
slow_query_log=ON
log_queries_not_using_indexes=ON

############ INNODB 选项
innodb_buffer_pool_size=24000M
innodb_flush_log_at_trx_commit=2
innodb_file_per_table=1
innodb_data_file_path=ibdata1:100M:autoextend
innodb_read_io_threads=4
innodb_write_io_threads=4
innodb_doublewrite=1
innodb_log_file_size=6144M
innodb_log_buffer_size=96M
innodb_buffer_pool_instances=24
innodb_log_files_in_group=2
innodb_thread_concurrency=0
#### innodb_file_format = barracuda
innodb_flush_method = O_DIRECT
#### innodb_locks_unsafe_for_binlog = 1
innodb_autoinc_lock_mode=2
######## 避免在执行例如显示表时更新统计信息
innodb_stats_on_metadata=0
default_storage_engine=innodb
innodb_strict_mode = 0

#### 其他东西，缓冲区等
#### key_buffer_size = 24M
tmp_table_size = 1024M
max_heap_table_size = 1024M
max_allowed_pa​​cket = 512M
#### sort_buffer_size = 256K
#### read_buffer_size = 256K
#### read_rnd_buffer_size = 512K
#### myisam_sort_buffer_size = 8M
skip_name_resolve
内存锁=0
sysdate_is_now=1
最大连接数=500
thread_cache_size=512

query_cache_type = 1
query_cache_size = 512M
query_cache_limit=512K
join_buffer_size = 1M

table_open_cache = 116925
open_files_limit = 233850
table_definition_cache = 58863
table_open_cache_instances = 8

lower_case_table_names=0

通过这种配置，我希望 MariaDB 使用最多，只要它不是关键。 我想查看此配置，可能禁用 query_cache 部分，并调整 InnoDB 值。请给我一些建议，并告诉我交换大小是否足够好，或者可能需要禁用 mysql 以完全使用交换。

解决方法

这些都不一定太大，但可能会发生一些事情使它们变得太大，尤其是结合在一起时：

innodb_buffer_pool_size=24000M  -- quick fix: lower this
      (otherwise it should be a good size)

tmp_table_size = 1024M      -- lower to 1% of RAM
max_heap_table_size = 1024M -- ditto

max_allowed_packet = 512M  -- possibly too big

max_connections=500   -- lower to Max_used_connections or 100

query_cache_type = 1     -- 0 -- QC is not allowed on Galera
query_cache_size = 512M  -- 0 -- ditto

table_open_cache = 116925      -- see how 2000 works
table_definition_cache = 58863 -- ditto

要进一步分析，请在此处提供 GLOBAL STATUS 和 VARIABLES 讨论：http://mysql.rjweb.org/doc.php/mysql_analysis#tuning

,

抱歉，我觉得这里没有什么令人兴奋的地方：

全球状况和变量分析：

观察：

• 版本：10.4.13-MariaDB-log
• 32 GB 内存
• 正常运行时间 = 1 天 15:19:41
• 您没有在 Windows 上运行。
• 运行 64 位版本
• 您似乎完全（或大部分）在运行 InnoDB。

更重要的问题：

低于建议值：

table_open_cache = 10000
tmp_table_size      = 200M
max_heap_table_size = 200M
query_cache_size = 0        -- the high value you have can cause mysterious slowdowns
max_connections = 200
thread_cache_size = 20

硬盘驱动器的 I/O 设置很漂亮；你有固态硬盘吗？

有很多 SHOW 命令——每秒超过一个。也许某些监控工具过于激进？

为什么有这么多赠款？

这是在 Galera 集群中吗？

细节和其他观察：

( Key_blocks_used * 1024 / key_buffer_size ) = 48 * 1024 / 128M = 0.04% -- 使用的 key_buffer 的百分比。高水位。 -- 降低 key_buffer_size（现在为 134217728）以避免不必要的内存使用。

( table_open_cache ) = 116,660 -- 要缓存的表描述符数 -- 一般几百就好了。

( Open_tables / table_open_cache ) = 4,439 / 116660 = 3.8% -- 缓存使用情况（打开表 + tmp 表） -- 可选较低的 table_open_cache（现在为 116660）

( innodb_buffer_pool_instances ) = 24 -- 对于大内存，考虑使用 1-16 个缓冲池实例，每个实例不允许少于 1GB。此外，不超过 CPU 内核数量的两倍。 -- 推荐不超过16个。（10.5开始消失）

( innodb_lru_scan_depth * innodb_buffer_pool_instances ) = 1,024 * 24 = 24,576 -- CPU 使用率指标。 -- 降低任一数字。

( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096 -- 页面清理器每秒的工作量。 -- "InnoDB: page_cleaner: 1000ms 预期循环花费..." 可以通过降低 lru_scan_depth 来解决：考虑 1000 / innodb_page_cleaners（现在是 4）。还要检查交换。

( innodb_page_cleaners / innodb_buffer_pool_instances ) = 4 / 24 = 0.167 -- innodb_page_cleaners -- 推荐将 innodb_page_cleaners（现在是 4）设置为 innodb_buffer_pool_instances（现在是 24） （10.5开始消失）

( innodb_lru_scan_depth ) = 1,024 -- "InnoDB: page_cleaner: 1000ms 预期循环花费..." 可以通过降低 lru_scan_depth 来修复

( innodb_io_capacity ) = 200 -- 刷新时，使用这么多 IOP。 -- 读取可能缓慢或尖锐。

( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 1,065,507 / 1538880 = 69.2% -- 当前未使用的 buffer_pool 的百分比 -- innodb_buffer_pool_size（现在是 25769803776）比必要的大？

( innodb_io_capacity_max / innodb_io_capacity ) = 2,000 / 200 = 10 -- 容量：最大/普通 -- 推荐 2。Max 应该大约等于您的 I/O 子系统可以处理的 IOP。 （如果驱动器类型未知，2000/200 可能是合理的一对。）

( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 7,641,841,664 / 24576M = 29.7% -- 数据占用缓冲池的百分比 -- 很小的百分比可能表明 buffer_pool 太大了。

( innodb_log_buffer_size ) = 96M -- 建议 2MB-64MB，至少与事务中最大的 blob 集一样大。 -- 调整 innodb_log_buffer_size（现在为 100663296）。

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 141,581 / 60 * 6144M / 2470192128 = 6,154 -- InnoDB 日志轮换之间的分钟数从 5.6.8 开始，可以动态更改；一定也要更改my.cnf。 --（轮换间隔60分钟的建议有点武断。）调整innodb_log_file_size（现在是6442450944）。 （无法在 AWS 中更改。）

( default_tmp_storage_engine ) = default_tmp_storage_engine =

( innodb_flush_neighbors ) = 1 -- 将块写入磁盘时的小优化。 -- SSD 驱动器使用 0； 1 个用于硬盘。

( innodb_io_capacity ) = 200 - 磁盘上的每秒 I/O 操作数。 100 用于慢速驱动器； 200 用于旋转驱动器； SSD 1000-2000；乘以 RAID 系数。

( sync_binlog ) = 0 -- 使用 1 来增加安全性，以一些 I/O 为代价=1 可能会导致大量的“查询结束”； =0 可能会导致“binlog at不可能的位置”并在崩溃时丢失交易，但速度更快。

( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF -- 是否记录所有死锁。 -- 如果您受到死锁的困扰，请打开它。注意：如果您有很多死锁，这可能会向磁盘写入大量数据。

( min( tmp_table_size,max_heap_table_size ) ) = (min( 1024M,1024M )) / 32768M = 3.1% -- 当需要 MEMORY 表（每个表）或 SELECT 中的临时表（每个临时表每个 SELECT）时分配的 RAM 百分比。太高可能会导致交换。 -- 将 tmp_table_size（现在是 1073741824）和 max_heap_table_size（现在是 1073741824）减少到 1% 的内存。

( character_set_server ) = character_set_server = latin1 -- 将 character_set_server（现在 latin1）设置为 utf8mb4 可能有助于字符集问题。这是未来的默认设置。

( local_infile ) = local_infile = ON -- local_infile (now ON) = ON 是一个潜在的安全问题

( query_cache_size ) = 512M -- QC 的大小 -- 太小 = 没有多大用处。太大 = 开销太大。推荐0或不超过50M。

( Qcache_hits / (Qcache_hits + Com_select) ) = 8,821 / (8821 + 5602645) = 0.16% -- 命中率 -- 使用 QC 的 SELECTs -- 考虑关闭查询缓存。

( (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache / query_alloc_block_size ) = (512M - 48787272) / 224183 / 16384 = 0.133 -- query_alloc_block_size vs 公式 -- 调整 query_alloc_block_size（现在是 16384）

( tmp_table_size ) = 1024M -- 用于支持 SELECT 的 MEMORY 临时表的大小限制 -- 减小 tmp_table_size（现在为 1073741824）以避免耗尽 RAM。也许不超过 64M。

( Com_admin_commands / Queries ) = 888,691 / 6680823 = 13.3% -- 属于“管理”命令的查询的百分比。 -- 怎么回事？

( Slow_queries / Questions ) = 438,188 / 6557866 = 6.7% -- 频率（占所有查询的百分比） -- 查找慢查询；检查索引。

( log_queries_not_using_indexes ) = log_queries_not_using_indexes = ON -- 是否在慢日志中包含此类。 -- 这会使慢日志变得混乱；把它关掉，这样你就可以看到真正的慢查询。并减少 long_query_time（现在为 2）以捕获最有趣的查询。

( Uptime_since_flush_status ) = 451 = 7m 31s -- 自 FLUSH STATUS（或服务器启动）以来的时间（以秒为单位）。 -- 全球状况的收集时间不够长，无法针对许多问题获得可靠的建议。修复你能做的，然后几个小时后再回来。

( Max_used_connections / max_connections ) = 25 / 500 = 5.0% -- 峰值连接百分比 -- 由于基于 max_connections（现在为 500）可以扩展多个内存因素，因此最好不要将该设置设置得太高。

( thread_cache_size / Max_used_connections ) = 500 / 25 = 2000.0% -- 线程缓存大于您可能的连接数没有任何优势。浪费空间是缺点。

异常小：

Innodb_dblwr_pages_written / Innodb_dblwr_writes = 2.28
aria_checkpoint_log_activity = 1.05e+6
aria_pagecache_buffer_size = 128MB
innodb_buffer_pool_chunk_size = 128MB
innodb_max_undo_log_size = 10MB
innodb_online_alter_log_max_size = 128MB
innodb_sort_buffer_size = 1.05e+6
innodb_spin_wait_delay = 4
lock_wait_timeout = 86,400
performance_schema_max_mutex_classes = 0
query_cache_limit = 524,288

异常大：

Acl_column_grants = 216
Acl_database_grants = 385
Acl_table_grants = 1,877
Innodb_buffer_pool_pages_free = 1.07e+6
Innodb_num_open_files = 9,073
Memory_used_initial = 8.16e+8
Open_table_definitions = 4,278
Open_tables = 4,439
Performance_schema_file_instances_lost = 1,732
Performance_schema_mutex_classes_lost = 190
Performance_schema_table_handles_lost = 570
Qcache_free_blocks = 9,122
Qcache_total_blocks = 457,808
Tc_log_page_size = 4,096
Uptime - Uptime_since_flush_status = 141,130
aria_sort_buffer_size = 256.0MB
auto_increment_offset = 3
gtid_domain_id = 12,000
innodb_open_files = 116,660
max_heap_table_size = 1024MB
max_relay_log_size = 1024MB
min(max_heap_table_size,tmp_table_size) = 1024MB
performance_schema_events_stages_history_size = 20
performance_schema_events_statements_history_size = 20
performance_schema_events_waits_history_size = 20
performance_schema_max_cond_classes = 90
table_definition_cache = 58,863
table_open_cache / max_connections = 233
tmp_memory_table_size = 1024MB
wsrep_cluster_size = 3
wsrep_gtid_domain_id = 12,000
wsrep_local_bf_aborts = 107
wsrep_slave_threads = 32
wsrep_thread_count = 33

异常字符串：

aria_recover_options = BACKUP,QUICK
disconnect_on_expired_password = OFF
gtid_ignore_duplicates = ON
gtid_strict_mode = ON
histogram_type = DOUBLE_PREC_HB
innodb_fast_shutdown = 1
myisam_stats_method = NULLS_UNEQUAL
old_alter_table = DEFAULT
opt_s__optimize_join_buffer_size = on
optimizer_trace = enabled=off
use_stat_tables = PREFERABLY_FOR_QUERIES
wsrep_cluster_status = Primary
wsrep_connected = ON
wsrep_debug = NONE
wsrep_gtid_mode = ON
wsrep_load_data_splitting = OFF
wsrep_provider = /usr/lib64/galera-4/libgalera_smm.so
wsrep_provider_name = Galera
wsrep_provider_options = base_dir = /var/lib/mysql/; base_host = FIRST_NODE_IP; base_port = 4567; cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; evs.auto_evict = 0; evs.causal_keepalive_period = PT1S; evs.debug_log_mask = 0x1; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.info_log_mask = 0; evs.install_timeout = PT7.5S; evs.join_retrans_period = PT1S; evs.keepalive_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.use_aggregate = true; evs.user_send_window = 2; evs.version = 1; evs.view_forget_timeout = P1D; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = galera.cache; gcache.page_size = 128M; gcache.recover = yes; gcache.size = 1024M; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.listen_addr = tcp://0.0.0.0:4567; gmcast.mcast_addr = ; gmcast.mcast_ttl = 1; gmcast.peer_timeout = PT3S; gmcast.segment = 0; gmcast.time_wait = PT5S; gmcast.version = 0; ist.recv_addr = FIRST_NODE_IP; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc.linger = PT20S; pc.npvo = false; pc.recovery = true; pc.version = 0; pc.wait_prim = true; pc.wait_prim_timeout = PT30S; pc.weight = 1; protonet.backend = asio; protonet.version = 0; repl.causal_read_timeout = PT30S; repl.commit_order = 3; repl.key_format = FLAT8; repl.max_ws_size = 2147483647; repl.proto_max = 10; socket.checksum = 2; socket.recv_buf_size = auto; socket.send_buf_size = auto;
wsrep_provider_vendor = Codership Oy 
wsrep_provider_version = 26.4.4(r4599)
wsrep_replicate_myisam = ON
wsrep_sst_auth = ********
wsrep_sst_method = mariabackup
wsrep_start_position = 353e0616-cb37-11ea-b614-be241cab877e:39442474