某客戶資料庫從p595物理遷移至p780新伺服器並更換儲存之後，發現應用效能反而下降。p780配置了32顆4核cpu（主頻為3920 mhz），710g記憶體。如下所示：
system model: ibm,9179-mhc
machine serial number: 06da0cr
processor type: powerpc_power7
processor implementation mode: power 7
processor version: pv_7_compat
number of processors: 32
processor clock speed: 3920 mhz
cpu type: 64-bit
kernel type: 64-bit
lpar info: 1 sn06da0cr
memory size: 727040 mb
good memory size: 727040 mb
platform firmware level: am740_088
firmware version: ibm,am740_088
console login: enable
auto restart: true
full core: false
p595配置了32顆雙線程cpu（主頻為2302 mhz），186g記憶體。如下所示：
system model: ibm,9119-595
machine serial number: 83e37e3
processor type: powerpc_power5
processor implementation mode: power 5
processor version: pv_5_3
number of processors: 32
processor clock speed: 2302 mhz
cpu type: 64-bit
kernel type: 64-bit
lpar info: 1 83-e37e3
memory size: 190976 mb
good memory size: 190976 mb
platform firmware level: sf240_358
firmware version: ibm,sf240_358
console login: enable
auto restart: true
full core: false
可以看到伺服器在硬體配置層面提高了很多，在排除了執行計畫變壞的可能性之後，資料庫效能下降是極不正常的。
在排除了伺服器配置因素之後，進一步檢查儲存的i/o效能。通過檢視awr報告發現資料庫效能下降期間，儲存i/o的響應時間下降厲害，單塊順序讀（db file sequential read）需要24ms，多塊離散讀（db file scattered read）需要33ms，日誌檔案同步（log file sync）竟然高達68ms，如下所示：
幾乎可以確認，儲存i/o下降是引起資料庫效能下降的主要原因。經過和客戶溝通之後，由於種種原因，該庫和另外一套資料庫需要共用一套儲存，而且短期內還不能更改這種架構模式。
前面提到p780伺服器的記憶體為710g，比原來的p595伺服器足足多出524g記憶體。在目前的硬體條件下，要快速提高資料庫效能，只能採取記憶體換i/o的優化手段。資料庫sga引數修改之前，buffer cache為40g，shared pool為14g，如下所示：
經過和客戶商量，決定擴大資料庫的buffer cache至256g，並設定db_keep_cache_size至200g，並將最「熱」的表和索引keep進keep pool中，keep語法如下所示：
alter table *** storage(buffer_pool keep);
alter index *** storage(buffer_pool keep);
可以通過dba_segments.buffer_pool欄位檢視物件是否已經keep進keep池中。如下所示：
sql> select distinct buffer_pool from dba_segments;
buffer_
-------
default
keep
修改之後的buffer cache和keep pool大小如下所示：
但是，檢視awr報告發現資料庫每秒的物理讀次數下降明顯，每秒讀資料塊個數為1,925個，如下所示：
而修改引數之前，每秒的物理讀高達6624個，如下所示：
可見，增大資料庫的buffer cache效果還是很明顯的，增大buffer cache使得更多的資料塊可以被緩衝到記憶體中，從而有效地減少了物理讀。但需要注意的是，增大buffer cache會在一定程度上增加cpu的使用率，所幸的是，增大buffer cache之後cpu空閒率維持在80%左右，系統記憶體使用率在78%左右，如下所示：
總結：在cpu資源充足的前提下，適當增加buffer cache記憶體可以緩減儲存i/o資源緊張。
記一次SQL優化
問題發生在關聯主表a 4w資料量 和副表b 4w資料量 關聯欄位都是openid 當時用的是 left join 直接跑sql，卡死 伺服器也是差 優化1 改left join 為join，兩者區別就是left join查詢時已主表為依據，該是幾條就幾條 就算副表沒有關聯的資料 join如果副表沒有...
記一次Mysql占用記憶體過高的優化過程
一.環境說明 作業系統 centos 6.5 x86 64 資料庫 mysql 5.6.22 伺服器 阿里雲vps，32g mem，0 swap 二.問題情況 1.某日發現公司線上系統的mysql某個例項的從庫長時間記憶體占用達到60 如下圖 2.於是開始按照以下步驟排查 1 檢視mysql裡的執行...
記一次goto記憶體洩漏
學習c語言時一直被告誡盡量不要使用goto語句，所以對其了解很少。在一次專案使用時由於之前的程式已經使用了goto，按照自己的理解去處理，結果導致記憶體未釋放。例子如下 include int main return 0 error printf aaaaa n printf 11111.n ret...