f 資料細度(data granularity) ~ 迪貝之家

Pages

資料細度(data granularity)

這個案例是在行銷部門做活動時,Postgres 資料庫所發生的錯誤,它比較麻煩的是,之前就發生過兩次 sorry, too many clients already,但沒有發生任何障礙,所以日檢發現後通知AP單位,他們沒理我。但這次被鬧大了,因為HA切換中斷了服務太久。 系統上的user process limit 設為1024,資料庫連線的max_connections 設為1000,再加上其他的Process的運作,就觸發了RHCS進行HA切換,又好死不死地,切換因為某些因素不成功而卡著,所以被深深地關心了一下下
could not fork new process for connection: Resource temporarily unavailable




發生問題時,我是被質疑,是不是有額外的管理session耗光了資源,我當下是腹誹了一陣。主機單位提出他們的效能數據,顯示CPU及記憶體資源都很充足,我當時就覺得,你是在跟我說笑話嗎?? 資料庫的系統記錄是甚麼 ?? 被要求開會面對面檢討,我當時忙得要死,再加上手上沒資料,我就直接說"沒空",你們想要怎麼做,我就是配合。

因為是固定週期性活動,再次活動時間前十分鐘左右進了系統下了指令vmstat 5 1000,output 如下
vmstat

硬體就只有40 Core,第一個欄位run queue的值就已經有超過40的狀況了,再去對照其他我標出紅色的數值,這是系統資源很充足的狀態嗎?系統在活動期間,有1~2分鐘的時間是處於 CPU資源被耗盡的狀態,主機單位他們的工具抓取資料的間隔應該至少都是5分鐘。我看完資料後,就mail 給主機單位的主管及負責人我的結論

再隔一個禮拜,他就來跟我說兩個點
1. 他們有trace DBA端使用的process,用量很少
2. AP在很短的時間內爆量把資源用光會調降AP 連線數
接著提到,主機端會調整ulimit值,資料庫端不需做任何處理
這個案例,我想要講的是,DBA不講話不表示沒意見,只是沒有充分的證據來表達意見,DBA是一個專業度很高的職務,所以懂的東西不會比主機單位少