一、CPU高分析

1.CPU負(fù)載分析

CPU總體使用率：最高時12%。Cpu(s):12%us.   當(dāng)前是：Cpu(s):8.4%us。

這個值在70%以下，都是合理的。%CPU列是單個CPU核占用的CPU百分比。

當(dāng)前系統(tǒng)24核，48CPU。CPU%列的所有值累計不超過4800*70%=3360.

當(dāng)前是：96.5+53.1+44.8+44.5+39.9+37.2+29+26+19.4+11

我們計算出來的值是：8.3625%，與圖中CPU的總體使用 Cpu(s):8.4%us相吻合。

由此可知，當(dāng)前CPU總體使用率8.4%,小于CPU的瓶頸值Cpu(s):70%us.所以即使有單個CPU占用100%，我們認(rèn)為是正常的，當(dāng)SQL正在運行時會出現(xiàn)CPU%列100%的情形。

2.數(shù)據(jù)寫入進程分析

當(dāng)前數(shù)據(jù)庫有6個數(shù)據(jù)寫入進程，并發(fā)向數(shù)據(jù)文件寫入數(shù)據(jù)。這6個進程對應(yīng)操作系統(tǒng)6個oracle進程。

再加上一個日志寫入進程，還有其他的用戶進程，就會出現(xiàn)多個進程占用CPU較高的現(xiàn)象。

3.日志分析

由上圖可以看到，日志文件大小100M過小，日志只有三個組，1s內(nèi)有6次切換，日志切換非常頻繁，需要增加日志文件的大小，同時增加日志的組數(shù)。

一般建議的日志每10~15分鐘切換一次較為合理，且最大大小一般不超過4G。日志切換也需要消耗一定的資源，影響數(shù)據(jù)庫的性能，建議先將日志文件增加到至少5組，每組大小設(shè)置為1G。

同時可以由歸檔情況可以推測，在夜晚跑批時：400M/每秒 的日志產(chǎn)生量。

4.連接分析

由該圖可以看到日志寫入進程只有一個。

由進程數(shù)可推斷同時在線有309人,或者中間件連接池設(shè)置為300左右。

中間件連接池一個連接對應(yīng)于操作系統(tǒng)后臺一個LOCAL=NO的連接。

5.日志產(chǎn)生量分析

由上圖可以知道白天業(yè)務(wù)時間，大約 300KB/s 的日志產(chǎn)生量。日志緩沖區(qū)(log_buffer)的大小是60M。

6.日志切換分析

晚上數(shù)據(jù)庫跑批時，產(chǎn)生的日志量是：361M/s

7.業(yè)務(wù)高峰日志分析

晚上數(shù)據(jù)庫跑批時，產(chǎn)生的日志量是：361M/s  ,日志緩沖區(qū)會頻繁刷盤,由于日志緩沖區(qū)1/3滿就會刷入到磁盤，由此可見夜晚跑批時，每秒刷盤：360M/(60*1/3)=360/20=18次。

日志緩沖區(qū)存在的目的就是為了減少刷入磁盤的次數(shù)，寫入較多的日志時，一次刷入。內(nèi)存寫入效率高，磁盤寫入效率低。要減少刷盤的次數(shù)，可以適當(dāng)增加日志緩沖區(qū)的大小。

當(dāng)前日志緩沖區(qū)60M,可以調(diào)整為254M。

8.SQL分析

上圖是今天9:30-9:45分?jǐn)?shù)據(jù)庫AWR報告抓取情況。由圖可以知道，SQL運行正常，無慢SQL。

9.內(nèi)存分析

由圖可以，內(nèi)核參數(shù)中設(shè)置的共享內(nèi)存段的值是：37.7G。緩存中剩余內(nèi)存26G。交換內(nèi)存使用9.2G。一旦使用交換內(nèi)存SWAP分區(qū)較多，則認(rèn)為內(nèi)存遇到瓶頸，我們認(rèn)為系統(tǒng)內(nèi)存不足。可適當(dāng)增加內(nèi)存。

由于系統(tǒng)內(nèi)存不足，當(dāng)需要內(nèi)存用于計算時會將部分緩沖的內(nèi)容移動到SWAP分區(qū)，從SWAP分區(qū)中訪問或者重新交換到內(nèi)存，這樣明顯降低系統(tǒng)運行效率。訪問SWAP分區(qū)，相當(dāng)于訪問磁盤，效率極低。

二、總結(jié)與優(yōu)化建議

1.CPU使用情況

CPU使用率合理。

2.優(yōu)化建議

2.1如果條件允許可以將內(nèi)存換成128G的。

2.2日志文件和日志緩沖區(qū)的大小可以設(shè)當(dāng)調(diào)整。

日志文件建議：5-10組，每組1G，日志緩沖區(qū)設(shè)置為：254M。

建議先修改日志文件大小和組數(shù)，觀察性能是否有大的提升。如果有較大提升則不改日志緩沖區(qū)。如果性能提升較小，再適當(dāng)調(diào)整日志緩沖區(qū)大小，再觀察性能是否提升。

三、該節(jié)點MySQL內(nèi)存分析

innodb_buffer_pool_size=21474836480=20G .

Total large memory allocated 21988638720 =20G .
Dictionary memory allocated 47611400=45M .
Buffer pool size 1310720=頁的總數(shù)，合計：20G。
Free buffers 1023=Free列表頁的數(shù)量=16M
Database pages 1282153==19.56G=LRU列表頁的數(shù)量
Old database pages 473275=7.2G



--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=22709, Main thread ID=139831373981440, state: sleeping
Number of rows inserted 1437766525, updated 39527145, deleted 503811945, read 372358523033

0.00 inserts/s, 0.11 updates/s, 0.00 deletes/s, 19263.64 reads/s

當(dāng)前MySQL數(shù)據(jù)庫innodb存儲引擎的情況。緩沖池設(shè)置為20G，數(shù)據(jù)庫的緩存也差不多有20G左右，緩沖池充分緩存了熱點數(shù)據(jù)。

且由最下方的行操作可知mysql數(shù)據(jù)庫作為CDP 平臺的元數(shù)據(jù)庫，讀多寫少。每秒有接近2W行數(shù)據(jù)的讀取。

當(dāng)前數(shù)據(jù)庫有360個左右的連接，且?guī)缀跆幱谛菝郀顟B(tài)。MySQL內(nèi)存占用的20G，不影響Oracle數(shù)據(jù)庫的內(nèi)存。

Oracle使用的內(nèi)存由內(nèi)核參數(shù)：kernel.shmmax=39G(不到40G)和oracle SGA 共同決定。Oracle和MySQL共同瓜分了操作系統(tǒng)的內(nèi)存，整體上內(nèi)存不足。但是不影響MySQL。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論