2009-11-23 196 views
0

我的服务器mysql有一个很大的问题。所有的工作都很好,但从一周开始,它就非常缓慢。 每个查询都很慢(有时会多出20次)。 我没有改变我的配置。非常慢的mysql

有人可以帮助我知道为什么我的服务器现在很慢?

谢谢。

这里是我的my.cnf:

[

mysqld_safe] 
socket  = /var/run/mysqld/mysqld.sock 
nice  = 0 

[mysqld] 
# 
# * Basic Settings 
# 
user  = mysql 
pid-file = /var/run/mysqld/mysqld.pid 
socket  = /var/run/mysqld/mysqld.sock 
port  = 3306 
basedir  = /usr 
datadir  = /var/lib/mysql 
tmpdir  = /tmp 
language = /usr/share/mysql/english 
#join_buffer_size = 128.0K 
skip-external-locking 
# 
# Instead of skip-networking the default is now to listen only on 
# localhost which is more compatible and is not less secure. 
bind-address  = 127.0.0.1 
# * Fine Tuning 
# 
key_buffer  = 16M 
max_allowed_packet = 16M 
max_heap_table_size = 64M 
tmp_table_size  = 64M 

thread_stack  = 128K 
thread_cache_size = 8 
#max_connections  = 100 
table_cache   = 400 
join_buffer_size = 2000K 
#thread_concurrency  = 10 
# 
# * Query Cache Configuration 
# 
query_cache_limit  = 1M 
query_cache_size  = 16M 
# 
# * Logging and Replication 
# 
# Both location gets rotated by the cronjob. 
# Be aware that this log type is a performance killer. 
#log  = /var/log/mysql/mysql.log 
# 
# Error logging goes to syslog. This is a Debian improvement :) 
# 
# Here you can see queries with especially long duration 
log_slow_queries = /var/log/mysql/mysql-slow.log 
long_query_time = 2 
#log-queries-not-using-indexes 
# 
# The following can be used as easy to replay backup logs or for replication. 
#server-id  = 1 
log_bin   = /var/log/mysql/mysql-bin.log 
# WARNING: Using expire_logs_days without bin_log crashes the server! See README.Debian! 
expire_logs_days = 10 
max_binlog_size   = 100M 
#binlog_do_db  = include_database_name 
#binlog_ignore_db = include_database_name 
# 
# * BerkeleyDB 
# 
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12. 
skip-bdb 
# 
# * InnoDB 
# 
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. 
# Read the manual for more InnoDB related options. There are many! 
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB. 
#skip-innodb 
innodb_buffer_pool_size = 42M 
# 
# * Security Features 
# 
# Read the manual, too, if you want chroot! 
# chroot = /var/lib/mysql/ 
# 
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca". 
# 
# ssl-ca=/etc/mysql/cacert.pem 
# ssl-cert=/etc/mysql/server-cert.pem 
# ssl-key=/etc/mysql/server-key.pem 



[mysqldump] 
quick 
quote-names 
max_allowed_packet = 16M 

[mysql] 
#no-auto-rehash # faster start of mysql but no tab completition 

[isamchk] 
key_buffer  = 16M 
+0

什么是你使用的确切查询和表格模式?表中有多少行? – 2009-11-23 23:10:46

+0

在查询中发布查询和EXPLAIN的输出。 可能 - 当您向表中注入更多数据,并且/或者您没有正确的索引时,mysql会切换为使用错误的索引。 – nos 2009-11-23 23:21:56

+0

它看起来像'_run_faster = 1'变量没有在my.cnf中设置。 (我小子,我小子。) – spencer7593 2014-03-18 22:27:18

回答

0

感谢您的回答。

我尝试重新启动我的mysql服务器,但没有任何变化。关于CPU和内存,没有错,我的CPU是2%左右,我有1个安装100Mo免费。

我在所有表上运行OPTIMIZE TABLE,但问题仍然存在。

但是,我分析I/O硬盘和我的硬盘每次写很多东西。我有平均75.33个请求/秒在我的磁盘上写入。

问题可能出在这里。如何知道每次写什么程序?

0

你可以试着用some tools, 对于UNIX系统性能监控来缩小问题,也有一个工具称为mytop,通常通过包管理系统可用...

另外,尝试cre在表上添加了一些索引以减少访问延迟。

1

不是一个真正的答案,但mysql的正常运行时间有多长?也许重新启动它可以帮助?

如果重新启动不起作用 - 对所有活动的数据库/表执行检查,有些可能会损坏并导致问题。

另外,你的mysql服务器系统的负载是什么?有些东西可能已经吃掉了所有的RAM并导致了大量的交换。您可以使用htopfree以及一些其他工具来监视CPU/RAM的使用情况。

+0

我怀疑正常运行时间与它有什么关系。这不是Windows 95;) – 2009-11-23 23:50:59

+0

没有完美的软件,我知道(从那时起)'长时间正常运行时间(256d-3y范围内的某处)出现'正常运行时间'实用程序故障:它从0天正常运行时间开始重新计数。无论如何,Kiva的更新清楚地表明我在这种情况下是错的:) – chronos 2009-11-24 18:36:05

5

假设什么都没有改变资源明智的(cpu,内存,磁盘活动) - 一个区域可能是查询的索引。假设数据不断输入/更新,那么随着越来越多的数据输入,查询可能会随着时间的推移而减慢 - 尤其是如果没有设置索引的话。如果没有关于整个设置的进一步信息,这种问题很难回答。

1

这个数据库被用于什么样的应用?

这可能是一个长镜头,但我曾经一直使用导入支持应用程序的电子邮件的应用程序监视服务器。过了一段时间,我发现应用程序开始放慢速度。事实证明,由于垃圾邮件增加了其中的一张表,数据库规模变得很大。将它们清理干净并且显着提高。

确保没有出错,并用垃圾数据淹没数据库。不是一个可能的原因,但它从来没有伤害检查。

在任何情况下,请确保您没有大量交换(如其他地方所建议的)。

+0

我的数据库被postfix用来发送邮件,并通过rails(mongrel)用于我的网站。 只有两个应用程序。我每天发送大约10封邮件。 – Kiva 2009-11-24 08:36:59

0

尝试在skip-external-locking之后添加选项skip-name-resolve,如果在/ etc/hosts中添加服务器IP地址和域,则相同。

我有同样的情况,并添加这解决了这个问题!