设为首页 收藏本站
查看: 446|回复: 0

[经验分享] mysql参数优化辅助工具之tuning-primer.sh

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2015-4-23 09:36:56 | 显示全部楼层 |阅读模式
Tuning-primer.sh  检测mysql当前的运行情况,产生报告,并给出优化建议。
下载及使用:
1.百度云附件:tuning-primer.sh   

2.tuning-primer.sh拷贝到my.cnf同级目录
3.chmod  +x tuning-primer.sh 执行:sh tuning-primer.sh


[iyunv@DG-webDB software]#./tuning-primer.sh all
Using login values from ~/.my.cnf
- INITIAL LOGIN ATTEMPT FAILED -
Testing for stored webmin passwords:
NoneFound
Could not auto detect login info!
Found potential sockets:/home/mysql/data/mysql.sock
Using: /home/mysql/data/mysql.sock
Would you like to provide a differentsocket?: [y/N] n
Do you have your login handy ? [y/N] : y
User: root
Password: anyu@2015

Would you like me to create a ~/.my.cnffile for you? [y/N] : n

       -- MYSQL PERFORMANCE TUNING PRIMER --
            - By: Matthew Montgomery -

MySQL Version 5.5.17-log x86_64

Uptime = 5 days 18 hrs 32 min 31 sec
Avg. qps = 0
Total Questions = 106649
Threads Connected = 1

Server has been running for over 48hrs.
It should be safe to follow theserecommendations

To find out more information on how each ofthese
runtime variables effects performancevisit:
http://dev.mysql.com/doc/refman/ ... stem-variables.html
Visithttp://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's EnterpriseMonitoring and Advisory Service
# 慢查询检查
SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 3.000000 sec.
You have 0 out of 106670 that take longerthan 3.000000 sec. to complete
Your long_query_time seems to be fine
#二进制日志检查
BINARY UPDATE LOG
The binary update log is enabled
# 工作线程检查
WORKER THREADS
Current thread_cache_size = 64
Current threads_cached = 4
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine
# 链接检查
MAX CONNECTIONS
Current max_connections = 2000
Current threads_connected = 1
Historic max_used_connections = 5
The number of used connections is 0% of theconfigured maximum.
You are using less than 10% of yourconfigured max_connections.
Lowering max_connections could help toavoid an over-allocation of memory
See "MEMORY USAGE" section tomake sure you are not over-allocating
# innodb状态检查
INNODB STATUS
Current InnoDB index space = 80 K
Current InnoDB data space = 224 K
Current InnoDB buffer pool free = 99 %
Current innodb_buffer_pool_size = 4.00 G
Depending on how much space your innodbindexes take up it may be safe
to increase this value to up to 2 / 3 oftotal system memory
# 内存状态检查
MEMORY USAGE
Max Memory Ever Allocated : 4.30 G
Configured Max Per-thread Buffers : 4.21 G
Configured Max Global Buffers : 4.29 G
Configured Max Memory Limit : 8.50 G
Physical Memory : 7.68 G

Max memory limit exceeds 90% of physicalmemory
# myisam 键值状态检查
KEY BUFFER
Current MyISAM index space = 105 K
Current key_buffer_size = 256 M
Key cache miss rate is 1 : 2
Key buffer free ratio = 81 %
Your key_buffer_size seems to be fine
#  查询缓存检查
QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size
# 排序操作检查
SORT OPERATIONS
Current sort_buffer_size = 1 M
Current read_rnd_buffer_size = 512 K
Sort buffer seems to be fine
# 表链接检查
JOINS
Current join_buffer_size = 132.00 K
You have had 0 queries where a join couldnot use an index properly
Your joins seem to be using indexesproperly
# 文件限制检查
OPEN FILES LIMIT
Current open_files_limit = 65535 files
The open_files_limit should typically beset to at least 2x-3x
that of table_cache if you have heavyMyISAM usage.
Your open_files_limit value seems to befine
# 变缓存检查
TABLE CACHE
Current table_open_cache = 4220 tables
Current table_definition_cache = 400 tables
You have a total of 55 tables
You have 56 open tables.
The table_cache value seems to be fine
# 临时表检查状态检查
TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 16 M
Of 53466 temp tables, 0% were created ondisk
Created disk tmp tables ratio seems fine
# 表扫描检查
TABLE SCANS
Current read_buffer_size = 256 K
Current table scan ratio = 52589 : 1
You have a high ratio of sequential accessrequests to SELECTs
You may benefit from raisingread_buffer_size and/or improving your use of indexes.
# 表锁检查
TABLE LOCKING
Current Lock Wait ratio = 1 : 91130
Your table locking seems to be fine

和 mysqltunner.sql  相比 tuning-primer的检测的更详细,主要是针对innodb的检测,
Mysqltunner.sql 不能对innodb进行检查的。


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-59903-1-1.html 上篇帖子: 解决MySQL Table '***' is marked as crashed and should be repaired问题 下篇帖子: MySQL存储引擎介绍 mysql
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表