神通資料庫測試環境調優過程
背景
同事中午時反饋一個環境速度很慢.
我透過grafana簡單看了下應用的
jvm資訊還有hikari都很正常.
沒有大量FullGC,也沒有很多失敗的提示.
感覺很奇怪.
當時已經過了中午,想著下午再看.
1點時想起來, 應用沒問題, 可能是資料庫的異常.
才發現自己被一個地方給坑了.
問題現象
11點四十時同事反饋應用白屏.
grafana檢視jvm的堆區,還有hikari,以及fullGC資訊
發現並沒有很明顯的瓶頸.
檢視node/sar 進行簡單檢視
發現並沒有 虛擬機器層面的瓶頸
因為已經接近中午, 就先吃飯了.
吃飯時想起來, 自己在半年前調整過資料庫.
資料庫在一個SSD的虛擬機器上面.
轉而上去檢視. 發現機器壓力上課
sar 發現有大量的iowait. 當時就懵逼了.
然後使用iotop檢視,發現 神通的程序有 150MB/S的流量無比震驚.
問題分析
透過sar 和 iotop 很確認 是資料庫的io存在問題.
但是虛擬機器在SSD 上面並且 20k io.s 以及 300MB/s 的速度幾乎是很強大的存在了.
此時聯絡了資料庫的工程師. 懷疑是引數不正確.
自己記得安裝時調整過但是一查才發現, 自己這次非常low
isql 輸入密碼
show data ;
然後發現
BUF_DATA_BUFFER_PAGES | 8192
需要注意, 神通資料庫使用page 進行表示大小
8k個 8K大小的頁面,合計就是 64MB的 buff區域
自己無比震驚 (預設值也太小了吧.)
自己發現自己一直在
/opt/ShenTong/admin/oscar.conf
進行修改.
但是工程師告訴我 這其實是 模板檔案.
真正的檔案是資料庫例項名.conf 也就是
/opt/ShenTong/admin/OSRDB.conf
增加配置並且重啟
XMLOPTION=1
BUF_DATA_BUFFER_PAGES=819200
SORT_MEM=409600
HOTSTANDBY_DATABASE_TYPE=0
ENABLE_HA_SINGLE_ALIVE=false
HA_SINGLE_ALIVE_KEEP_ELECTION_MS=180000
DATEFORMAT='YYYY-MM-DD HH24:MI:SS'
HA_ELECTION_TIMEOUT_MS=10000
HA_HEARTBEAT_PERIOD_MS=1000
HA_SLAVE_WRITE_BUFFER_BLOCK_NUM=655350
HA_SLAVE_QUERY_WAIT_TIMEOUT=0
BUF_GROUP_WRITE_SIZE=512
HA_GATEWAY=''
HA_SUB_MASK=''
HA_SERVER_IP_ADDRESS=''
HA_LOCAL_NET_DEV_NAME=''
ENABLE_GUID_GROUP=true
ONLY_FULL_GROUP_BY=false
NAME_CASE_SENSITIVE=true
ENABLE_SORT_WM_CONTACT=FALSE
FORCE_EXPAND_AEXPR_IN_NUM=100
MAX_OR_EXPR_USING_MULTI_INDEX=101
ENABLE_SCALARARRAYOPEXPR_TO_VALUES=true
ENABLE_EXPAND_AEXPR_IN=false
LOADBUFFERLEVEL=3
ENABLE_SQL_STAT=true
ENABLE_TIME_STAT=true
配置說明
將buffer區域修改為 6.4G
其他的都是一些正常處理的過程.
然後自己還關閉了測試環境的歸檔, 避免磁碟佔用
alter database noarchivelog;
然後重啟 指令碼一般為:
/etc/init.d/oscardb_OSRDBd start
/etc/init.d/oscardb_OSRDBd stop
前後資源使用情況對照
總結
一定注意配置檔案的正確性
設定完後一定要透過命令號進行檢查.
要時刻注意虛擬機器的異常情況. 尤其是這個如此大IO的場景
雖然是大量的讀沒有寫入. 但是依舊對系統有很大的損害
感謝原廠工程師的大力幫助.
情況對照頁說明, 記憶體的配置對 CPU的使用情況有著非常巨大的影響
CPU 其實是最難進行調優的. 一般需要對記憶體 IO, 以及程式碼進行調整
來實現對CPU的無用消耗.