国产欧美精品专区一区二区_91www永久在线精品果冻传媒_日韩成人亚洲综合专区无码av_欧美激情一区二区三区高清视频_免费福利在线视频亚洲_日韩精品无码人妻自慰喷水_把腿张开老子cao哭你动态图_51a性爱高清免费视频_国产无码资源在线观看資源免費看_再深点灬舒服灬太大了网站

前言

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

系統(tǒng)負(fù)載

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

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

系統(tǒng)負(fù)荷為 1.7，意味著車輛太多了，大橋已經(jīng)被占滿了 (100%)，后面等著上橋的車輛為橋面車輛的 70%。以此類推，系統(tǒng)負(fù)荷 2.0，意味著等待上橋的車輛與橋面的車輛一樣多；系統(tǒng)負(fù)荷 3.0，意味著等待上橋的車輛是橋面車輛的 2 倍?？傊?，當(dāng)系統(tǒng)負(fù)荷大于 1，后面的車輛就必須等待了；系統(tǒng)負(fù)荷越大，過橋就必須等得越久。

在實際生產(chǎn)系統(tǒng)中，一般不建議系統(tǒng)滿負(fù)荷運(yùn)行。通用的經(jīng)驗法則是：平均負(fù)載 = 0.7 * CPU 邏輯核數(shù)

?0.70：長期高于此值就值得關(guān)注；?1.00：持續(xù)超過 1 應(yīng)立即排查，否則很快就會告警；?5.00：意味著系統(tǒng)可能已極度卡頓，需要立刻介入，緊急處理。

橫截面趨勢

除了關(guān)注自身負(fù)載之外，"負(fù)載趨勢"也顯得尤為重要，瞬時負(fù)載告訴你"現(xiàn)在疼不疼"，而負(fù)載趨勢告訴你"病是怎么得的、會不會復(fù)發(fā)"。

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

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

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

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

瑞士軍刀 sar -q

又看到我們的老朋友了，是的，又是它 sar。前面介紹了使用 sar 分析網(wǎng)絡(luò)丟包排障的文章，sar 觀察負(fù)載也是一把好手

[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 —— 當(dāng)前處于 R 狀態(tài)的任務(wù)數(shù)

Process List Size —— 系統(tǒng)進(jìn)程 (線程) 總數(shù)

blocked —— 當(dāng)前處于 D 狀態(tài) (不可中斷，等待 I/O 完成) 的任務(wù)數(shù)， 值大表明正在卡磁盤 / 網(wǎng)絡(luò) / NFS / 復(fù)制；常與 iostat %util?&?await 一起看

數(shù)據(jù)庫負(fù)載

前面聊完了系統(tǒng)負(fù)載，那么關(guān)于數(shù)據(jù)庫，如何去衡量"負(fù)載"這個指標(biāo)呢？操作系統(tǒng)和數(shù)據(jù)庫畢竟是分開的，數(shù)據(jù)庫跑在操作系統(tǒng)之上，嚴(yán)格來說它們是系統(tǒng)的指標(biāo)，而非數(shù)據(jù)庫軟件自身的指標(biāo)，數(shù)據(jù)庫自身也可能因為各種原因出幺蛾子。

因此，回到數(shù)據(jù)庫自身，是否有類似的負(fù)載指標(biāo)？很可惜，原生 PostgreSQL 并沒有類似這樣的指標(biāo)，但是我們知道，一些 CLI 工具是包含 LOAD 這個指標(biāo)的，比如 pg_top、pg_activity、pg_views 等等。以 pg_top 為例：

那么這個 load 是如何計算出來的呢？可惜的是，pg_top 本身 從不計算 負(fù)載，只負(fù)責(zé)"搬運(yùn) + 排版"。

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);    }

而對于遠(yuǎn)程模式，獲取源端機(jī)器的負(fù)載，則借助于 pg_proctab 插件，同樣也是取自 OS，其提供了如下幾個函數(shù)：

?pg_cputime?pg_loadavg?pg_memusage?pg_proctab

因此，嚴(yán)格來說，數(shù)據(jù)庫的負(fù)載需要我們?nèi)プ孕杏嬎?/span>，感興趣的童鞋可以參照馮董的文章 PostgreSQL 的 KPI^[2]。

小結(jié)

負(fù)載是個好指標(biāo)，負(fù)載是個好指標(biāo)，負(fù)載是個好指標(biāo) ????

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/

轉(zhuǎn)載：https://mp.weixin.qq.com/s/QBS84VokX7jd7pACTjv1ZA