神通數據庫測試環境調優過程
背景
同事中午時反饋一個環境速度很慢.
我通過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的無用消耗.
