LOGO OA教程 ERP教程 模切知識交流 PMS教程 CRM教程 開發文檔 其他文檔  
 
網站管理員

PostgreSQL的黃金指標 — 負載

maoxiaoming
2025年8月12日 10:24 本文熱度 352

前言

在分析數據庫性能問題的時候,筆者尤其鐘愛負載這個指標,負載是"需求"與"能力"之間的直接差值,它橫跨 CPU 與 I/O,兩類瓶頸一眼可見,筆者在分析數據庫性能問題的時候,往往第一時間都先瞅瞅這個指標,再做后續判斷。這篇文章中,讓我們聊聊負載那些事兒。

系統負載

以 https://www.scoutapm.com/blog/understanding-load-averages[1] 為例,作者將負載定義為 run-queue length:即當前處于 Running 狀態 + D(不可中斷 I/O) 狀態的進程總數,不可中斷休眠狀態的進程一般是在等待 I/O 完成的進程,也就是說,它同時覆蓋了 CPU 和阻塞 I/O 的排隊情況。因此,不妨將系統負載看做是真實并發壓力的體溫計,負載既能做容量紅線,又能做性能診斷入口,堪稱是數據庫運維的 MVP 指標。在此文中,作者用"包含一車道的大橋"的交通比喻解釋數值含義:

?0.00 – 1.00 ? 橋面不排隊;?1.00 ? 剛好滿載;?1.00 ? 開始排隊,2.00 表示一條車道正行駛、一條車道在等,依此類推。

系統負荷為 1.7,意味著車輛太多了,大橋已經被占滿了 (100%),后面等著上橋的車輛為橋面車輛的 70%。以此類推,系統負荷 2.0,意味著等待上橋的車輛與橋面的車輛一樣多;系統負荷 3.0,意味著等待上橋的車輛是橋面車輛的 2 倍。總之,當系統負荷大于 1,后面的車輛就必須等待了;系統負荷越大,過橋就必須等得越久。

在實際生產系統中,一般不建議系統滿負荷運行。通用的經驗法則是:平均負載 = 0.7 * CPU 邏輯核數

?0.70:長期高于此值就值得關注;?1.00:持續超過 1 應立即排查,否則很快就會告警;?5.00:意味著系統可能已極度卡頓,需要立刻介入,緊急處理。

橫截面趨勢

除了關注自身負載之外,"負載趨勢"也顯得尤為重要,瞬時負載告訴你"現在疼不疼",而負載趨勢告訴你"病是怎么得的、會不會復發"。

?如果 load1 > load5 > load15,說明剛剛進入擁塞,查詢/IO 正在排隊,這個時候就需要立即采取動作,望聞問切,如果是高峰時段,可短暫擴容或快速限流。?如果 load1 < load5 < load15,說明負載消退中,可能是峰值過去、批量任務結束或索引命中率恢復,我們需要關注是否有殘留鎖、慢 VACUUM、慢查詢等尾巴,避免再次反彈。?另外也別忽視"負加速度":如果 load1 < 0.5 × load5,可能是故障恢復后流量驟降?若 load15 長期高而 CPU% 不高,多半是 I/O 慢或鎖爭用;優化難度往往更高,需要結構性調優,比如索引、建模、硬件升級等

歷史趨勢:從曲線讀出故事

1.日周期鋸齒,可能原因是固定批量任務 / 報表 / 備份,可以將批量作業移到離峰,加并行或分區2.周末平坦,而周一陡升,意味著周末流量低、緩存冷,可以熱備預熱、增加自動伸縮冷啟動窗口3.如果基線緩慢抬高,意味著平均訪問增多,新功能上線、數據集增大,我們可以重新對當前集群算力進行預估,跑基準驗證新版本 SQL4.忽高忽低"鋸齒",這種就相對要麻煩一些,判斷是否有鎖競爭、IO 突刺 (比如 checkpoint、freeze 風暴、索引失效等)

只有把 load 1/5/15 的加速度和歷史曲線一起納入監控,才能做到既能早預警、又能追根溯源,把數據庫性能問題扼殺在萌芽階段。

瑞士軍刀 sar -q

又看到我們的老朋友了,是的,又是它 sar。前面介紹了使用 sar 分析網絡丟包排障的文章,sar 觀察負載也是一把好手

    [postgres@mypg ~]$ sar -q 1Linux 3.10.0-1127.19.1.el7.x86_64 (mypg)        08/08/2025      _x86_64_        (2 CPU)
    04:42:08 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked04:42:09 PM         0       206      0.03      0.02      0.05         004:42:10 PM         0       206      0.03      0.02      0.05         004:42:11 PM         0       206      0.03      0.02      0.05         004:42:12 PM         1       206      0.03      0.02      0.05         0

    Run Queue Size —— 當前處于 R 狀態的任務數

    Process List Size —— 系統進程 (線程) 總數

    blocked —— 當前處于 D 狀態 (不可中斷,等待 I/O 完成) 的任務數, 值大表明正在卡磁盤 / 網絡 / NFS / 復制;常與 iostat %util?&?await 一起看

    數據庫負載

    前面聊完了系統負載,那么關于數據庫,如何去衡量"負載"這個指標呢?操作系統和數據庫畢竟是分開的,數據庫跑在操作系統之上,嚴格來說它們是系統的指標,而非數據庫軟件自身的指標,數據庫自身也可能因為各種原因出幺蛾子。

    因此,回到數據庫自身,是否有類似的負載指標?很可惜,原生 PostgreSQL 并沒有類似這樣的指標,但是我們知道,一些 CLI 工具是包含 LOAD 這個指標的,比如 pg_top、pg_activity、pg_views 等等。以 pg_top 為例:

    那么這個 load 是如何計算出來的呢?可惜的是,pg_top 本身 從不計算 負載,只負責"搬運 + 排版"。

      voidget_system_info(struct system_info *info){    char        buffer[4096 + 1];    int            fd,                len;    char       *p;
          /* get load averages */
          if ((fd = open("loadavg", O_RDONLY)) != -1)    {        if ((len = read(fd, buffer, sizeof(buffer) - 1)) > 0)        {            buffer[len] = '\0';            info->load_avg[0] = strtod(buffer, &p);            info->load_avg[1] = strtod(p, &p);            info->load_avg[2] = strtod(p, &p);            p = skip_token(p);    /* skip running/tasks */            p = skip_ws(p);            if (*p)            {                info->last_pid = atoi(p);            }            else            {                info->last_pid = -1;            }        }        close(fd);    }

      而對于遠程模式,獲取源端機器的負載,則借助于 pg_proctab 插件,同樣也是取自 OS,其提供了如下幾個函數:

      ?pg_cputime?pg_loadavg?pg_memusage?pg_proctab

      因此,嚴格來說,數據庫的負載需要我們去自行計算,感興趣的童鞋可以參照馮董的文章 PostgreSQL 的 KPI[2]

      小結

      負載是個好指標,負載是個好指標,負載是個好指標 ????

      References

      [1]https://www.scoutapm.com/blog/understanding-load-averages
      [2] PostgreSQL 的 KPI: https://blog.vonng.com/pg/pg-load/
      [3]https://www.scoutapm.com/blog/understanding-load-averages
      [4]http://jartto.wang/2020/01/20/system-load/
      [5]https://www.ruanyifeng.com/blog/2011/07/linux_load_average_explained.html
      [6]https://github.com/StabilityMan/StabilityMan.github.io/blob/main/docs/diagnosis/system/cpu/SoHot_%E5%BF%AB%E7%BB%99CPU%E9%99%8D%E9%99%8D%E6%B8%A9.md
      [7]: https://blog.vonng.com/pg/pg-load/

      轉載:https://mp.weixin.qq.com/s/QBS84VokX7jd7pACTjv1ZA


      該文章在 2025/8/12 10:26:08 編輯過
      關鍵字查詢
      相關文章
      正在查詢...
      點晴ERP是一款針對中小制造業的專業生產管理軟件系統,系統成熟度和易用性得到了國內大量中小企業的青睞。
      點晴PMS碼頭管理系統主要針對港口碼頭集裝箱與散貨日常運作、調度、堆場、車隊、財務費用、相關報表等業務管理,結合碼頭的業務特點,圍繞調度、堆場作業而開發的。集技術的先進性、管理的有效性于一體,是物流碼頭及其他港口類企業的高效ERP管理信息系統。
      點晴WMS倉儲管理系統提供了貨物產品管理,銷售管理,采購管理,倉儲管理,倉庫管理,保質期管理,貨位管理,庫位管理,生產管理,WMS管理系統,標簽打印,條形碼,二維碼管理,批號管理軟件。
      點晴免費OA是一款軟件和通用服務都免費,不限功能、不限時間、不限用戶的免費OA協同辦公管理系統。
      Copyright 2010-2025 ClickSun All Rights Reserved

      黄频国产免费高清视频,久久不卡精品中文字幕一区,激情五月天AV电影在线观看,欧美国产韩国日本一区二区
      亚洲2020一区二区中文字幕 | 亚洲日韩精品欧美一区二区 | 亚洲视频在线青青 | 日本亚洲欧美在线视观看在线观看 | 日韩~欧美一中文字幕 | 婷婷久久五月综合色国产 |