2012-05-23 67 views
2

我們正在運行2臺Web服務器,它們承載Amazon EC2上的Magento電子商務網站和1臺MySQL數據庫服務器。Amazon EC2上的MySQL/Magento性能問題

我們正在經歷重大的性能問題,死鎖,「鎖等待超時超標」 MySQL服務器上的錯誤等,並真正地奮鬥得到這些解決。

我們的數據庫服務器最近升級到m1.xlarge實例(從m1.large),仍然我們將繼續遇到這些問題。

我們已經歸於這些問題向壞磁盤IO,我們經常在EC2服務器上看到的,但最近我已經看到了死鎖等,即使磁盤IO是罰款的問題。

的「特區」命令顯示,我們在高峯時段盤非常不好的IO性能,或當我們執行像通過Magento的API創建發票數據庫密集型操作。我們經常看到愛荷華州達到20%以上。

下面是截圖鏈接最近的一個問題,我們必須在那裏查詢是導致緩慢整個數據庫的下跌過程中表現出的「MTOP」的結果:

http://i.imgur.com/AARlc.png

該截圖顯示一個或其他查詢將執行其餘的查詢。它也表現出相當低的平均負載,當執行密集命令時,經常會看到平均負載高達3.0。

這裏是my.cnf設置:

[mysqld] 
datadir=/var/lib/mysql 
socket=/var/lib/mysql/mysql.sock 
user=mysql 
symbolic-links=0 
innodb_file_per_table=1 
key_buffer=512M 
max_allowed_packet=64M 
table_cache=512 
innodb_thread_concurrency=5 
innodb_buffer_pool_size=4976M 
innodb_additional_mem_pool_size=8M 
innodb_log_file_size=128M 
innodb_log_buffer_size=8M 
thread_cache_size=150 
sort_buffer_size=4M 
read_buffer_size=4M 
read_rnd_buffer_size=2M 
myisam_sort_buffer_size=64M 
tmp_table_size=256M 
query_cache_type=1 
query_cache_size=128M 
max_connections=400 
wait_timeout=28800 
innodb_lock_wait_timeout=120 
max_heap_table_size=256M 
long_query_time=3 
log-slow-queries=...mysql-slow.log 

[mysqld_safe] 
log-error=...mysqld.log 
pid-file=...mysqld.pid 

我們已經使用了pt-query-digest功能廣泛地分析我們的MySQL慢查詢日誌。

基本上我們看到sales_flat_quote table的更新和插入速度非常慢,但其他表格也是如此。

sales_flat_quote不是特別大,雖然,只有100k左右表中的行。

我現在不知道我們應該嘗試或接下來做什麼,並且任何建議都會真正被讚賞!

我也不清楚需要什麼其他信息,以幫助診斷這樣的問題,所以請與我裸露。

回答

1

幾個根本原因是可能的:

  • 一些您的查詢速度慢可能是鎖表,因此排隊等查詢
  • 您的查詢可能無法優化
  • 您的查詢可能需要一些更多的索引表

使用this official tool檢查最慢的查詢:

mysqldumpslow 
+1

嗨Adrien,這些查詢是Magento軟件平臺中的標準查詢,所以這些我們可以改變的很少。這並不是說它們是「優化的」,因爲該軟件已知有很多錯誤。 – nickwes

+0

對不起,我忘了添加,我們已經在使用pt-query-digest工具,它允許我們總結mysql慢速查詢日誌並確定最慢的查詢。 但是,關於如何解決這些問題的建議方式很少提供。 – nickwes

1

我們在我們的mysql EC2服務器上觀察到類似的豬,但是,我們很快將我們的數據庫遷移到了RDS實例。從那時起,問題就很少了。有人可能會說,RDS代價高昂,而EC2不是,但是,您還可以節省管理數據庫/日常備份等所花費的時間。

+0

你還在運行Magento嗎? – nickwes

+0

是的。我們現在已經超過6個月 – sulabh

+0

太好了,謝謝你的信息。我將看看亞馬遜RDS。 – nickwes

0

我建議將您的數據庫遷移到RDS實例。