代码之家  ›  专栏  ›  技术社区  ›  markratledge

Mysqltuner建议和更改我的.cnf

  •  12
  • markratledge  · 技术社区  · 14 年前

    有好几天没把这个问题放在服务器上。

    我已经跑了mysqltuner.pl文件在一个VPS上,有一堆关于要改变的变量的建议的问题。我相信这些都是一般性的问题,答案很复杂。

    我没有足够的知识来编写查询并在服务器上测试它们,但我只是想让运行五个WordPress站点的服务器的性能提高一点,每个月的页面浏览量超过200000次。

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

    但是我应该增加多少变量,比如query\u cache\u size和innodb\u buffer\u pool\u size?其他innodb变量呢?

    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
    

    下面是我的.cnf以及mysqltuner的输出:

    的内容我的.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
    

    ------- 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)
    
    5 回复  |  直到 14 年前
        1
  •  21
  •   ᴍᴇʜᴏᴠ   5 年前

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

    查询缓存大小

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

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

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

    线程\u缓存\u大小

    我会选择建议的值4,我想如果没有大量的并发用户,这个值就可以了。

    表\u缓存

    innodb\缓冲区\池\大小

    要回答您的其他问题,请在 [mysqld_safe]

    最后,由于您正处于优化状态,如果您还没有使用PHP字节码缓存,例如 APC 那么这是值得探索的。APC可以在没有任何负面影响的情况下显著提高PHP应用程序的速度。

        2
  •  3
  •   Yes Barry    12 年前

    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的很多有用信息可以在 http://www.mysqlperformanceblog.com/

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

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

    线程缓存:

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

    [!!]在磁盘上创建的临时表:46%(磁盘上400K/869K)

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

        3
  •  0
  •   Todd Moses    14 年前

    我的建议是为WP tunning MySQL:

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

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

    wpdbmanager允许您安排和忘记,它将自动处理所有工作。

    phpmyadmin .

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

    query_cache_type = 1
    query_cache_size = 26214400
    
        4
  •  0
  •   Christoph Strasen    14 年前

    这不是一个直接回答你的问题,但在我的经验,wordpress可以 非常 在前端服务器上使用缓存进行了很好的优化。而且大部分wordpress似乎在前端机器上而不是数据库上受到CPU的限制。(您可能需要再次检查是否确实在优化瓶颈)。

    我见过wordpress实例在一台服务器上顺利运行,而且每月的页面浏览量超过20万次。