一次redis調優的過程

記錄一次redis調優的過程，這次事故主要是測試組人員那邊 在給我們測試的時候發現的，有個介面返回資料特別慢，之後我們就去排查問題，結果就發現了是 redis的延遲問題。那究竟是怎麼回事呢？請看下面

根據日誌的提示，找到**中用到redis的**，檢視是是因為大key或者是大value造成的延遲問題，最後發現不是。

最後看了下伺服器的 配置檔案，發現是開啟了記憶體大頁，後來講這個記憶體大頁關閉後演出 情況就好了

一般應用程式向作業系統申請記憶體時，是按記憶體頁進行申請的，而常規的記憶體頁大小是4kb。linux核心從2.6.38開始，支援了記憶體大頁機制，該機制執行應用程式以2mb大小為單位，向作業系統申請記憶體。應用程式每次向作業系統申請的記憶體單位變大了，這 也就意味著申請記憶體的耗時邊長。

這樣對redis的效能 影響如下：

主程序在拷貝記憶體資料時，這個階段就涉及到了新記憶體的 申請，如果此時操作 系統開啟了大頁，那麼在此期間，客戶單即便只修改10b的資料，也要申請2mb的記憶體大小，申請記憶體就會耗時，進而就會導致整個寫請求的時間延遲增加，影響到redis的效能。

雖然開啟記憶體大頁，能夠降低應用程式申請記憶體的次數，但對於效能和延遲極其敏感的資料庫來說，不建議開啟

記一次oracle sql調優過程

這裡兩天都在對一條sql進行調優。該sql並不複雜,類似於 select from some view union all select from some table where datetime d1 and datetime d2 and 底層使用ibatis2.1.6 oracle 10g。...

記錄一次查詢調優過程

調優過程中使用explain命令檢視執行過程，包括執行時間 掃瞄方式 是否用到索引等，explain 使用 timing on timing off 乙個查詢介面被頻繁呼叫，且查詢過程較慢 首先考慮優化sql語句 其次考慮優化業務 最後考慮是否需要新增快取機制 3.1 優化sql 原始sql，分組查...

記錄一次系統效能調優過程

問題回顧 問題清單 模組合併過程中各種衝突，各種bean無法正常載入 事件處理效能原來每秒3000 1w左右，現在突然驟降至幾百左右 事件存在丟失現象，而且丟失比較嚴重 發現系統cache一直在不斷的 free m 後發現可餘記憶體幾乎用沒了 剩餘100m左右，其實就差不多是用完了，不會再降低 1....