IO優化案例一則

我把我的整個過程寫在這裡，希望能給大家提供一個思路和借鑑。

環境：
OS:AIX 5307
DB:ALTIBASE 3
EMC DMX1000


第一次出現問題

問題現象：
    在白天的業務高峰期，210G記憶體被消耗完。記憶體資料庫同步積壓，積壓的日誌檔案數達到2000個多個，也出現了SWAP OUT的情況。主機相應變慢，但還沒有hang住。

在出現這個問題的時候，首先檢查了系統的記憶體佔用情況，發現記憶體被消耗完，noncomp（檔案型頁面快取）佔用比較高，同時IO也存在等待的情況（當時的情況沒有儲存，無法重現了）。因為一直執行也比較正常，儲存層的東西沒怎麼修改過，所以當時嘗試修改了系統引數max_perm%和 min_perm%，修改之後，noncomp佔用依然，因為這兩個引數只是一個大概的值，並不會嚴格限定noncomp記憶體的使用，於是在加上引數 strict_maxperm = 1，嚴格限定noncomp的記憶體佔用，修改的結果是導致同步程式出現異常，無法正常進行復制。時間比較緊迫，就採用了以下方法解決：
1、停止複製。
2、就直接從其他的邏輯分割槽上劃了25個G的記憶體過來。
3、當天晚上再重做一次全同步。
問題解決。


============================================
第二次出現問題

在第一次解決之後，觀察了幾天，系統還算穩定。但是在半個月之後，又出現了前面的問題。已經嘗試加過記憶體，不能再繼續加了，明顯治標不治本，而且我們也沒那麼多記憶體來不停的加。
當時就停止複製，釋放記憶體，當天晚上再重新全同步。但這隻能是權宜之計，不能隔段時間就做一次這樣的全同步，決心徹查一下問題。

在對當時的topas，nmon等的結果分析，我認為，主要是因為磁碟的IO等待太高，導致檔案的讀寫被拖延，從而導致noncomp的記憶體佔用不斷攀升。我發現一個現象，從io層面看，io分佈不均勻，在一個時間段中，總有一個hdiskpower busy為100％，但是大約1個小時之後，會換另外一個hdiskpower busy為100％，而且，這個100％的盤實際讀寫的量並不是很高，大概為6M/s。當時我的判斷就是存在熱點盤，並且在儲存層面沒有做raid 0。

因為這個問題幾次出現，影響到我們的業務，決定徹查。於是找了EMC原廠的人過來的人過來商討優化方法，emc建議抓一天的資料做一個儲存分析，看看是否存在熱點盤。幾天以後，emc的結果出來了，emc認為沒有單獨的熱點盤，全部盤都是熱點盤，都在滿負荷執行。另外，關於我提出的沒有做條帶的疑惑，EMC的答覆是條帶肯定做了。
emc給出的建議是：
1）擴充現有的記憶體(增加2塊16GB cache)
2）另外發現只有幾個前端埠的IOPS較高，其他的前端埠比較空閒，建議把繁忙LUN再增加對前端埠的對映。
這個儲存其實也比較老了，儲存上掛了好幾個業務系統，磁碟都忙也是正常的。而且EMC是以24小時為單位看的，所以我覺得得到這樣的結果也正常，因為我們busy100％的盤始終在輪換，從整體的效果來看，每塊盤都忙。
針對EMC的解決方案，擴充cache板，也許對系統有一定的提升，但是實際的效果很難說，我覺得基本不會有太大的提升，能提升個5%也就差不多了。

    想要解決這個問題，還是得找其他的辦法。另外，我還是懷疑條帶沒做，還想繼續檢查確認條帶的問題。
在系統中，我們在crontab中佈置了一個nmon作業，來監控系統的使用。於是我就找了其中的一天分析。結果發現一個比較奇怪的現象。altibase資料庫有3個檔案系統：
/altibase_dbs1
/altibase_dbs2
/altibase_logs
資料在寫入的時候，會先寫/altibase_dbs1，一段時間之後，再寫/altibase_dbs2，然後再寫 /altibase_dbs1...，如此交替。/altibase_logs則始終在寫。寫入的量上/altibase_logs為（dbs1＋dbs2）中寫入的量的2倍。這三個檔案系統都基本不存在讀。如果按照這個寫入的來量來推算，那應該是logs下面的盤比較忙，但是實際的情況是dbs1和dbs2的盤非常忙，正在寫入的盤busy為100％，但是logs正在寫入的盤busy只有50％。
    因為不清楚altibase在做checkpoint的時候，資料塊的寫入策略，所以比較難以解釋。當時猜想altibase在寫資料檔案的時候是針對修改了的資料塊進行更改寫入，是隨機小資料塊寫入，在磁碟上尋道的時間比較長，所以寫入的量不大，但是磁碟非常的忙。同時，我也認為磁碟沒有做條帶化，所以才導致這個結果。

    一切以事實為準。所以我向原廠確認兩點：
1）altibase資料庫在checkpoint的時候寫入的策略。原廠工程師最終答覆：
    發生 checkpoint 的時候，對dirty page的flush，是根據資料檔案順序寫， 而且是寫好一個寫另一個。
    第一次發生checkpoint 的時候 ，mydb-0-0, mydb-0-1, mydb-0-2..（位於/altibase_dbs1），根據資料檔案的順序進行flush。
    第二次發生checkpoint 的時候 ，mydb-1-0, mydb-1-1, mydb-1-2..（位於/altibase_dbs2），根據資料檔案的順序進行flush。
    第三次發生checkpoint 的時候 ，mydb-0-0, mydb-0-1, mydb-0-2..（位於/altibase_dbs1），根據資料檔案的順序進行flush。
    ...
mydb-0-n是一個一個的物理檔案（每個大小我這裡定義的是1G），altibase沒有表空間的概念。在沒有做條帶的檔案系統中，這種寫入策略就會導致磁碟寫入效率比較低。

2）找來emc原廠的工程師，現場檢查每個/altibase_dbs1，/altibase_dbs2，/altibase_logs中pv（hdiskpower）在物理磁碟上是如何分佈的？最終檢查的結果終於證實了我的猜想，只做了raid1。
    emc在劃分的時候，將一塊物理硬碟（146G）分成10個 volumn （每個14g），然後從第一塊硬碟中取出一個volumn，比如volumn11，從第二塊硬碟中取出一個volumn，比如volumn21，..，從第九塊硬碟中取出一個volumn（volumn91），這9個volumn組成一個檔案系統/altibase_dbs1。然後volumn12，volumn22，...，volumn92組成檔案系統/altibase_dbs2。
然後volumn13，volumn23，...，volumn93組成檔案系統/altibase_logs。

這樣，每個物理硬碟中還有其他的volumn，其餘的volumn則被其他的系統使用，主要是被我們另一個oracle資料庫使用，oracle的資料庫比較繁忙。所以現在就比較清楚，為什麼出現前面的情況了。altibase的資料檔案mydb-0-n每個是1g，而我們劃分的volumn每個是 14g，基本上每個mydb-0-n是在同一個volumn中的，也就是在同一個物理硬碟中，同時這個物理硬碟還被其他的oracle資料使用，所以 altibase本身的寫入量雖然不大，但是會出現busy 100％的情況。

解決方案

問題已經比較清楚了，我當時建議優化可以考慮從儲存、主機、資料庫3個方面來做：
1、主機級
當前lv建立在引數設定不是很合理。當前我們配置的INTER-POLICY:minimum ，也就是說資料在寫入磁碟的儘量分佈在最少的盤上，如果IO的量比較大，就容易造成單塊盤的busy過高，引起等待。
建議重新建立vg，並且開啟條帶化寫入的功能，條帶化應該能緩解硬碟的IO壓力。

2、儲存級
1）加cache板，我們還有16G的cache板沒加上去，加16G的cache在儲存上，應該有比較明顯的效果。但是當時emc回覆需要下電才能加板，那就存在儲存在下電以後無法起來，所以操作的風險很大。（最終還是加了cache板，因為最後確認不需要下電）。
2）做raid0策略。這個過於複雜，對我們的系統影響太大，所以實際上不可行。

3、資料庫級
altibase資料庫連線比較多，消耗了很多的實體記憶體，將連線數能降下來一些，也可以改善主機的情況。
對於altibase的寫入策略，如果同時寫多個資料檔案，那也存在問題。因為同時開啟，要佔用記憶體，而且檔案很大，對記憶體的佔用也不少。這種策略上修改也比較困難，也不是短時間就可以解決的。

主機級的操作影響的範圍最小，效果最好，但是也最麻煩。我將/altibase_dbs1，/altibase_dbs2，/altibase_logs 所有涉及的物理硬碟全部找出來，以及上面劃分的pv的情況，以及每個pv給哪個系統使用了，然後挑選負擔比較輕的物理硬碟中的volumn，組成 /altibase_dbs1和/altibase_dbs2，在主機層開啟條帶功能。

vg重建方案如下：
PV       邏輯分割槽編號 物理硬碟編號 該物理硬碟上其他的邏輯分割槽 oracle佔用的邏輯分割槽數
hdiskpower4      0200 1d,da 1b0-1c0-1d0-1e0-1f0-200-210-220-230-240-2e6 5
hdiskpower5      0201 1a,ca 1b1-1c1-1d1-1e1-1f1-201-211-221-231-241-2e7 5
hdiskpower6      0202 1b,da 1b2-1c2-1d2-1e2-1f2-202-212-222-232-242-2e8 5
hdiskpower7      0203 1c,db 1b3-1c3-1d3-1e3-1f3-203-213-223-233-243-2e9 5
hdiskpower8      0204 1d,cb 1b4-1c4-1d4-1e4-1f4-204-214-224-234-244-2ea 5
hdiskpower9      0205 1a,db 1b5-1c5-1d5-1e5-1f5-205-215-225-235-245-2eb 5
hdiskpower10     0206 1b,cb 1b6-1c6-1d6-1e6-1f6-206-216-226-236-246-2ec 5
hdiskpower11     0207 1c,ce 1b7-1c7-1d7-1e7-1f7-207-217-227-237-247-2ed 6
hdiskpower12     0208 1d,dc 1b8-1c8-1d8-1e8-1f8-208-218-228-238-248-2ee 6
hdiskpower13     0209 1a,cc 1b9-1c9-1d9-1e9-1f9-209-219-229-239-249-2ef 6
hdiskpower14     020A 1b,dc 1ba-1ca-1da-1ea-1fa-20a-21a-22a-23a-24a-2f0 6
hdiskpower15     020B 1c,dd 1bb-1cb-1db-1eb-1fb-20b-21b-22b-23b-24b-2f1 6
hdiskpower16     020C 1d,cd 1bc-1cc-1dc-1ec-1fc-20c-21c-22c-23c-24c-2f2 6
hdiskpower17     020D 1a,dd 1bd-1cd-1dd-1ed-1fd-20d-21d-22d-23d-24d-2f3 6
hdiskpower18     020E 1b,cd 1be-1ce-1de-1ee-1fe-20e-21e-22e-23e-24e-2f4 6
hdiskpower19     020F 1c,cc 1bf-1cf-1df-1ef-1ff-20f-21f-22f-23f-24f-2f5 5
hdiskpower20     0210 1d,da 1b0-1c0-1d0-1e0-1f0-200-210-220-230-240-2e6 5
hdiskpower21     0211 1a,ca 1b1-1c1-1d1-1e1-1f1-201-211-221-231-241-2e7 5
hdiskpower54     0063 1b,d4 014-03b-063-08b-103-12b-153-17b-1a3 4
hdiskpower55     0064 1c,d5 015-03c-064-08c-104-12c-154-17c-1a4 3
hdiskpower56     0065 1d,c5 016-03d-065-08d-105-12d-155-17d-1a5 3
hdiskpower57     0066 1a,d5 017-03e-066-08e-106-12e-156-17e-1a6 3
hdiskpower58     0067 1b,c5 018-03f-067-08f-107-12f-157-17f-1a7 3
hdiskpower59     0068 1c,c6 009-040-068-090-0b8-0e0-108-130-158-180-198 4
hdiskpower60     0069 1d,d6 012-041-069-091-0b9-0e1-109-131-159-181-1a1 4
hdiskpower61     006A 1a,c6 01a-042-06a-092-0ba-0e2-10a-132-15a-182-1a9 4
hdiskpower62     006B 1b,d6 01b-043-06b-093-0bb-0e3-10b-133-15b-183-1aa 5
hdiskpower63     006C 1c,d7 01c-044-06c-094-0bc-0e4-10c-134-15c-184-1ab 5
hdiskpower64     006D 1d,c7 01d-045-06d-095-0bd-0e5-10d-135-15d-185-1ac 5
hdiskpower65     006E 1a,d7 01e-046-06e-096-0be-0e6-10e-136-15e-186-1ad 6
hdiskpower66     006F 1b,c7 01f-047-06f-097-0bf-0e7-10f-137-15f-187-1ae 6
hdiskpower67     0070 1c,c8 011-048-070-098-0c0-0e8-110-138-160-188-1a0 6
hdiskpower68     0071 1d,d8 019-049-071-099-0c1-0e9-111-139-161-189-1a8 6


lv的劃分需要儘量跨在多個物理硬碟上，dbs1和dbs2的lv最好能避開oracle，所以需要儘量劃在oracle佔用比較少的物理硬碟上，建議的lv劃分如下：
lv00 (/altibase_dbs1): hdiskpower 4,5,54,55,56,57,6,7,8,9,10,11    -12個pv
lv01 (//altibase_dbs2): hdiskpower 20,21,58,59,60,61,12,13,14,15,16,17    -12個pv
lv02 (/altibase_logs) : hdiskpower 18,19,62,63,64,65,66,67,68       -9個pv

lv 的Stripe Size為64K。stripe width 為4。

後記：
條帶後的效果非常明顯，同步不再存在積壓情況，在條帶之後的1年，沒有再出現任何問題。
    其實這也不是第一次出現問題。以前也出現過，只不過一般也都是半年才出現個一次。

其實這個事情上給我們幾個教訓：
1、系統在設計階段你就得做好規劃。從底向上，得有一個通盤的考慮。
2、給EMC這樣的原廠廠家提需求的時候，最好能細節化。比如詳細的你對binfile要求。在後面的另一個專案中，又鬱悶了一次。新買的DMX4儲存，在美國就給灌好了binfile，這個binfile我沒有提很多細節的東西。結果因為趕進度，沒有時間再重新調整了。儲存的劃分沒有達到我的一個比較理想的情況。
3、原廠的話不能盡信。很多的東西你必須得親眼看到才行。這也是無數次的教訓了。
4、有時候你要堅持你的判斷，相信自己。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10867315/viewspace-580381/，如需轉載，請註明出處，否則將追究法律責任。