« 2008年11月 | (回到Blog入口) | 2009年01月 »

2008年12月 归档

2008年12月07日

MySQL的性能调优工具:比mysqlreport更方便的tuning-primer.sh

年初的时候收藏过一篇关于mysqlreport的报表解读,和内置的show status,show variables相比mysqlreport输出一个可读性更好的报表;但Sundry MySQL提供的脚本相比mysqlreport更进一步:除了报表还进一步提供了修改建议。安装和使用非常简单:

wget http://www.day32.com/MySQL/tuning-primer.sh
chmod +x tuning-primer.sh
./tuning-primer.sh

和mysqlreport一样,tuning-primer.sh也支持.my.cnf
[client]
user = USERNAME
password = PASSWORD
socket = /tmp/mysql.sock

样例输出:在终端上按照问题重要程度分别用黄色/红色字符标记问题

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

MySQL Version 5.0.45 i686

Uptime = 19 days 8 hrs 32 min 54 sec
Avg. qps = 0
Total Questions = 264260
Threads Connected = 1

Server has been running for over 48hrs.
It should 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.0/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 sec.
You have 0 out of 264274 that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 1
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 = 33
The number of used connections is 33% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 96 M
Configured Max Per-thread Buffers : 268 M
Configured Max Global Buffers : 7 M
Configured Max Memory Limit : 276 M
Physical Memory : 1.97 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 8 M
Current key_buffer_size = 7 M
Key cache miss rate is 1 : 1817
Key buffer fill ratio = 6.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
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_cache value = 64 tables
You have a total of 125 tables
You have 64 open tables.
Current table_cache hit rate is 9%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 564 temp tables, 6% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 1 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 264392
Your table locking seems to be fine

更有用是作者总结的处理MySQL性能问题处理的优先级:尤其是头3条,基本上可以解决大部分瓶颈问题的原因。
# Slow Query Log 慢查询 尤其是like操作,性能杀手,轻易不要使用,让全文索引交给Lucene或者利用Tag机制减少like操作;
# Max Connections 并发连接数:一个MySQL deamon缺省最大连接数是100,调到更高只是为了出现问题是给我们更多的缓冲时间而不是任其一直处于那么高的状态,并发连接数类似于等候大厅:当等候人数过多的时候,一味扩大等候厅不是根本解决问题的办法,提高业务的处理速度,多开几个窗口才是更好的解决方法;我的经验就是超过100: 数据就要想办法(镜像或者分片)分布到更多Deamon上
# Worker Threads: Jeremy Zawondy 曾在部落格上說到:Thread caching 並不是我們最需要關心的問題,但當你解決了所有其他更嚴重的問題之後,它就會是最嚴重的問題。(thread caching really wasn't the worst of our problems. But it became the worst after we had fixed all the bigger ones.)
# Key Buffer
# Query Cache
# Sort Buffer
# Joins
# Temp Tables 临时表
# Table (Open & Definition) Cache 表缓存;
# Table Locking 表锁定
# Table Scans (read_buffer)
# Innodb Status

按此阅读全文 "MySQL的性能调优工具:比mysqlreport更方便的tuning-primer.sh " »

2008年12月18日

关于Google FREE Webhosting !的欺诈邮件 200∞

早上收到了一封貌似正常的邮件:

Hello,
Dear Gmail customer
After our free email services we offer you to sing up for our free hosting services.
This service currently is in beta test.
And we choose you to test this services and report us any bug you may find.We give you unlimited webspace on your own domain name you must only change your dns services to ns1.google.com and ns2.google.com and enter your domain name in our special control panel.
Our servers are linux based and we support PHP, SSL (Secure Shell),FTP,Stats,CGI,Perl,Unlimited email address and finaly 500 MySQL Database.

Notice :
Dont sell this invitation code in auction website that may cause we disable your account in the future.

Your invitation code :
http://gmail-application.com/cvw2p99ah7dtV1bFJyacSHUQcdROroysWeaIkkATEXaZUJ7n6wwXjzlyFVEYfJyB74Y66qln8VSP1Njjbp4zW/


Need help ? Hosting-Support@google.com
Google Webhosting Team

为什么是欺诈邮件,whois一下邀请链接的域名就知道了:详情附后,注册人好像在香港,搜索 Hosting-Support@google看,1月份,4月份,8月份都有类似邮件发出;

按此阅读全文 "关于Google FREE Webhosting !的欺诈邮件 200∞" »

关于 2008年12月

此页面包含了在2008年12月发表于车东[Blog^2]的所有日记,它们从老到新列出。

前一个存档 2008年11月

后一个存档 2009年01月

更多信息可在 主索引 页和 归档 页看到。

Creative Commons License
此 Blog 中的日记遵循以下授权 Creative Commons(创作共用)授权.
Powered by
Movable Type 3.36