1

几年来，我一直在使用迭代现有数据库的过程进行自动化的每日数据库备份。

mysqldump --user=${mysql_username} --password=${mysql_password} $db --single-transaction --events -R >> $normal_output_filename

最近我从一个专用服务器（Centos 6、Apache 2.2、php5.6、Mysql 5.0——据我记得）转移到一个带有 Centos 7、Apache 2.4、php 7.2/5.6、MariaDB 5.5 的 VPS）
最近，不时地一些数据库访问速度很慢，最终“超出时间执行”
我有一个 cron 作业，可以在 03:00 之后对所有数据库进行每日备份。
从ps aux | grep mysql我得到

根 15840 0.0 0.0 126772 3456 ？SN 03:09 0:00 mysqldump --user=uuu --password=x xxxxxx information_schema --single-transaction --events -R

这被搁置了几个小时。
有一次，我在 mysqldump 暂停并且没有执行新的数据库备份六天后意识到这个问题。

show status like '%conn%';

不输出任何东西，它保持在保持状态。

mysqladmin -uuser1 -p*** processlist

（user1 是超级用户）列出了近 8000 行被杀死的进程，例如

| 671958 | 用户1 | 本地主机 | 数据库1 | 被杀 | 3 | | | 0.000 |
| 671959 | 用户1 | 本地主机 | 数据库1 | 被杀 | 3 | | | 0.000 |
| 671961 | 用户1 | 本地主机 | 数据库1 | 被杀 | 2 | | | 0.000 |
| 671962 | 用户1 | 本地主机 | 数据库1 | 被杀 | 2 | | | 0.000 |
| 671963 | 用户1 | 本地主机 | 数据库2 | 被杀 | 2 | | | 0.000 |
| 671964 | 用户2 | 本地主机 | 数据库3 | 被杀 | 1 | | | 0.000 |
| 671965 | 用户1 | 本地主机 | | 被杀 | 1 | | | 0.000 |
| 671966 | 用户1 | 本地主机 | | 查询 | 0 | | 显示进程列表 | 0.000 |
+--------+-----+--------------+-----------+------- --+---+---+------------------+----------+

我还没有重新启动mysql服务器。我可以看到一些网站快速加载他们的页面，这些页面有几个数据库访问，而 Horde 和 Roundcube 网络邮件达到超时和错误 500。

我不知道为什么突然（可能是在它发生前几天）进程列表开始随着被杀死的进程而增长，我不知道它们来自哪里。

更新 1：
Contabo 的 VPS，200GB SSD 磁盘。已用 61.93 GiB / 134.78 GiB 可用 / 总计 196.71 GiB
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz，4 核
CentOS Linux 7.7.1908
Linux 3.10.0-1062.9.1.el7.x86_64 on x86_64
At这次：CPU 负载平均 0.88（1 分钟）1.03（5 分钟）0.95（15 分钟）
8GB RAM - 此时：已使用 1.81 GiB / 缓存 2.21 GiB / 总计 7.63 GiB
此时：正常运行时间 2 天 17 小时

更多数据

更新 2

添加thread_handling=pool-of-threads到 my.cnf

4

2 回答 2

1

有些东西变了……

观察：

  • 版本：5.5.64-MariaDB
  • 8 GB 内存
  • 正常运行时间 = 5 天 15:01:27
  • 您没有在 Windows 上运行。
  • 运行 64 位版本
  • 您似乎正在同时运行 MyISAM 和 InnoDB。

更重要的问题：

对于 8GB 以及 MyISAM 和 InnoDB 的混合：

key_buffer_size = 800M
innodb_buffer_pool_size = 3000M

ulimit -n是 1024。但open_files_limit只有 760。我不知道如何让那些提高并保持提高。

innodb_log_file_size = 5M -- 这太低了。但是，更改会很混乱。

每小时 24 次优化是非常高的，即使对于 MyISAM 也是如此。1/月可能更现实。

有查询慢的迹象；请参阅我的博客以了解如何追逐它。

thread_cache_size -- 设置为 30；这可能会显着加快连接速度。

细节和其他观察：

从 MyISAM 到 InnoDB 的转换

( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) ) = ((200M / 0.20 + 128M / 0.70)) / 8192M = 14.4%-- 大部分可用的 ram 应可用于缓存。-- http://mysql.rjweb.org/doc.php/memory

( open_files_limit ) = 760-- ulimit -n -- 要允许更多文件，请更改 ulimit 或 /etc/security/limits.conf 或 sysctl.conf (kern.maxfiles & kern.maxfilesperproc) 或其他内容（取决于操作系统）

( innodb_buffer_pool_size ) = 128M-- InnoDB 数据 + 索引缓存 -- 128M（旧的默认值）小得可怜。

( innodb_log_buffer_size / innodb_log_file_size ) = 8M / 5M = 160.0%-- 缓冲区在 RAM 中；文件在磁盘上。-- buffer_size 应该更小和/或 file_size 应该更大。

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

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

( innodb_stats_on_metadata ) = innodb_stats_on_metadata = ON- 触摸统计数据时重新分析表格。-- ON 可能会减慢某些 SHOW 和 information_schema 访问。

( innodb_recovery_update_relay_log ) = innodb_recovery_update_relay_log = OFF-- 有助于避免崩溃后的复制错误。

( innodb_import_table_from_xtrabackup ) = 0-- 对可传输表空间有用

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

( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF-- 是否记录所有死锁。-- 如果你被死锁困扰，打开它。注意：如果你有很多死锁，这可能会写入很多磁盘。

( character_set_server ) = character_set_server = latin1 -- 将 character_set_server（现在是 latin1）设置为 utf8mb4 可以帮助解决字符集问题。那是未来的默认值。

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

( Created_tmp_disk_tables / Created_tmp_tables ) = 98,045 / 181066 = 54.1%-- 溢出到磁盘的临时表的百分比 -- 可能增加 tmp_table_size（现在为 16777216）和 max_heap_table_size（现在为 16777216）；改进指标；避免斑点等

( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (388211 + 19570 + 3890 + 330) / 0 = INF-- 每个提交的语句（假设所有 InnoDB） -- 低：可能有助于在事务中将查询分组；高：长期交易使各种事情紧张。

( Select_scan ) = 945,274 / 486087 = 1.9 /sec-- 全表扫描 -- 添加索引/优化查询（除非它们是小表）

( Com_optimize ) = 3,202 / 486087 = 24 /HR-- 执行 OPTIMIZE TABLE 的频率。-- OPTIMIZE TABLE 很少有用，当然不是高频。

( binlog_format ) = binlog_format = STATEMENT-- 声明/行/混合。-- ROW 是 5.7 (10.3) 的首选

( expire_logs_days ) = 0-- 多久自动清除 binlog（经过这么多天） -- 太大（或为零）= 消耗磁盘空间；太小 = 需要快速响应网络/机器崩溃。（如果 log_bin（现在关闭）=关闭，则不相关）

( log_slow_queries ) = log_slow_queries = OFF-- 是否记录慢查询。（5.1.29、5.6.1之前）

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

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

( back_log ) = 50-- （自 5.6.6 起自动调整大小；基于 max_connections） -- 提高到 min(150, max_connections (现在为 151)) 在进行大量连接时可能会有所帮助。

( Com_change_db / Connections ) = 8,920,272 / 2392646 = 3.73-- 每个连接的数据库切换 --（次要）考虑使用“db.table”语法

( Com_change_db ) = 8,920,272 / 486087 = 18 /sec-- 可能来自 USE 语句。-- 考虑与 DB 连接，使用 db.tbl 语法，消除虚假的 USE 语句等。

你有一半的查询缓存。您应该同时设置 query_cache_type = OFF 和 query_cache_size = 0 。（根据传言）QC 代码中有一个“错误”，除非您关闭这两个设置，否则某些代码会保持打开状态。

异常小：

Innodb_adaptive_hash_non_hash_searches = 46 /sec
Innodb_buffer_pool_bytes_data = 272 /sec
Innodb_checkpoint_max_age = 7.78e+6
Innodb_master_thread_10_second_loops = 17,345
Innodb_master_thread_1_second_loops = 184,979
Innodb_master_thread_sleeps = 0.38 /sec
Innodb_mem_adaptive_hash = 4.17e+6
Innodb_mem_dictionary = 4.15e+6
Innodb_mem_total = 131.4MB
net_buffer_length = 8,192

异常大：

Com_check = 24 /HR
Com_create_db = 0.15 /HR
Com_drop_db = 0.044 /HR
Com_rename_table = 0.49 /HR
Com_show_charsets = 16 /HR
Com_show_events = 17 /HR
Com_show_storage_engines = 1.9 /HR
Feature_gis = 1.1 /HR
Feature_locale = 20 /HR
Threadpool_idle_threads = 7
Threadpool_threads = 8

异常字符串：

binlog_checksum = NONE
innodb_fast_shutdown = 1
opt_s__engine_condition_pushdown = off
opt_s__extended_keys = off
thread_handling = pool-of-threads
于 2020-01-22T00:34:57.817 回答
1

以下不直接回答你问的问题，但指出了一些非常低的设置和MyISAM的用法。我不知道切换到 InnoDB 和/或增加一些设置是否会有所帮助。

请注意，转储 MyISAM 表本质上会阻止用户进行数据库工作。（另一方面，也许您的数据集相当小并且活动相当低。）

观察：

  • 版本：5.5.64-MariaDB
  • 8 GB 内存
  • 正常运行时间 = 21:05:35；一些 GLOBAL STATUS 值可能还没有意义。
  • 您没有在 Windows 上运行。
  • 运行 64 位版本
  • 您似乎完全（或大部分）运行 MyISAM。

更重要的问题：

你应该从 MyISAM 迁移到 InnoDB；请参阅从 MyISAM 到 InnoDB 的转换

看看你是否可以提出以下问题（下面有更多讨论）：

open_files_limit = 2000
table_open_cache = 300
key_buffer_size = 200M
innodb_buffer_pool_size = 600M  -- after moving tables to InnoDB

OPTIMIZE TABLE是一项不常见的任务；你做得太频繁了。

细节和其他观察：

( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) ) = ((16M / 0.20 + 128M / 0.70)) / 8192M = 3.2%-- 大部分可用的 ram 应可用于缓存。-- http://mysql.rjweb.org/doc.php/memory

( open_files_limit ) = 760-- ulimit -n -- 要允许更多文件，请更改 ulimit 或 /etc/security/limits.conf 或 sysctl.conf (kern.maxfiles & kern.maxfilesperproc) 或其他内容（取决于操作系统）

( table_open_cache ) = 64-- 要缓存的表描述符的数量 -- 几百通常是好的。

( innodb_buffer_pool_size ) = 128M-- InnoDB 数据 + 索引缓存 -- 128M（旧的默认值）小得可怜。

( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 5,578 / 8191 = 68.1%-- 当前未使用的 buffer_pool 的百分比 -- innodb_buffer_pool_size（现在为 134217728）是否大于所需？

( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF-- 是否记录所有死锁。-- 如果你被死锁困扰，打开它。注意：如果你有很多死锁，这可能会写入很多磁盘。

( join_buffer_size ) = 131,072 / 8192M = 0.00%-- 每个线程 0-N。可以加速 JOIN（更好地修复查询/索引）（所有引擎）用于索引扫描、范围索引扫描、全表扫描、每个完整 JOIN 等。 -- 如果很大，请减小 join_buffer_size（现在为 131072）以避免内存压力. 建议少于 1% 的 RAM。如果很小，则将 RAM 增加到 0.01% 以改进一些查询。

( innodb_buffer_pool_populate ) = OFF = 0-- NUMA 控制

( query_prealloc_size ) = 8,192 / 8192M = 0.00%-- 用于解析。内存百分比

( query_alloc_block_size ) = 8,192 / 8192M = 0.00%-- 用于解析。内存百分比

( character_set_server ) = character_set_server = latin1 -- 将 character_set_server（现在是 latin1）设置为 utf8mb4 可以帮助解决字符集问题。那是未来的默认值。

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

( Key_writes / Key_write_requests ) = 5,804 / 9232 = 62.9%-- 写入的 key_buffer 有效性 -- 如果你有足够的 RAM，增加 key_buffer_size（现在是 16777216）是值得的。

( Created_tmp_disk_tables / Created_tmp_tables ) = 13,250 / 18108 = 73.2%-- 溢出到磁盘的临时表的百分比 -- 可能增加 tmp_table_size（现在为 16777216）和 max_heap_table_size（现在为 16777216）；改进指标；避免斑点等

( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (68440 + 1927 + 425 + 0) / 0 = INF-- 每个提交的语句（假设所有 InnoDB） -- 低：可能有助于在事务中将查询分组；高：长期交易使各种事情紧张。

( Select_scan ) = 165,862 / 75935 = 2.2 /sec-- 全表扫描 -- 添加索引/优化查询（除非它们是小表）

( Com_optimize ) = 464 / 75935 = 22 /HR-- 执行 OPTIMIZE TABLE 的频率。-- OPTIMIZE TABLE 很少有用，当然不是高频。

( binlog_format ) = binlog_format = STATEMENT-- 声明/行/混合。-- ROW 是 5.7 (10.3) 的首选

( expire_logs_days ) = 0-- 多久自动清除 binlog（经过这么多天） -- 太大（或为零）= 消耗磁盘空间；太小 = 需要快速响应网络/机器崩溃。（如果 log_bin（现在关闭）=关闭，则不相关）

( innodb_autoinc_lock_mode ) = 1-- Galera: 欲望 2 -- 2 = "interleaved"; 1 =“连续”是典型的；0 =“传统”。-- 加莱拉的愿望 2；2 需要 BINLOG_FORMAT=ROW 或 MIXED

( log_slow_queries ) = log_slow_queries = OFF-- 是否记录慢查询。（5.1.29、5.6.1之前）

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

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

( back_log ) = 50-- （自 5.6.6 起自动调整大小；基于 max_connections） -- 提高到 min(150, max_connections (现在为 151)) 在进行大量连接时可能会有所帮助。

( Com_change_db / Connections ) = 1,278,567 / 363881 = 3.51-- 每个连接的数据库切换 --（次要）考虑使用“db.table”语法

( Com_change_db ) = 1,278,567 / 75935 = 17 /sec-- 可能来自 USE 语句。-- 考虑与 DB 连接，使用 db.tbl 语法，消除虚假的 USE 语句等。

( Threads_running / thread_cache_size ) = 1 / 0 = INF-- 线程：当前/缓存（使用线程池时不相关）- 优化查询

您有一半的查询缓存。您应该同时设置 query_cache_type = OFF 和 query_cache_size = 0 。（根据传言）QC 代码中有一个“错误”，除非您关闭这两个设置，否则某些代码会保持打开状态。

异常小：

( Innodb_pages_read + Innodb_pages_written ) / Uptime = 0.0672
(innodb_buffer_pool_size + innodb_log_buffer_size + key_buffer_size + query_cache_size + Max_used_connections * (thread_stack + net_buffer_length)) / _ram = 1.9%
Innodb_adaptive_hash_non_hash_searches = 1.1 /sec
Innodb_buffer_pool_pages_flushed / max(Questions, Queries) = 0.00056
Innodb_buffer_pool_pages_made_young = 0
Innodb_buffer_pool_pages_old = 943
Innodb_buffer_pool_read_ahead = 0
Innodb_checkpoint_max_age = 7.78e+6
Innodb_ibuf_merged_inserts = 0
Innodb_ibuf_merges = 0
Innodb_lsn_current = 2.52e+8
Innodb_lsn_flushed = 240.6MB
Innodb_lsn_last_checkpoint = 2.52e+8
Innodb_master_thread_10_second_loops = 945
Innodb_master_thread_1_second_loops = 10,439
Innodb_master_thread_sleeps = 0.14 /sec
Innodb_mem_adaptive_hash = 2.25e+6
Innodb_mem_dictionary = 2.1e+6
Innodb_mem_total = 131.4MB
Innodb_pages_read + Innodb_pages_written = 0.067 /sec
Innodb_x_lock_spin_waits = 0.047 /HR
Open_tables = 64
net_buffer_length = 8,192

异常大：

Com_check = 22 /HR
Com_show_charsets = 28 /HR
Com_show_events = 1.2 /HR
Feature_gis = 0.66 /HR

异常字符串：

binlog_checksum = NONE
innodb_fast_shutdown = 1
opt_s__engine_condition_pushdown = off
opt_s__extended_keys = off
于 2020-01-17T02:12:12.040 回答