MS Azure Mysql 灵活服务器消耗所有内存

Question

我有在 Azure 中运行的 MS Azure MySQL 灵活服务器，具有 4vCPU 和 32GB RAM。

它消耗了它获得的所有内存，并且在低于 32GB 的配置下肯定会令人窒息，这对于使用来说似乎有点过分了。大部分工作量是插入/更新数据。

我试图了解到底是什么在使用我的内存，并假设innodb_buffer_pool_size这是一个问题，但即使在 32GB 主机和innodb_buffer_pool_size= 6.5GB 内存上也会很快耗尽。

基本内存故障排除指南没有给我明确的答案。我怀疑tmp_tables但无法弄清楚如何确定剩余内存分配的确切位置。

Microsoft 支持部门无法告诉我文档中不起作用的解决方案或建议。

这是基本内存分配检查显示的内容：

我尝试了基于其他类似线程的大部分检查。我尝试减少主机中的内存大小，但在 16GB 的情况下，系统内存不足，在 Azure 中缺少指标。

这是一个 Azure PaaS 服务，但我猜它在 Linux 上运行，存储作为服务的一部分提供。

---

SELECT COUNT(*), sum(data_length), sum(index_length), sum(data_free)
FROM information_schema.tables;

数数（*）	总和（数据长度）	总和（索引长度）	总和（无数据）
668	106841464051	17000455168	776994816

SHOW GLOBAL STATUS;

https://justpaste.it/7oj0m

SHOW GLOBAL VARIABLES;

https://justpaste.it/5b8rb

SHOW FULL PROCESSLIST;

现在只有我的会话在进程列表中

STATUS;

https://justpaste.it/1u9z5

SHOW ENGINE INNODB STATUS; 

https://justpaste.it/6mr1z

Answer 1

Analysis of GLOBAL STATUS and VARIABLES:

观察结果：

• 版本：5.7.40-log
• 32 GB 内存
• 正常运行时间 = 1 天 03:53:33
• 43.6 PSC

更重要的问题：

嗯，没什么紧急的事情。下面是一些比较重要的：

innodb_lru_scan_depth = 256

如果使用 SSD，而不是 HDD：

innodb_io_capacity = 500
innodb_io_capacity_max = 4000
max_allowed_packet = 50M
max_connections = 50

详细信息和其他观察结果：

( table_open_cache ) = 10,000-- 要缓存的表描述符的数量 -- 通常几百个就足够了。

( binlog_cache_size * max_connections ) = (8M * 300) / 32768M = 7.3%-- RAM 用于缓存传输至二进制日志的事务。-- 减少 binlog_cache_size （现在为 8388608）和/或 max_connections （现在为 300）

( innodb_buffer_pool_size ) = 6,144M / 32768M = 18.8%-- 用于 InnoDB buffer_pool 的 RAM % -- 设置为可用 RAM 的大约 70%。（太低效率较低；太高则存在交换风险。）

( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096-- 页面清理器每秒的工作量。--“InnoDB：page_cleaner：1000ms预期循环花费了...”可以通过降低lru_scan_深度来修复：考虑1000 / innodb_page_cleaners（现在为4）。还要检查是否有交换。

( innodb_lru_scan_depth ) = 1,024-- innodb_lru_scan_depth 是一个命名非常糟糕的变量。更好的名称是 innodb_free_page_target_per_buffer_pool。它是 InnoDB 尝试在每个缓冲池实例中保持空闲的页数，以加速读取和页创建操作。--“InnoDB：page_cleaner：1000ms预期循环花费了...”可以通过降低lru_scan_深度来修复

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

( Innodb_buffer_pool_read_ahead_evicted / Innodb_buffer_pool_read_ahead ) = 34,621 / 50483 = 68.6%-- read_ahead 的实用程序。-- 关闭 innodb_random_read_ahead （现在关闭）。

( innodb_doublewrite ) = innodb_doublewrite = OFF-- ON 导致额外的 I/O，但在崩溃时具有额外的安全性。-- 对于 FusionIO、Galera、Replicas、ZFS、EXT4，关闭即可。

( innodb_flush_method ) = innodb_flush_method = fsync-- InnoDB 应该如何要求操作系统写入块。建议使用 O_DIRECT 或 O_ALL_DIRECT (Percona) 以避免双缓冲。（至少对于 Unix 而言。）有关 O_ALL_DIRECT 的警告，请参阅 chrischandler

( innodb_io_capacity ) = 200- 磁盘上每秒的 I/O 操作数。慢速行驶时为 100；200 用于旋转驱动器；SSD 1000-2000；乘以 RAID 系数。限制每秒写入 IO 请求 (IOPS)。-- 对于初学者：硬盘：200；固态硬盘：2000。

( innodb_flush_log_at_trx_commit ) = 1-- 1 = 安全；2 = 更快——（由您决定）使用 1 以及sync_binlog（现在为 1）=1 以获得最高级别的容错能力。0 最适合速度。2是0和1之间的折衷。

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

( innodb_purge_threads ) = 1-- 清理历史列表的线程数。-- 如果写入量较多，建议在5.6和10.0及以上版本中使用4。

( max_allowed_packet ) = 1G / 32G = 3.1% -- 如果没有大的 blob（等）要加载，则减小该值。否则减小 innodb_buffer_pool_size （现在为 6442450944）以腾出空间。交换对于性能来说非常糟糕。

( character_set_client ) = character_set_client = latin1-- -- 如果您要使用西欧以外地区的文本，请考虑切换到 utf8mb4。（超出了本次讨论的范围。）

( character_set_connection ) = character_set_connection = latin1 --

( character_set_results ) = character_set_results = latin1--

( local_infile ) = local_infile = ON -- local_infile（现在为ON）= ON是一个潜在的安全问题

( Com_delete / Com_insert ) = 275,515 / 10556 = 2610.0%-- 删除/插入（作为一个 pct）。（忽略加载、替换等）

( Com__biggest ) = Com__biggest = Com_update-- 哪个“Com_”指标最大。-- 通常是 Com_select（现在是 440739）。如果是别的，那么它可能是一个草率的平台，也可能是别的什么。

( relay_log_space_limit ) = 1024M-- 副本上中继日志的最大总大小。(0=无限制)——让我们讨论一下限制的理由。

( slow_query_log ) = slow_query_log = OFF-- 是否记录慢速查询。(5.1.12)

( long_query_time ) = 10-- 用于定义“慢速”查询的截止时间（秒）。-- 建议2

( log_slow_slave_statements ) = log_slow_slave_statements = OFF-- (5.6.11, 5.7.1) 默认情况下，复制语句不会出现在慢日志中；这导致他们表现出来。-- 在慢日志中查看可能干扰副本读取的写入会很有帮助。

( Max_used_connections / max_connections ) = 7 / 300 = 2.3%-- 连接的峰值百分比 -- 由于多个内存因素可以根据 max_connections（现在为 300）进行扩展，因此最好不要将该设置设置得太高。

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

异常小：

(Com_select + Qcache_hits) / (Com_insert + Com_update + Com_delete + Com_replace) = 0.115
Com_show_fields = 0
Innodb_buffer_pool_pages_misc = 0
Innodb_buffer_pool_pages_misc * 16384 / innodb_buffer_pool_size = 0
Innodb_dblwr_pages_written = 0
net_buffer_length / max_allowed_packet = 0.00%

异常大：

Com_change_repl_filter = 0.036 /HR
Com_lock_tables_for_backup = 0.072 /HR
Com_purge_before_date = 12 /HR
Com_show_master_status = 0.033 /sec
Com_show_open_tables = 0.036 /HR
Com_show_plugins = 18 /HR
Com_show_slave_status = 0.033 /sec
Com_show_status = 0.24 /sec
Com_show_warnings = 18 /HR
Com_slave_stop = 0.036 /HR
Handler_commit/Questions = 118.6%
Performance_schema_file_handles_lost = 248
Ssl_accepts = 14,343
Ssl_default_timeout = 7,200
Ssl_finished_accepts = 14,343
Ssl_session_cache_misses = 13,168
Ssl_session_cache_overflows = 211
Ssl_used_session_cache_entries = 49
Ssl_verify_depth = 1.84e+19
Ssl_verify_mode = 5
back_log / max_connections = 943.7%
binlog_cache_size = 8.39e+6
binlog_transaction_dependency_history_size = 32,000
net_read_timeout = 120
net_write_timeout = 240
slave_parallel_workers = 32
table_definition_cache = 10,000
table_open_cache / max_connections = 33.3

异常字符串：

auto_generate_certs = OFF
binlog_row_image = MINIMAL
binlog_transaction_dependency_tracking = WRITESET
core_file = ON
delay_key_write = OFF
disabled_storage_engines = MyISAM,MRG_MyISAM,BLACKHOLE,FEDEATED,ARCHIVE
innodb_fast_shutdown = 1
innodb_tmpdir = /mnt/temp
log_bin_trust_function_creators = ON
log_output = NONE
log_syslog = ON
lower_case_file_system = ON
lower_case_table_names = 1
opt_tf__dynamic_range = 
optimizer_trace = enabled=off,one_line=off
optimizer_trace_features = greedy_search=on,range_optimizer=on,dynamic_range=
relay_log_recovery = ON
require_secure_transport = ON
sha256_password_auto_generate_rsa_keys = OFF
slave_parallel_type = LOGICAL_CLOCK
slave_preserve_commit_order = ON
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN
sql_slave_skip_counter = 0
time_zone = +00:00