问哪个AWS RDS；当前的t3.media超过CPU基线，但不确定下一个最佳选择是什么

EN

状况和变量分析：

意见：

• 版本: 5.6.10
• 4GB内存
• 正常运行时间= 68d 06:45:29
• 您不在Windows上运行。
• 运行64位版本
• 您似乎正在完全(或大部分)运行InnoDB。

The更重要的问题：

innodb_buffer_pool_size可以增加，但不足以引起交换。(如果您没有太多的数据，那么增加它将不会有任何影响。)

如果磁盘是SSD，则将innodb_io_capacity提高到500。( I/O似乎很低，因此这可能不会产生任何影响。)

max_allowed_packet是内存的12%；建议将其降到RAM的1%，除非您需要一个巨大的数据包大小。

有些事情很少显示I/O，因为大部分工作都在CPU中。这进一步推动了对缓慢查询的研究。

查询缓存(query_cache_type)是ON。有一些迹象表明它有很大的活动。这可能是为了“剪枝”而添加到CPU中，也可能是在帮助CPU。(我不知道是哪一个。)建议您更改为DEMAND；同时，将SQL_CACHE添加到可能从QC和SQL_NO_CACHE中受益的查询中。这就在SELECT之后。这些变化将使QC更加专注，从而(希望)减少双方的CPU使用。

如果打开慢速日志(我建议这样做)，一定要将long_query_time降低到1。

Details和其他观察：

( Key_blocks_used * 1024 / key_buffer_size ) = 22 * 1024 / 16M = 0.13% --使用key_buffer的百分比。高水渍。-降低key_buffer_size (现在是16777216)，以避免不必要的内存使用。

( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) ) = ((16M / 0.20 + 1513M / 0.70)) / 4096M = 54.7% --大多数可用的ram都可以用于缓存。-- http://mysql.rjweb.org/doc.php/memory

( innodb_lru_scan_depth ) = 1,024 -- "InnoDB: page_cleaner: 1000的预定循环.“可以通过降低lru_scan_depth来固定

( innodb_io_capacity_max / innodb_io_capacity ) = 2,000 / 200 = 10 --容量:最大/普通--推荐2。最大值应该相当于你的I/O子系统所能处理的IOP。(如果驱动器类型未知，则2000/200可能是合理的一对。)

( innodb_change_buffering ) = innodb_change_buffering = none --在5.6.11/ 5.5.31之前，有一个bug使得=“更改”成为一个更安全的选项。

( innodb_doublewrite ) = innodb_doublewrite = OFF --额外的I/O，但在坠机时额外的安全性。-- FusionIO，Galera，复制品，ZFS都可以.

( Innodb_os_log_written ) = 512 / 5899529 = 0.31 /HR --这是一个指示InnoDB有多忙的指示器。-非常无聊的InnoDB。

( Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group / innodb_log_file_size ) = 512 / (5899529 / 3600) / 2 / 48M = 3.1e-9 -比率-(见记录)

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 5,899,529 / 60 * 48M / 512 = 9.67e+9 -从5.6.8开始的InnoDB日志轮转之间的分钟时间，这可以动态更改；确保也要更改my.cnf。-- (轮流60分钟的建议有点武断)。调整innodb_log_file_size (现在是50331648)。(AWS中无法更改)

( Handler_rollback ) = 68,089,346 / 5899529 = 12 /sec -为什么会有这么多回滚？

( innodb_flush_neighbors ) = 1 --将块写入磁盘时的次要优化。- SSD驱动器使用0；HDD使用1。

( innodb_io_capacity ) = 200 --每秒可以在磁盘上执行I/O操作。100用于慢速驱动器；200用于旋转驱动器；1000-2000用于SSD；乘以RAID因子。

( innodb_adaptive_hash_index ) = innodb_adaptive_hash_index = OFF --通常应该开着。-在某些情况下，情况会更好。另见innodb_adaptive_hash_index_parts (5.7.9之后)和innodb_adaptive_hash_index_partitions (MariaDB和Percona)。ON与罕见的崩溃有牵连(bug 73890)。

( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF --是否记录所有死锁。--如果你被死锁所困扰，把这个打开警告:如果您有很多死锁，这可能会写入很多磁盘。

( max_allowed_packet ) = 512M / 4096M = 12.5%否则，减少innodb_buffer_pool_size (现在1586495488)，以腾出空间。用交换来换取表演是很糟糕的。

( innodb_ft_result_cache_limit ) = 2,000,000,000 / 4096M = 46.6% --全文结果集的字节限制。(可能不是预先分配的，而是增长的？) --降低设置。

( character_set_server ) = character_set_server = latin1 --字符集问题可以通过将character_set_server (现在的latin1)设置为utf8mb4来解决。这是未来的违约。

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

( Qcache_lowmem_prunes ) = 142,717,868 / 5899529 = 24 /sec -- QC中没有房间--增加query_cache_size (现在是88158208)

( Qcache_lowmem_prunes/Qcache_inserts ) = 142,717,868/210841277 = 67.7% --去除率(由于内存不足需要修剪的频率)

( Qcache_not_cached ) = 624,955,002 / 5899529 = 105 /sec -- SQL_CACHE尝试过，但被忽略了--重新考虑缓存；调优qcache

( Qcache_not_cached / (Qcache_hits + Com_select + Qcache_not_cached) ) = 624,955,002 / (608264262 + 835804146 + 624955002) = 30.2% --没有缓存在QC中的选择的百分比。-- QC不是很有用。

( (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache / query_alloc_block_size ) = (88158208 - 1227312) / 34276 / 8192 = 0.31 -- query_alloc_block_size对公式--调整query_alloc_block_size (现在为8192)

( Select_scan ) = 171,787,477 / 5899529 = 29 /sec --全表扫描--添加索引/优化查询(除非它们是小表)

( Select_scan / Com_select ) = 171,787,477 / 835804146 = 20.6% -%的选择执行全表扫描。(可能被存储的例程愚弄了)-添加索引/优化查询

( relay_log_space_limit ) = 1,000,000,000 = 953.7MB --副本上中继日志的最大总大小。(0=unlimited) --让我们来讨论有一个限制的理由。

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

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

Abnormally small:

( Innodb_pages_read + Innodb_pages_written ) / Uptime = 0.0118
Innodb_buffer_pool_bytes_data = 262 /sec
Innodb_buffer_pool_pages_flushed / max(Questions, Queries) = 0
Innodb_buffer_pool_pages_misc = 0
Innodb_buffer_pool_pages_misc * 16384 / innodb_buffer_pool_size = 0
Innodb_data_fsyncs = 0
Innodb_data_read = 192 /sec
Innodb_data_reads = 1.3 /HR
Innodb_data_writes = 1.3 /HR
Innodb_data_writes - Innodb_log_writes - Innodb_dblwr_writes = 1.3 /HR
Innodb_data_written = 0
Innodb_dblwr_pages_written = 0
Innodb_log_write_requests = 0
Innodb_os_log_fsyncs = 0
Innodb_os_log_written / (Uptime / 3600) / innodb_log_files_in_group = 0.0MB
Innodb_pages_read = 42 /HR
Innodb_pages_read + Innodb_pages_written = 42 /HR
Innodb_pages_written = 0
host_cache_size = 128

Abnormally大：

(query_cache_size - Qcache_free_memory) / query_cache_size = 98.6%
1 - Qcache_free_memory / query_cache_size = 98.6%
Com_create_trigger = 0.00061 /HR
Com_drop_trigger = 0.00061 /HR
Com_empty_query = 0.06 /HR
Com_flush = 21 /HR
Com_purge_before_date = 12 /HR
Com_rename_user = 0.00061 /HR
Com_revoke = 0.0012 /HR
Com_show_tables = 1.6 /sec
Handler_read_last = 1.6 /sec
Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads ) = 100.0%
Qcache_total_blocks = 118,191
Qcache_total_blocks * query_cache_min_res_unit / Qcache_queries_in_cache = 14,123
Ssl_accepts = 172
Ssl_default_timeout = 7,200
Ssl_finished_accepts = 166
Ssl_session_cache_misses = 172
Ssl_verify_depth = 1.84e+19
Ssl_verify_mode = 5
back_log / max_connections = 75.6%
innodb_stats_persistent_sample_pages = 128
table_definition_cache = 5,383

Abnormal字符串：

core_file = ON
ft_boolean_syntax = + -><()~*:\"\"&
innodb_checksums = OFF
innodb_fast_shutdown = 1
innodb_use_native_aio = OFF
log_output = TABLE
optimizer_trace = enabled=off,one_line=off
optimizer_trace_features = greedy_search=on, range_optimizer=on, dynamic_range=on, repeated_subselect=on
relay_log_recovery = ON
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN
thread_handling = multiple-connections-per-thread
time_zone = Pacific/Auckland

每秒速率= RPS

参数组中考虑AWS Aurora实例的建议

read_rnd_buffer_size=131072  # from 524288 to reduce handler_read_rnd_next RPS of 98,949
read_buffer_size=512288  # from 262144 to reduce handler_read_next RPS of 1788
log_output=TABLE,FILE  # from TABLE only to have useful visible Slow and General logs
thread_cache_size=32  # from 2 - not sure how you are getting by with only 2
query_cache_type=OFF  # to eliminate CPU cycles used for QC mgmt 24 times a SECOND
query_cache_size=0  # from ~ 84M to no RAM for Query Cache

其他建议，查看配置文件，网络配置文件的联系信息和免费下载实用程序脚本，以协助性能调优。应该调整更多的全球变量。这只是一个开始。

另一个观察，平均每天有一百万次handler_rollback事件，你有什么可能的原因？