MySQL數據庫辦事器逐步變慢剖析與處理辦法分享。本站提示廣大學習愛好者：（MySQL數據庫辦事器逐步變慢剖析與處理辦法分享）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL數據庫辦事器逐步變慢剖析與處理辦法分享正文
1、檢討體系的狀況
經由過程操作體系的一些對象檢討體系的狀況，好比CPU、內存、交流、磁盤的應用率，依據經歷或與體系正常時的狀況比擬對，有時體系外面上看起來看余暇，這也能夠不是一個正常的狀況，由於cpu能夠正期待IO的完成。除此以外，還應不雅注那些占用體系資本(cpu、內存)的過程。
1.應用sar來檢討操作體系能否存在IO成績
#sar-u210— 即每隔2秒審查一次，共履行20次。
成果示例：
注：在redhat下，%system就是所謂的%wio。
Linux2.4.21-20.ELsmp (YY075)05/19/2005
10:36:07AMCPU%user%nice%system%idle
10:36:09AMall0.000.000.1399.87
10:36:11AMall0.000.000.00100.00
10:36:13AMall0.250.000.2599.49
10:36:15AMall0.130.000.1399.75
10:36:17AMall0.000.000.00100.00
個中：
%usr指的是用戶過程應用的cpu資本的百分比;
%sys指的是體系資本應用cpu資本的百分比;
%wio指的是期待io完成的百分比，這是值得不雅注的一項;
%idle即余暇的百分比。
假如wio列的值很年夜，如在35%以上，解釋體系的IO存在瓶頸，CPU消費了很年夜的時光去期待I/O的完成。Idle很小解釋體系CPU很忙。像以上的示例，可以看到wio均勻值為11，解釋I/O沒甚麼特殊的成績，而idle值為零，解釋cpu曾經滿負荷運轉了。
2.應用vmstat監控內存 cpu資本
[root@mysql1 ~]# vmstat
procs ———–memory———-—swap– —–io—-–system– —–cpu——
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 72 25428 54712672264 0 0 14 43 53 59 1 198 0 0
vmstat 的輸入那些信息值得存眷?
io bo: 磁盤寫的數據量稍年夜，假如是年夜文件的寫，10M之內根本不消擔憂，假如是小文件寫2M之內根本正常
① CPU成績
上面幾列須要被觀察，以肯定cpu能否有成績
Processesinthe run queue (procs r)
Usertime (cpu us)
System time (cpu sy)
Idle time (cpu id)
成績情形:
假如processes in run queue (procs r)的數目弘遠於體系中cpu的數目，將會使體系便慢。
假如這個數目是cpu的4倍的話，解釋體系正面對cpu才能缺乏,這將使體系運轉速度年夜幅度下降
假如cpu的idle時光常常為0的話，或許體系占用時光(cpu sy)是用戶占用時光(cpu us)兩輩的話，體系面對缺乏cpu資本
處理計劃 :
處理這些情形，觸及到調劑運用法式，使其能更有用的應用cpu，同時增長cpu的才能或數目
②內存成績
重要檢查頁導入的數值(swap中的si)，假如該值比擬年夜就要斟酌內存，年夜概辦法以下：
最簡略的，加年夜RAM
削減RAM的需求
3.磁盤IO成績
處置方法：做raid10進步機能
4.收集成績
telnet一下MySQL對外開放的端口，假如欠亨的話，看看防火牆能否准確設置了。別的，看看MySQL是否是開啟了skip-networking的選項，假如開啟請封閉。
