2

我正在使用具有 32GB RAM 和 8 核服务器的专用服务器,使用 Maria DB 10.1,大多数表都是 InnoDB。总 DB 大小小于 2GB,但我认为性能很慢。

以下是my.cnf我正在使用的文件:

[mysqld]
log-error=/home/MySQL_Server/mysql/dedi.server.co.err
datadir=/home/MySQL_Server/mysql
pid-file=/home/MySQL_Server/mysqlmysqld.pid
innodb_file_per_table=1

skip-name-resolve=1
bind-address=127.0.0.1
#skip-networking=1
#query_cache_type=0
query_cache_type=1
innodb_file_per_table=1
default-storage-engine=InnoDB

#query_cache_size=0
query_cache_size=128M
query_cache_limit=256K
query_cache_min_res_unit = 2k

performance_schema=ON
innodb_buffer_pool_size = 1536M
innodb_log_file_size = 140M
innodb_log_files_in_group=2

sort_buffer_size=256k
join_buffer_size=256k
read_buffer_size=256k
read_rnd_buffer_size=256k
thread_stack=256k
mrr_buffer_size=256k

join_cache_level=8

tmp_table_size=64M
max_heap_table_size=64M

table_open_cache=1024
thread_cache_size=32

innodb_buffer_pool_instances=1

innodb_use_sys_malloc = 1

max_connections=500
wait_timeout=300
interactive_timeout=360
#tmpdir=/var/mysqltmp
#max_allowed_packet=268435456

MySQL Tuner 建议如下:

General recommendations:
    Control warning line(s) into /home/MySQL_Server/mysql/dedi.niresh.co.err file
    Control error line(s) into /home/MySQL_Server/mysql/dedi.niresh.co.err file
    Increasing the query_cache size over 128M may reduce performance
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries which have no LIMIT clause
    Consider installing Sys schema from https://github.com/mysql/mysql-sys
Variables to adjust:
    query_cache_size (=0)
    query_cache_type (=0)
    query_cache_size (> 128M) [see warning above]
    tmp_table_size (> 64M)
    max_heap_table_size (> 64M)
    innodb_log_file_size should be (=192M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

我应该关闭查询缓存吗?

有什么额外的建议吗?

4

3 回答 3

8

在几乎所有的生产服务器中,关闭查询缓存是明智的。 对表的每次修改都会导致清除该表的所有QC 条目。桌子越大,花费的时间就越多。128M是危险的高。

通常,明智的做法是设置innodb_buffer_pool_size可用RAM 的 70% 左右。您将其设置为低得多的值,甚至小于数据集的大小。3G 可能会有所帮助。20G 将不再有帮助(直到您的数据集显着增长)。

确保操作系统和 MySQL 都是 64 位版本。

要进行更彻底的分析,请提供

  • 内存大小 (32G)
  • SHOW VARIABLES;
  • SHOW GLOBAL STATUS;(运行至少 24 小时后)

变量和状态分析

更重要的问题

由于您只(?)使用 InnoDB 并且只有 2GB 的数据,因此回应关于innodb_buffer_pool_sizekey_buffer_size

提供更多关于您大量使用DELETE.

利用慢日志查找“最差”的查询。更多细节在这里。这应该可以识别下面提到的 tmp_table 和表扫描问题。

不要打扰使用OPTIMIZE TABLE.

你是如何进行“交易”的?有时使用自动提交,有时使用COMMIT?

细节和其他观察

( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6%-- 使用的 key_buffer 的百分比。高水位线。-- 降低 key_buffer_size 以避免不必要的内存使用。

( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5%-- 用于 InnoDB buffer_pool 的 RAM 百分比

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

( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6%-- 缓冲池空闲 -- buffer_pool_size 大于工作集;可以减少它

( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9%-- 写入必须命中磁盘的请求 -- 检查 innodb_buffer_pool_size

( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9%-- 数据占用缓冲池的百分比 -- 小百分比可能表明 buffer_pool 过大。

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234-- InnoDB 日志轮换之间的分钟数从 5.6.8 开始,可以动态更改;请务必同时更改 my.cnf。-- (轮换间隔 60 分钟的建议有些随意。)调整 innodb_log_file_size。(不能在 AWS 中更改。)

( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879——流失——“不要排队,就去做。” (如果 MySQL 被用作队列。)

( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7%-- 溢出到磁盘的临时表的百分比 -- 可能会增加 tmp_table_size 和 max_heap_table_size;避免斑点等

( Select_scan ) = 871,872 / 533153 = 1.6 /sec-- 全表扫描 -- 添加索引/优化查询(除非它们是小表)

( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9%-- % 的选择进行全表扫描。(可能被存储例程愚弄。)——添加索引/优化查询

( Com_optimize ) = 216 / 533153 = 1.5 /HR-- 执行 OPTIMIZE TABLE 的频率。-- OPTIMIZE TABLE 很少有用,当然不是高频。

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

极端(无评论):

异常小:

Com_commit = 2.5 /HR
Innodb_buffer_pool_pages_made_not_young = 0.15 /sec
Innodb_ibuf_merged_delete_marks = 27 /HR
Innodb_row_lock_time = 8
Innodb_row_lock_time_max = 1
interactive_timeout = 360

异常大:

Com_rollback_to_savepoint = 14 /HR
Handler_savepoint_rollback = 14 /HR
join_cache_level = 8   (This may be unused?  It was removed in 5.6.3, but possibly left in MariaDB 10.1?)

异常字符串:

Innodb_buffer_pool_dump_status = Dumping buffer pool(s) not yet started
Innodb_buffer_pool_load_status = Loading buffer pool(s) not yet started
innodb_checksum_algorithm = INNODB
innodb_cleaner_lsn_age_factor = HIGH_CHECKPOINT
innodb_empty_free_list_algorithm = BACKOFF
innodb_force_load_corrupted = OFF
innodb_foreground_preflush = EXPONENTIAL_BACKOFF
innodb_log_checksum_algorithm = INNODB
myisam_stats_method = NULLS_UNEQUAL
opt_s__engine_condition_pushdown = off
opt_s__mrr = off
opt_s__mrr_cost_based = off

查询缓存

由于它已关闭,因此未设置任何 Qcache 状态值。所以我无法解决最初的问题。如果您想打开QC并重新启动服务器并等待几天,我可以重新分析它。关于命中、修剪等的各种指标可以解决最初的问题。

于 2017-08-13T16:22:11.150 回答
0

附加建议(按照原始问题的要求)。

除了 Rick James 的建议之外,对于 [mysqld] 部分中的 .cfg/ini - 一次一个,请:

    max_seeks_for_key = 64 #而不是让优化器搜索 40 亿个 ndx。
    innodb_log_buffer_size = 64M #从16M降低HDD写入频率
    max_connections = 200 #from 500 因为只使用了 123 (HWM)
    table_open_cache = 4000 #从 1024 保持表打开
    table_definition_cache = 3000 #从 400 保持表定义打开
    open_files_limit = 30000 #从 10000 保持文件打开

您的状态变量指示com_stmt_prepare9,391,427,执行相同的计数但只有 9,388,882 com_stmt_close。可能需要关闭这几千个以释放资源。

请让我们知道您的进展。

JYelton,variable_value 之后的 # 的目的是允许快速复制/粘贴到 [mysqld] 函数的末尾,并了解旧值是什么。感谢您提供有关格式化的提示,我们非常感谢您。

于 2017-09-06T10:55:56.603 回答
0

Yes, Query Cache should be turned OFF with

have_query_cache=0        # from Yes 08/19/2017 to avoid QC overhead, just by its presence
query_cache_size=0        # to ensure QC can not be used
read_rnd_buffer_size=16K  # from 256K 08/19/2017 to minimize wasted RD cycles

Ask why max_allowed_packet=268435456 is necessary. This can cause net_buffer_length to increase in size and lead to memory stress.

于 2017-08-19T23:46:24.967 回答