2

我正在使用 MySQLTuner.pl 来优化我的网站....虽然我不完全确定如何解决其中一些问题,并且想知道是否有人可以帮助我。

如果需要使用以下 MySQL 设置的 MySQL,我有大约 4GB 的可用内存:

key_buffer      = 100M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 800

myisam-recover         = BACKUP
max_connections        = 750
table_cache            = 125000
thread_concurrency     = 500

query_cache_type=1
query_cache_limit = 128M
query_cache_size        = 128M

tmp_table_size = 300M
max_heap_table_size = 300M
innodb_buffer_pool_size = 2G
innodb_file_per_table = 0
innodb_flush_log_at_trx_commit = 2

这是我的调谐器的输出

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.24-0ubuntu0.12.04.1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 7K (Tables: 10)
[--] Data in InnoDB tables: 27M (Tables: 5)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 5

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 15d 5h 4m 19s (1B q [1K qps], 208M conn, TX: 172B, RX: 98B)
[--] Reads / Writes: 71% / 29%
[--] Total buffers: 2.5G global + 2.7M per thread (750 max threads)
[OK] Maximum possible memory usage: 4.5G (57% of installed RAM)
[OK] Slow queries: 0% (0/1B)
[OK] Highest usage of available connections: 15% (118/750)
[OK] Key buffer size / total MyISAM indexes: 100.0M/119.0K
[OK] Key buffer hit rate: 100.0% (22M cached / 0 reads)
[!!] Query cache efficiency: 0.1% (703K cached / 519M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (13 temp sorts / 13M sorts)
[OK] Temporary tables created on disk: 25% (4M on disk / 18M total)
[OK] Thread cache hit rate: 99% (752 created / 208M connections)
[OK] Table cache hit rate: 74% (992 open / 1K opened)
[OK] Open file limit used: 0% (68/250K)
[OK] Table locks acquired immediately: 100% (216M immediate / 216M locks)
[OK] InnoDB data size / buffer pool: 27.8M/2.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
Variables to adjust:
query_cache_limit (> 128M, or use smaller result sets)

的输出SHOW STATUS LIKE '%cache%'

Binlog_cache_disk_use   0
Binlog_cache_use    0
Binlog_stmt_cache_disk_use  0
Binlog_stmt_cache_use   0
Com_assign_to_keycache  0
Qcache_free_blocks  19
Qcache_free_memory  134026728
Qcache_hits 704192
Qcache_inserts  143569852
Qcache_lowmem_prunes    0
Qcache_not_cached   11043040
Qcache_queries_in_cache 94
Qcache_total_blocks 217
Ssl_callback_cache_hits 0
Ssl_session_cache_hits  0
Ssl_session_cache_misses    0
Ssl_session_cache_mode  NONE
Ssl_session_cache_overflows 0
Ssl_session_cache_size  0
Ssl_session_cache_timeouts  0
Ssl_used_session_cache_entries  0
Threads_cached  748

有什么我还可以改进以获得更好的性能吗?

谢谢

4

1 回答 1

1

“查询缓存效率:0.1%(703K 缓存/519M 选择)”表示您在缓存生命周期内没有重复查询。

这可能是由于三个因素造成的:缓存生命周期太小而无法显示重复,或者您的查询太大或不同而无法缓存。

例如,一些框架会运行一个大的SELECT然后“过滤”它服务器端(甚至可能缓存它服务器端)。MySQL 看到的是一个可能被认为最好不缓存的大型查询,并且MySQL效率下降,而整体效率保持不变。

或者您可能有许多不同的客户端,并且每个客户端都使用自定义数据(例如,它们的消息表内容)运行一些查询。如果您有 1000 个客户,每个客户占用 1 MB,并且每个客户每分钟检查一次消息,如果您有 1 GB 专用于此类查询,您将看到每小时有 1000 次未命中和 59000 次命中。但是如果你只有 999 兆,最后一个客户端将从缓存中刷新第一个客户端,然后第一个客户端再次出现并丢失并刷新第二个客户端,依此类推;在同一小时内,您会看到 6 万次未命中,效率从 98% 下降到 0%。

因此,首先您需要仔细查看您正在运行的查询。也许其中一些可以优化,缓存方式:一个大查询运行两次,两个细化而不是两个大查询,第一个被缓存。但请记住,您这样做可能会牺牲效率。

从你的其他结果来看,情况似乎如此。您有大量的插入、大量的空闲查询缓存内存,但命中率却很少。因此,显然您的所有查询都彼此不同:在这种情况下,您希望减少查询缓存内存以释放内存用于任何其他目的。即使点击率进一步下降,阿姆达尔定律也会确保与查询相关的性能不会那么相关(你损失了 0.01% 的 50%,你实际上损失了 0.005%;不要让“百分之五十的损失! ”吓到你)。

Qcache_free_memory  134,026,728
Qcache_hits             704,192
Qcache_inserts      143,569,852

肯定不会受到伤害的是检查哪些查询可能不值得,并且可以使用SQL_NO_CACHE. 它们仍然会成为缓存未命中,但不会降低其他查询的性能,这可能会找到更多内存并提高其性能。无论如何,这都是零成本,所以总是可以做到的(当然,对于足够大的查询,它们值得麻烦!)。

完成此操作后,您可以试验该query_cache_size参数。检查其他组件正在使用多少内存,以及文件系统缓存的性能。您不希望加快查询速度并看到页面出现两次,因为视图和控制器组件检索已经把它弄到了脖子上。

您可能想要查看的另一件事是索引。您可以降低慢查询限制并检查是否有查询运行速度明显慢于其他查询,并通过查看他们的查询计划来检查原因。

于 2012-09-13T09:34:05.557 回答