重型MySQL的使用CPU或內存

我有一個Amazon S3的情況下，我們必須在服務器上的項目做了很多INSERT和UPDATE和一些複雜的SELECT重型MySQL的使用CPU或內存

我們發現，MySQL會經常佔用的很多的CPU。

我想確定更高的內存還是更高的cpu是更好的上述設置。

下面是cat /proc/meminfo

MemTotal:  7347752 kB 
MemFree:   94408 kB 
Buffers:   71932 kB 
Cached:  2202544 kB 
SwapCached:   0 kB 
Active:  6483248 kB 
Inactive:  415888 kB 
SwapTotal:   0 kB 
SwapFree:   0 kB 
Dirty:   168264 kB 
Writeback:   0 kB 
AnonPages:  4617848 kB 
Mapped:   21212 kB 
Slab:   129444 kB 
SReclaimable: 86076 kB 
SUnreclaim:  43368 kB 
PageTables:  54104 kB 
NFS_Unstable:  0 kB 
Bounce:    0 kB 
CommitLimit: 3673876 kB 
Committed_AS: 5384852 kB 
VmallocTotal: 34359738367 kB 
VmallocUsed:  180 kB 
VmallocChunk: 34359738187 kB

當前設置的輸出：

高CPU超大型實例

7 GB的存儲器20個EC2計算單元（8 具有2.5 EC2的虛擬核心Compute 單位）1690 GB實例存儲 64位平臺I/O性能：高API名稱：c1.xlarge

可能的設置：

高內存雙超大實例

34.2 GB內存13個EC2計算單元（4個虛擬核心，3.25個EC2計算每個計算單元）850 GB實例存儲器 64位平臺I/O性能：高性能 API名稱：m2.2xlarge

來源

2011-03-03 Lizard

表是所有/主要是MyISAM或InnoDB？ – robjmills 2011-03-03 10:32:47

InnoDb for most tables ...我已將MyISAM保留在我們執行全文搜索的1個表上 – Lizard 2011-03-03 12:13:15

您是否嘗試過使用mk-query-digest（在maatkit中）或mtop來確定資源使用量最重的位置？慢查詢日誌和查詢分析器？ – coolgeek 2011-03-13 17:17:52

我會去32GB的內存，也許更多的硬盤在RAID中。 CPU不會有太大的幫助 - 你有足夠的CPU能力。您還需要正確配置mysql。

離開1-2 GB用於OS緩存和臨時表。
增加tmp_table_size的
刪除交換
優化query_cache_size變量（不讓它過大 - 看到它MySQL文檔）
定期運行FLUSH QUERY CACHE。如果您的查詢緩存是< 512 MB - 每5分鐘運行一次。這不清理緩存，它優化它（碎片整理）。這是從MySQL文檔：

整理查詢緩存，以更好地利用它的內存。與FLUSH TABLES或RESET QUERY CACHE不同，FLUSH QUERY CACHE 不會刪除緩存中的任何查詢。

但是我注意到其他的解決方案有一半的磁盤空間：850GB，這可能會減少硬盤的數量。這通常是一個壞主意。數據庫中最大的問題是硬盤。如果您使用RAID5--請確保您不要使用較少的硬盤。如果你根本不使用RAID - 我會建議raid 0.

來源

2011-03-30 14:31:20 NickSoft

這取決於應用。

您可以使用memcached緩存mysql查詢。這可以緩解CPU佔用率，但是使用這種方法，您希望增加用於存儲查詢的RAM。

另一方面，如果它不適用於基於應用程序的類型，那麼我會推薦更高的CPU。

來源

2011-03-03 15:59:31 RDL

MySQL沒有太多的理由使用大量的CPU：它要麼處理存儲的例程（存儲過程或存儲函數），要麼進行可以吃掉CPU的排序。

如果由於存儲的例程而使用了大量的CPU，那麼您做錯了，無論如何您的靈魂都無法保存。

如果由於排序正在進行而使用大量CPU，取決於查詢的性質，可以完成一些操作：可以擴展索引以在末尾包括ORDER BY列，或者可以放下ORDER BY子句並在客戶端進行排序。

選擇何種方法取決於CPU使用的實際原因 - 查詢和排序？並在實際的查詢。因此，無論如何，您需要首先進行更好的監控。

沒有監控信息，一般的建議總是：購買更多的內存，而不是更多的CPU數據庫。

來源

2011-03-13 16:52:41 Isotopp

你是否暗示sprocs不好？ – 2011-03-13 17:03:55

在MySQL中，實現非常糟糕。該代碼未被解析，該過程的ASCII源存儲在磁盤上。每個連接都會解析該過程並在其連接結構中緩存解析的代碼，連接之間不會共享。另外，實現是不完整的（在5.5中稍微糾正）並且難以調試。即使沒有這些問題，存儲過程也是運行在系統中最昂貴且最不容易擴展的CPU上的代碼，因此通常是一個壞主意（存在反例）。 – Isotopp 2011-03-13 17:08:17

然而，它仍然會比將數據傳送到您的應用程序進行處理然後通過網絡發回他的結果的速度更快（並且需要更少的網絡資源） – coolgeek 2011-03-13 17:12:39

EC2的按需性質是否使得租用一天中可能的設置變得相當簡單，並進行一些負載測試？測量勝於雄辯。

來源

2011-03-13 17:02:41

使用「高CPU超大實例」。

在當前設置中，MySQL不受存儲器約束：

MemTotal:  7347752 kB  
MemFree:   94408 kB  
Buffers:   71932 kB  
Cached:  **2202544 kB**

在對7 GB存儲器，2 GB未被使用，正在使用的OS作爲I/O緩存。

在這種情況下，CPU數量的增加可以讓你更加放心。

來源

2011-03-14 08:25:17

使用vmstat和iostat來確定CPU或I/O是否是瓶頸（如果I/O - 增加更多RAM並將數據加載到內存中）。從殼運行，並檢查結果：

vmstat 5 
iostat -dx 5

如果CPU是問題vmstat將在us列顯示出高的值，並且iostat將顯示低磁盤使用（util）
如果I/O是問題則vmstat將在us列中顯示較低值，iostat將顯示高磁盤利用率（util）;通過高我的意思是> 50％

來源

2011-05-25 11:29:21 matt

重型MySQL的使用CPU或內存

回答

相關問題