Mysql performance optimization tool -- Introduction to tuner-primer and mysql Performance Optimization

Mysql performance optimization tool -- Introduction to tuner-primer and mysql Performance Optimization

Download and change the execution permission:
Wget http://www.day32.com/MySQL/tuning-primer.sh
Chmod + x tuning-primer.sh
/Tuning-primer.sh

Result report:
It will be marked with several colors:
Blue: Total metrics
Green: this parameter is optional.
RED: indicates a serious problem with this parameter.
Deep red: indicates a parameter with a problem
Yellow: Some information prompts
There are also warnings:
Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

The following is the result of a report.

Xx @ xxxxxx :~ $ ../Tuning-primer.sh
Mysqld is alive

-- Mysql performance tuning primer --
-By: Matthew Montgomery-

MySQL Version 5.1.32-enterprise-gpl-log x86_64

Uptime = 4 days 0 hrs 48 min 3 sec
Avg. qpss = 255
Total Questions = 88956118
Threads Connected = 4

Server has been running for over 48hrs.
It shoshould be safe to follow these recommendations

To find out more information on how each of these
Runtime variables effects performance visit:
Http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
For info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10.000000 sec.
You have 9589 out of 88956228 that take longer than 10.000000 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is enabled
The expire_logs_days is not set.
The mysqld will retain the entire binary log until reset master or purge master logs commands are run manually
Setting expire_logs_days will allow you to remove old binary logs automatically
See http://dev.mysql.com/doc/refman/5.1/en/purge-master-logs.html

WORKER THREADS
Current thread_cache_size = 32
Current threads_cached = 29
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 151
Current threads_connected = 4
Historic max_used_connections = 84
The number of used connections is 55% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated: 11.87 GB
Configured Max Per-thread Buffers: 10.38G
Configured Max Global Buffers: 6.10G
Configured Max Memory Limit: 16.48 GB
Physical Memory: 8.00G

Max memory limit exceeds 90% of physical memory

(Memory settings have serious problems! -- By Me)

KEY BUFFER
1714734x1024/2147483648x100
Current MyISAM index space = 8 K
Current key_buffer_size = 2.00G
Key cache miss rate is 1: 585673
Key buffer free ratio = 0%
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere


(Incorrect parameter settings: query_cache_size> query_cache_limit -- By Me)
SORT OPERATIONS
Current sort_buffer_size = 4 M
Current read_rnd_buffer_size = 64 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 1 queries where a join cocould not use an index properly
You shoshould enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may be want to increase your
Join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

(Join_buffer_size is too small. Another query uses join but does not take the index -- By Me)

OPEN FILES LIMIT
Current open_files_limit = 1185 files
The open_files_limit shocould typically be set to at least 2x-3x
That of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cached = 512 tables
Current table_definition_cache = 256 tables
You have a total of 0 tables
You have 125 open tables.

TABLE SCANSCurrent read_buffer_size = 2 M
Current table scan ratio = 4650: 1
You have a high ratio of sequential access requests to SELECTs
You may benefit from raising read_buffer_size and/or improving your use of indexes.



TABLE LOCKING
Current Lock Wait ratio = 1: 5833374
Your table locking seems to be fine