【问题标题】:Mysqltuner suggestions and changes to my.cnfmysqltuner对my.cnf的建议和修改
【发布时间】:2011-04-14 18:54:38
【问题描述】:

在Serverfault上遇到这个问题几天没有运气。

我已经在 VPS 上运行了 mysqltuner.pl,并且对于要更改的变量的建议有很多问题。我敢肯定,这些都是具有复杂答案的一般性问题。

我没有足够的知识来编写查询并针对服务器进行测试,但我只是想从运行五个 WordPress 网站的服务器中获得更高的性能,每月浏览量 >200,000 次。

我已经通过 phpmyadmin 优化了数据库(并且经常这样做),但是调谐器仍然说有碎片表。而且因为这是 WordPress,所以我无法更改核心代码中的查询。

但是我应该将query_cache_size 和innodb_buffer_pool_size 等变量增加多少?其他 innodb 变量呢?

建议的一些变量在 my.cnf 中不存在,例如 table_cache,并且在调谐器报告中被标记等。我可以将它们添加到 my.cnf 中吗?

(为什么这个块在my.cnf中是重复的?我可以删除重复的吗?)

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2

下面是my.cnf和mysqltuner的输出:

my.cnf 的内容:

query-cache-type = 1
query-cache-size = 8M

set-variable=local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql

old_passwords=1

skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2

mysqltuner 的输出:

------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.45
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 133M (Tables: 637)
[--] Data in InnoDB tables: 10M (Tables: 344)
[--] Data in MEMORY tables: 126K (Tables: 2)
[!!] Total fragmented tables: 69

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 6h 24m 13s (2M q [22.135 qps], 116K conn, TX: 4B, RX: 530M)
[--] Reads / Writes: 97% / 3%
[--] Total buffers: 35.0M global + 2.7M per thread (100 max threads)
[OK] Maximum possible memory usage: 303.7M (8% of installed RAM)
[OK] Slow queries: 0% (4/2M)
[OK] Highest usage of available connections: 53% (53/100)
[OK] Key buffer size / total MyISAM indexes: 8.0M/46.1M
[OK] Key buffer hit rate: 99.6% (749M cached / 2M reads)
[OK] Query cache efficiency: 32.2% (685K cached / 2M selects)
[!!] Query cache prunes per day: 948863
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 660K sorts)
[!!] Temporary tables created on disk: 46% (400K on disk / 869K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 24K opened)
[OK] Open file limit used: 10% (109/1K)
[OK] Table locks acquired immediately: 99% (2M immediate / 2M locks)
[!!] InnoDB data size / buffer pool: 10.6M/2.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (> 8M)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 64)
    innodb_buffer_pool_size (>= 10M)

【问题讨论】:

    标签: mysql performance wordpress


    【解决方案1】:

    我会尽我所能在这里提供帮助。 MysqlTuner 报告暗示你在这个 VPS 中有 4GB 的 RAM,所以我的建议是基于此。

    query_cache_size - 这是 MySQL 可用于缓存数据库查询结果的 RAM 量。存储在查询缓存中的结果的返回速度比普通选择快得多,因此这个变量可以显着加快速度(比任何其他建议的更改都快)。

    您需要进行一些实验才能确定正确的值。您目前将此设置为 8M。如果你在这个盒子里有 4GB 的 RAM,我会从 64M 开始,如果需要,增加到 128M 和 256M。每次更改后,放置几天,然后再次运行 MysqlTuner 并将“查询缓存效率”的百分比与之前的百分比进行比较。对于主要托管 5 个 Wordpress 博客的服务器,我怀疑你会看到超过 256M 的任何改进,我不建议超过总 RAM 的八分之一。

    就我个人而言,我发现 Munin(一个免费的服务器监控工具)非常方便地监视这类事情,因为它会绘制缓存命中与其他查询的关系图。

    tmp_table_size - 对于一些复杂的查询(特别是那些使用 GROUP BY 或复杂排序的查询),MySQL 需要首先创建一个包含数据的临时表,然后对其运行一些操作以创建结果集。它将尝试在内存中创建这些临时表,因为这比在磁盘上创建它们要快得多;但对于大型结果集,这并不总是可能的。 tmp_table_size 控制这个阈值。

    我无法想象 Wordpress 会执行任何非常复杂的查询,所以我不会在这个问题上做得过火。 MysqlTuner 建议使用大于 32MB 的值,所以从 64M 开始,几天后看看这对“磁盘上创建的临时表”值有何影响。按照建议设置 max_heap_table_size。

    thread_cache_size - 默认情况下,Wordpress 不使用持久连接(这很好),因此每个请求都会与您的数据库建立新连接,然后在生成页面后关闭它。这个开销并不大,但使用 thread_cache_size 允许 MySQL 重用这些连接线程,这将有所帮助。

    我会选择建议的值 4,除非您获得大量并发用户,否则我认为这会很好。

    table_cache - 我对这个有点模糊,它似乎与MySQL的表结构缓存有关。我会选择 128。

    innodb_buffer_pool_size - 这是 MySQL 可以用来缓存 InnoDB 表的索引和数据的内存量。这让我有点困惑,因为我认为 Wordpress 根本不使用 InnoDB - 你在这台服务器上还有其他网站吗?

    为了回答您的其他问题,[mysqld_safe] 之后的配置仅适用于安全模式下的 MySQL 守护进程,而不适用于整个 MySQL,所以这就是某些变量重复的原因。如果你确实改变了 innodb_buffer_pool_size,你会想要改变第一个。文件中没有的变量可以添加,是的,但是出于同样的原因将它们添加到[mysqld_safe]块之上。

    最后,由于您有优化的心情,如果您还没有使用 PHP 字节码缓存,例如 APC,那么这值得探索。 APC 可以显着提高 PHP 应用程序的速度,而不会产生任何负面影响。

    【讨论】:

    • 谢谢...我会检查所有这些,尝试这些更改并尝试 Munin。服务器已安装 ioncube。
    • 您好...我必须在 my.cnf 上放置 join_buffer_size >= 128 K 吗?这行得通吗?
    【解决方案2】:

    还有更多工具可以调整您的 mysql 数据库:http://www.day32.com/MySQL/http://www.maatkit.org/doc/http://hackmysql.com/mysqlsla

    在大多数情况下,您不需要编写查询并针对服务器进行测试。 只需启用慢查询日志,以识别您的慢查询将它们与 mysqlsla 聚合并使用 maatkit 进行解释:

    您可以将 mysqla 结果中最慢的查询粘贴到文本文件中,然后使用 maatkit 执行它们。

    mk-visual-explain –host hostname –user username –password passwort –database \
    databasename -c query1.sql >> query1_data.txt
    

    -

    mk-query-profiler –host hostname –user username –password passwort –database \
    databasename query1_data.txt >> query1_data.txt
    

    通常使用更新的 mysql 版本对性能至关重要。我体验到,当您比较 mysql 5.0.23 和 5.1.4 时,复杂查询的执行计划非常不同。使用 5.1.4,它们在我们的环境中执行得更快。

    很多关于 mysql 的有用信息可以在http://www.mysqlperformanceblog.com/ 和“高性能 MySQL”一书中找到。

    表缓存: 根据这本书“表缓存存储代表表的对象。缓存中的每个对象都包含关联表的解析 .frm 文件以及其他数据,具体取决于表的存储引擎。

    表缓存的设计有点以 MyISAM 为中心 - 由于历史原因,这是服务器和存储引擎之间的分离不完全干净的领域之一。表缓存对 InnoDB 来说不那么重要,因为 InnoDB 不依赖它来达到很多目的(例如保存文件描述符;为此目的,它有自己的表缓存版本)。但是,即使是 InnoDB 也可以从缓存解析的 .frm 文件中受益。”。

    如果您提高表缓存,则打开文件限制可能会出现错误。您还需要增加服务器上的 open_files_limit 变量,可能还有操作系统打开文件限制:http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/

    线程缓存:

    线程缓存保存当前未与连接关联但已准备好为新连接提供服务的线程。只要 MySQL 在缓存中有空闲线程,它就可以非常快速地响应连接请求,因为它不必为每个连接创建一个新线程。

    [!!] 在磁盘上创建的临时表:46%(磁盘上 400K / 总共 869K) 如果 tmp_table_size 和 max_heap_table_size 尚未设置,请增加它们。与 RAM 操作相比,磁盘操作非常慢。 wordpress 是否使用大量 blob/文本列?那么你不会看到太多好处,因为内存表中不允许有 BLOB 和 Text 列。

    [OK] 可用连接的最高使用率:53% (53/100) 为了节省 RAM,您可以减少允许的最大连接数。另一方面,您可能会在高峰时间用完连接。

    为 PHP 使用操作码缓存是个好主意!

    【讨论】:

      【解决方案3】:

      我为 WP 调整 MySQL 的建议:

      应定期优化数据库表(并在必要时进行修复)以获得最佳性能。

      我建议使用WP-DBManager 插件,它提供此功能以及数据库备份,这对于任何博客安装都至关重要。

      WP-DBManager 允许您安排和忘记,它会自动处理所有工作。

      其他替代方法是通过phpmyadmin 之类的工具手动优化和修复您的表格。

      MySQL 查询缓存会保存查询结果,以防查询再次出现。但是,它只知道如何保存查询的字节文本,而不知道它们的编译版本,因此对查询的微小更改将创建不同的缓存条目。如果您在每个查询中都没有唯一 ID,请打开此选项。您可以通过将以下内容添加到 /etc/my.cnf 来启用它:

      query_cache_type = 1
      query_cache_size = 26214400
      

      【讨论】:

      • 我提到我使用 phpmydmin 进行优化/修复,备份在这里不是问题。我的主要问题与当前不在 my.cnf 中但报告推荐的变量有关。
      【解决方案4】:

      这不是您问题的直接答案,但根据我的经验,wordpress 可以使用前端服务器上的缓存进行非常很好的优化。此外,大多数 wordpress 似乎在前端机器上不受 CPU 限制,而不是在数据库上。 (您可能需要仔细检查您是否确实在优化瓶颈)。

      以“w3 总缓存”为例。将它与 APC 一起使用应该是最简单的方法。确保查看 apc.shm_size 的大小(在 php.ini 中)和缓存命中率(w3tc 应提供一些 apc 信息实用程序)。

      我已经看到 wordpress 实例在具有这种设置的单个服务器上顺利运行,并且每月的页面浏览量超过 200,000 次。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2015-07-30
        • 1970-01-01
        • 2016-05-17
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多