gpt4 book ai didi

mysql - 最大可能内存使用量 : 307. 9G(已安装 RAM 的 244%)

转载 作者:行者123 更新时间:2023-11-29 12:22:00 27 4
gpt4 key购买 nike

服务器专用 128 GB RAM 的推荐配置是什么

my.cnf

[mysqld]
datadir="/home/mysql"
default-storage-engine=MyISAM
innodb_file_per_table=1
max_allowed_packet=268435456

innodb_buffer_pool_size = 94G
innodb_buffer_pool_instances = 12
innodb_open_files=20000
innodb_io_capacity=10000
innodb_io_capacity_max=25000
innodb_read_io_threads=8
innodb_write_io_threads=8
innodb_flush_log_at_trx_commit=2
innodb_max_dirty_pages_pct = 90


open_files_limit=100000

interactive_timeout=60
wait_timeout=60

max_connections=20000
max_connect_errors=20000

tmp_table_size=1G
max_heap_table_size=1G

# MyISAM
key_buffer_size = 1G

join_buffer_size = 10M
sort_buffer_size=256K
read_buffer_size=64K
read_rnd_buffer_size=256K

slow-query-log
table_open_cache = 5000

query_cache_type = 1
query_cache_limit = 10M
query_cache_min_res_unit = 1M
query_cache_size = 256M

thread_cache_size = 4

skip_name_resolve=ON

MySQL调整:

>>  MySQLTuner 1.4.0 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
[!!] Currently running unsupported MySQL version 10.0.17-MariaDB-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED +InnoDB +MRG_MyISAM
[--] Data in MyISAM tables: 603M (Tables: 470)
[--] Data in InnoDB tables: 93G (Tables: 563)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[--] Data in MEMORY tables: 60K (Tables: 3)
[!!] Total fragmented tables: 216

-------- Performance Metrics -------------------------------------------------
[--] Up for: 16h 58m 38s (22M q [366.226 qps], 920K conn, TX: 8B, RX: 1B)
[--] Reads / Writes: 35% / 65%
[--] Total buffers: 96.1G global + 10.8M per thread (20000 max threads)
[!!] Maximum possible memory usage: 307.9G (244% of installed RAM)
[OK] Slow queries: 0% (0/22M)
[OK] Highest usage of available connections: 0% (106/20000)
[OK] Key buffer size / total MyISAM indexes: 1.0G/589.3M
[OK] Key buffer hit rate: 99.7% (28M cached / 74K reads)
[OK] Query cache efficiency: 22.8% (1M cached / 6M selects)
[!!] Query cache prunes per day: 1568144
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 46K sorts)
[OK] Temporary tables created on disk: 5% (3K on disk / 66K total)
[OK] Thread cache hit rate: 98% (14K created / 920K connections)
[OK] Table cache hit rate: 104% (1K open / 1K opened)
[OK] Open file limit used: 1% (1K/100K)
[OK] Table locks acquired immediately: 99% (14M immediate / 14M locks)
[OK] InnoDB buffer pool / data size: 94.0G/93.2G
[OK] InnoDB log waits: 0

我有一个很大的数据库,我的CPU使用情况:

http://i.stack.imgur.com/4azch.png

http://i.stack.imgur.com/mm7oZ.png

并拥有 5000 名用户

查询:

SELECT * FROM users ORDER BY RAND();

非常慢,用户中有超过 900k 行

最佳答案

该值是假的。它是根据最坏情况的组合计算得出的。而且它甚至没有包括所有的情况!

然而,这是荒谬的:

max_connections = 20000 [OK] Highest usage of available connections: 0% (106/20000)

2000 很少是一个合理的数字。降低它。如果你确实达到了 max_connections,那么其他地方就会出现问题。无论如何,请注意 Max_used_connections 只有 106。(106 有点高,但不一定是问题。)

tmp_table_size=1G max_heap_table_size=1G

如果您正在运行 20K 个 SELECT,每个 SELECT 都需要 3 个临时表,那么可能需要多达 60TB 的 RAM!因此,降低这两个设置作为防止 RAM 耗尽的额外保护。对于 MySQL 来说,交换是可怕

[!!] Total fragmented tables: 216

忽略这一点;表通常是碎片化的;采取行动是不值得的。

[OK] Slow queries: 0% (0/22M)

将 long_query_time 降低到 2(秒)。

[!!] Query cache prunes per day: 1568144

听起来好像打开查询缓存 (1) 会造成伤害。

[OK] Key buffer size / total MyISAM indexes: 1.0G/589.3M

认真考虑更改为 InnoDB。

关于mysql - 最大可能内存使用量 : 307. 9G(已安装 RAM 的 244%),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28868926/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com