-- MYSQL PERFORMANCE TUNING PRIMER
-- - By: Matthew Montgomery -
MySQL Version 5
.1
.34
-log i686
./tuning-primer.sh: line 497: bc: command not found
./tuning-primer.sh: line 498: bc: command not found
./tuning-primer.sh: line 499: bc: command not found
./tuning-primer.sh: line 500: bc: command not found
./tuning-primer.sh: line 501: bc: command not found
./tuning-primer.sh: line 502: bc: command not found
Uptime
= days hrs
min sec
Avg. qps = 13
Total Questions = 4652
Threads Connected = 1
Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations
To find out more information on how
each of these
runtime variables effects performance visit:
<a href="http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html" target="_blank">http://dev.mysql.com/doc/refman/5.1/en/ser...-variables.html</a>
Visit <a href="http://www.mysql.com/products/enterprise/advisors.html" target="_blank">http://www.mysql.com/products/enterprise/advisors.html</a>
for info about
MySQL's Enterprise Monitoring and Advisory Service
SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 2.000000 sec.
You have 354 out of 4673 that take longer than 2.000000 sec. to complete
./tuning-primer.sh: line 403: bc: command not found
./tuning-primer.sh: line 606: [: -gt: unary operator expected
Your long_query_time seems to be fine
BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See <a href="http://dev.mysql.com/doc/refman/5.1/en/point-in-time-recovery.html" target="_blank">http://dev.mysql.com/doc/refman/5.1/en/poi...e-recovery.html</a>
WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 5
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine
MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 1
Historic max_used_connections = 6
The number of used connections is 6% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating
No InnoDB Support Enabled!
MEMORY USAGE
./tuning-primer.sh: line 1321: bc: command not found
./tuning-primer.sh: line 1322: bc: command not found
./tuning-primer.sh: line 1346: bc: command not found
./tuning-primer.sh: line 1349: bc: command not found
./tuning-primer.sh: line 1350: bc: command not found
./tuning-primer.sh: line 1352: bc: command not found
./tuning-primer.sh: line 1354: [: -gt: unary operator expected
./tuning-primer.sh: line 459: [: max_memoryHR: integer expression expected
./tuning-primer.sh: line 465: [: max_memoryHR: integer expression expected
./tuning-primer.sh: line 471: [: max_memoryHR: integer expression expected
./tuning-primer.sh: line 478: export: `=max_memoryHR': not a valid identifier
Max Memory Ever Allocated
: bytes
./tuning-primer.sh: line 459: [: per_thread_buffersHR: integer expression expected
./tuning-primer.sh: line 465: [: per_thread_buffersHR: integer expression expected
./tuning-primer.sh: line 471: [: per_thread_buffersHR: integer expression expected
./tuning-primer.sh: line 478: export: `=per_thread_buffersHR': not a valid identifier
Configured Max Per-thread Buffers : bytes
./tuning-primer.sh: line 459: [: global_buffersHR: integer expression expected
./tuning-primer.sh: line 465: [: global_buffersHR: integer expression expected
./tuning-primer.sh: line 471: [: global_buffersHR: integer expression expected
./tuning-primer.sh: line 478: export: `=global_buffersHR': not a valid identifier
./tuning-primer.sh: line 459: [: total_memoryHR: integer expression expected
./tuning-primer.sh: line 465: [: total_memoryHR: integer expression expected
./tuning-primer.sh: line 471: [: total_memoryHR: integer expression expected
./tuning-primer.sh: line 478: export: `=total_memoryHR': not a valid identifier
Configured Max Memory Limit : bytes
./tuning-primer.sh: line 440: bc: command not found
Physical Memory : G
Max memory limit seem to be within acceptable norms
KEY BUFFER
./tuning-primer.sh: line 754: bc: command not found
./tuning-primer.sh: line 755: bc: command not found
./tuning-primer.sh: line 440: bc: command not found
Current MyISAM index space = M
./tuning-primer.sh: line 440: bc: command not found
Current key_buffer_size = M
Key cache miss rate is 1 : 65
Key buffer free ratio = %
./tuning-primer.sh: line 788: [: -le: unary operator expected
./tuning-primer.sh: line 792: [: -le: unary operator expected
./tuning-primer.sh: line 796: [: -le: unary operator expected
Your key_buffer_size seems to be fine
QUERY CACHE
./tuning-primer.sh: line 827: bc: command not found
./tuning-primer.sh: line 828: bc: command not found
Query cache is enabled
./tuning-primer.sh: line 440: bc: command not found
Current query_cache_size = M
./tuning-primer.sh: line 440: bc: command not found
Current query_cache_used = K
./tuning-primer.sh: line 440: bc: command not found
Current query_cache_limit = M
Current Query cache Memory fill ratio = %
./tuning-primer.sh: line 440: bc: command not found
Current query_cache_min_res_unit = K
./tuning-primer.sh: line 845: bc: command not found
./tuning-primer.sh: line 846: bc: command not found
./tuning-primer.sh: line 847: [: -gt: unary operator expected
./tuning-primer.sh: line 854: [: -le: unary operator expected
MySQL won't cache query results that are larger than query_cache_limit in size
./tuning-primer.sh: line 440: bc: command not found
./tuning-primer.sh: line 440: bc: command not found
Sort buffer seems to be fine
JOINS
./tuning-primer.sh: line 440: bc: command not found
You have had 0 queries where a
join could not use an index properly
Your joins seem to be using indexes properly
OPEN FILES LIMIT
Current open_files_limit
= 1024 files
The open_files_limit should 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_cache
= 128 tables
Current table_definition_cache
= 256 tables
You have a total of 617 tables
You have 128 open tables.
, while 100% of your table cache is in use
You should probably increase your table_cache
You should probably increase your table_definition_cache value.
TEMP TABLES
./tuning-primer.sh: line 440: bc: command not found
./tuning-primer.sh: line 440: bc: command not found
Of 553 temp tables, 14% were created on disk
Created disk tmp tables ratio seems fine
TABLE SCANS
./tuning-primer.sh: line 440: bc: command not found
read_buffer_size seems to be fine
TABLE LOCKING
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.