FreeBSD 与 mysql 的交换使用情况

Question 1

分析...

观察结果：

版本：5.6.43-log
8 GB RAM
正常运行时间 = 14 天 21:34:59
您没有在 Windows 上运行。
运行 64 位版本
您似乎正在运行全部（或大部分）InnoDB。

更重要的问题：

唉，没有任何东西可以解决你的交换问题。无论如何，以下是我的评论：

设置 long_query_time=1 并打开 slowlog。您有一些慢查询，随着表变大，这些查询可能会变得更糟。（16% 的 SELECT 是表扫描。）

slave_skip_errors = 1022 1050 1060 1061 1062 1146 1169 -- 这是扫除很多地毯下的东西！

每个连接执行USE dbname30 次（每秒 14 次）？发生了什么？

增加thread_cache_size至 20。

由于您似乎没有使用 MyISAM，我想知道您为什么要这样做REPAIRs。

是否有第三方软件SHOW TABLES每秒都在做这件事？这会产生一些开销。

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

( innodb_buffer_pool_size / _ram ) = 4096M / 8192M = 50.0%-- 用于 InnoDB 缓冲池的 RAM 百分比

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

( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 4,358,689 / 19741903 = 22.1%-- 必须到达磁盘的写入请求 -- 检查 innodb_buffer_pool_size

( Innodb_dblwr_pages_written/Innodb_pages_written ) = 0/4358689 = 0—— 看起来这些值应该相等？

( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 2,416,485,376 / (1287299 / 3600) / 2 / 512M = 0.00629-- 比率 -- （见会议纪要）

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 1,287,299 / 60 * 512M / 2416485376 = 4,766-- InnoDB 日志轮换之间的分钟数从 5.6.8 开始，可以动态更改；请确保也更改 my.cnf。--（轮换之间建议 60 分钟有点武断。）调整 innodb_log_file_size。（无法在 AWS 中更改。）

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

( innodb_flush_neighbors ) = 1-- 将块写入磁盘时进行小幅优化。-- 对于 SSD 驱动器使用 0；对于 HDD 使用 1。

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

( sync_binlog ) = 0-- 使用 1 来增加安全性，但会花费一些 I/O 成本 =1 可能会导致大量的“查询结束”；=0 可能会导致“binlog 处于不可能的位置”并在崩溃时丢失事务，但速度更快。

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

( max_connections ) = 80-- 最大连接数（线程）。影响各种分配。-- 如果 max_connections 太高，并且各种内存设置都很高，则可能会耗尽 RAM。

( local_infile ) = local_infile = ON -- local_infile = ON 存在潜在的安全问题

( Select_scan ) = 3,833,980 / 1287299 = 3 /sec-- 全表扫描 -- 添加索引/优化查询（除非它们是小表）

( Select_scan / Com_select ) = 3,833,980 / 23827649 = 16.1%-- 执行全表扫描的选择百分比。（可能会被存储例程欺骗。）-- 添加索引/优化查询

( binlog_error_action ) = binlog_error_action = IGNORE_ERROR-- 如果无法写入 binlog，该怎么办。-- IGNORE_ERROR 是默认的，用于向后兼容，但建议使用 ABORT_SERVER。

( binlog_format ) = binlog_format = MIXED—— STATEMENT/ROW/MIXED。ROW 是首选；它可能成为默认值。

( slave_skip_errors ) = slave_skip_errors = 1022 1050 1060 1061 1062 1146 1169-- 忽略哪些错误情况 -- 修改代码比将问题掩盖起来要好。

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

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

( Com_change_db / Connections ) = 17,594,185 / 586795 = 30-- 每个连接的数据库切换 -- （次要）考虑使用“db.table”语法

( Com_change_db ) = 17,594,185 / 1287299 = 14 /sec-- 可能来自 USE 语句。-- 考虑连接 DB、使用 db.tbl 语法、消除虚假的 USE 语句等。

( Threads_created / Connections ) = 16,681 / 586795 = 2.8%-- 流程创建速度

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

异常大：

Com_check = 5.1 /HR
Com_create_procedure = 0.011 /HR
Com_create_trigger = 0.22 /HR
Com_drop_procedure = 0.022 /HR
Com_drop_trigger = 0.22 /HR
Com_repair = 0.0028 /HR
Com_show_tables = 0.98 /sec

异常字符串：

optimizer_trace = enabled=off,one_line=off
optimizer_trace_features = greedy_search=on, range_optimizer=on, dynamic_range=on, repeated_subselect=on
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN
version_compile_machine = amd64

Answer

分析...

观察结果：

版本：5.6.43-log
8 GB RAM
正常运行时间 = 14 天 21:34:59
您没有在 Windows 上运行。
运行 64 位版本
您似乎正在运行全部（或大部分）InnoDB。