上次通過巡檢發現數據庫以下問題：
1. 兩個節點間有大量的gc
詢問應用側開發人員， 整個庫一共三個用戶， UCR、UOP、UQRY， 其中 UCR是所有表的原始創建用戶， UOP是UCR用戶對應的程序操作用戶， UQRY是一個查詢用戶，有對UCR所有表的查詢權限。
應用側生產程序是通過UOP來連接數據庫，對所有的對象有DML的操作。除了我們自己的程序還有第三方程序通過UQRY來查詢UCR的表。
重點是UQRY在一節點， UOP在二節點， 這樣UCR的表會在兩個節點有大量的交叉查詢，從而導致GC。因此馬上建議應用側把所有的連接全部首先連接一節點。
修改完畢以後，GC問題解決
2. 內存問題
環境介紹： Linux 6.5 ，八路CPU， 64core ，內存256G
問題點：沒有啓用Hugepage，其中內存裏面PageTable佔用32G
free -m 可以看到系統有大量的內存被cached掉。
老庫的pagetable佔用到了29G！
dqg6ddspt1:~ # grep Page /proc/meminfo
AnonPages: 5079144 kB
PageTables: 29073708 kB
AnonHugePages: 2412544 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
dqg6ddspt1:~ #
dqg6ddspt1:~ # free -m
total used free shared buffers cached
Mem: 258298 122240 136058 0 178 85563
-/+ buffers/cache: 36498 221800
Swap: 32763 0 32763
調整參數如下：
vm.min_free_kbytes = 512000
vm.swappiness = 0
vm.dirty_ratio = 20
vm.vfs_cache_pressure = 200
調整以後需要重啓主機。
調整以後系統內存情況如下：
新庫的pagetable只佔用了128M。
huibuy1[/home/oracle]$grep Page /proc/meminfo
AnonPages: 2297620 kB
PageTables: 128736 kB
AnonHugePages: 0 kB
HugePages_Total: 44036
HugePages_Free: 12544
HugePages_Rsvd: 12541
HugePages_Surp: 0
huibuy1[/home/oracle]$
huibuy1[/home/oracle]$
huibuy1[/home/oracle]$free -m
total used free shared buffers cached
Mem: 258159 94725 163433 0 269 1543
-/+ buffers/cache: 92912 165246
Swap: 32767 0 32767
做完以上調整，運行至今一月有餘，內存使用率，連接數，高耗事件等以前的異常情況全部消失。數據庫系統運行穩定