2009-11-23 195 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地址和域,則相同。

我有同樣的情況,並添加這解決了這個問題!