I have an AWS RDS Mysql Server with Table cache hit rate's problem. If I do a query on phpmyadmin (also simple query) always do it without cache.

Here the mysqltuner log:

MySQLTuner 1.6.12 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
[--] Performing tests on xxxxxxxxxx
Please enter your MySQL administrative login: xxxx
Please enter your MySQL administrative password:
[--] Skipped version check for MySQLTuner script
[--] Assuming 15000 MB of physical memory
[!!] Assuming 0 MB of swap space (use --forceswap to specify)
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
[OK] Currently running supported MySQL version 5.6.27-log

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Data in MyISAM tables: 231G (Tables: 5052)
[--] Data in InnoDB tables: 2G (Tables: 339)
[!!] Total fragmented tables: 86

-------- Security Recommendations ------------------------------------------------------------------
[OK] There are no anonymous accounts for any database users
[!!] User 'mysql.sys@localhost' has no password set.
[!!] There is no basic password file list!

-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 44d 18h 57m 56s (658M q [170.285 qps], 10M conn, TX: 482G, RX: 354G)
[--] Reads / Writes: 52% / 48%
[--] Binary logging is enabled (GTID MODE: OFF)
[--] Physical Memory     : 14.6G
[--] Max MySQL memory    : 13.5G
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
[--] Other process memory: 273.4M
[--] Total buffers: 13.3G global + 2.2M per thread (100 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[!!] Maximum reached memory usage: 13.4G (91.49% of installed RAM)
[!!] Maximum possible memory usage: 13.5G (92.27% of installed RAM)
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 1% (6M/658M)
[OK] Highest usage of available connections: 48% (48/100)
[OK] Aborted connections: 0.52%  (56490/10863413)
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.
[OK] Sorts requiring temporary tables: 0% (124K temp sorts / 20M sorts)
[!!] Joins performed without indexes: 265811
[OK] Temporary tables created on disk: 3% (413K on disk / 12M total)
[!!] Table cache hit rate: 0% (6K open / 3M opened)
[OK] Open file limit used: 12% (8K/65K)
[OK] Table locks acquired immediately: 98% (629M immediate / 636M locks)
[OK] Binlog cache memory access: 99.56% ( 3252959 Memory / 3267284 Total)

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is disabled.

-------- Performance schema ------------------------------------------------------------------------
[--] Performance schema is disabled.

-------- MyISAM Metrics ----------------------------------------------------------------------------
[OK] Key buffer used: 100.0% (268M used / 268M cache)
[OK] Key buffer size / total MyISAM indexes: 256.0M/73.1G
[OK] Read Key buffer hit rate: 97.3% (41B cached / 1B reads)
[!!] Write Key buffer hit rate: 88.7% (5B cached / 621M writes)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is disabled.

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 11.1G/2.9G
[OK] InnoDB buffer pool instances: 11
[OK] InnoDB Used buffer: 98.45% (713650 used/ 724922 total)
[OK] InnoDB Read buffer efficiency: 100.00% (60609315410 hits/ 60609364241 total)
[OK] InnoDB Write log efficiency: 99.67% (509380571 hits/ 511044352 total)
[OK] InnoDB log waits: 0.00% (0 waits / 1663781 writes)

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] This is a standalone server.

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Set up a Password for user with the following SQL statement ( SET PASSWORD FOR 'user'@'SpecificDNSorIp' = PASSWORD('secure_password'); )
    Reduce your overall MySQL memory footprint for system stability
    Adjust your join queries to always utilize indexes
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: 
    Beware that open_files_limit (65535) variable
    should be greater than table_open_cache ( 6396)
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    join_buffer_size (> 1.0M, or always use indexes with joins)
    table_open_cache (> 6396)

I have some query that are slow query logged because don't use index (but not at all).

Can someone explain how resolve this hits rate problem?

Thank you


Some of what MySQLTuner says is bogus. Here are the things that seem bad:

You are using MyISAM instead of InnoDB; this is generally sub-optimal.

Fragmented tables -- bogus. There may be some MyISAM tables that could use OPTIMIZE, but probably not.

3GB of InnoDB tables, yet the buffer_pool is much bigger. Lower innodb_buffer_pool_size to 3500M and the instances to 3.

You have lots of MyISAM indexes, yet a small key_cache. Increase key_buffer_size to 3G.

Lower long_query_time to 1, run for awhile, then use pt-query-digest to find the worst couple of queries. Fix them. (This will deal with several of the "!!" comments - joins, disk tmp tables, write key, etc.)

How long was mysqld up when you ran this script? A 1% miss rate for table_open_cache is not that bad, but maybe the Opened_tables / Uptime is bad. I consider over 2/sec to be bad.

If you would like a different analysis, post SHOW VARIABLES and SHOW GLOBAL STATUS and size of RAM. (Probably need post.it because of size.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.