一幅图秒懂LoadAverage(负载)

本文深入解析Linux系统负载概念,通过类比马路与汽车说明负载含义,介绍如何使用top、w和uptime命令查看系统负载,并分析不同负载值所代表的系统状态,提供了一种直观理解负载的方法。

载:http://www.habadog.com/2015/02/27/what-is-load-average/

一幅图秒懂LoadAverage(负载)

 

 

 

 

一、什么是Load Average?

系统负载(System Load)是系统CPU繁忙程度的度量,即有多少进程在等待被CPU调度(进程等待队列的长度)。

平均负载(Load Average)是一段时间内系统的平均负载,这个一段时间一般取1分钟、5分钟、15分钟。

 

二、如何查看Load?

top命令,w命令,uptime等命令都可以查看系统负载:

[shenjian@dev02 ~]$ uptime

13:53:39 up 130 days,  2:15,  1 user,  load average: 1.58, 2.58, 5.58

如上所示,dev02机器1分钟平均负载,5分钟平均负载,15分钟平均负载分别是1.58、2.58、5.58

 

三、Load的数值是什么含义?

把CPU比喻成一条(单核)马路,进程任务比喻成马路上跑着的汽车,Load则表示马路的繁忙程度:

Load小于1:表示完全不堵车,汽车在马路上跑得游刃有余:

[ Load<1,单核]

Load等于1:马路已经没有额外的资源跑更多的汽车了:

[Load==1,单核]

Load大于1:汽车都堵着等待进入马路:

[Load>1,单核]

如果有两个CPU,则表示有两条马路,此时即使Load大于1也不代表有汽车在等待:

[Load==2,双核,没有等待]

 

四、什么样的Load值得警惕(单核)?

Load < 0.7时:系统很闲,马路上没什么车,要考虑多部署一些服务

0.7 < Load < 1时:系统状态不错,马路可以轻松应对

Load == 1时:系统马上要处理不多来了,赶紧找一下原因

Load > 5时:马路已经非常繁忙了,进入马路的每辆汽车都要无法很快的运行

 

五、三个Load值要先看哪一个?

结合具体情况具体分析:

1)1分钟Load>5,5分钟Load<1,15分钟Load<1:短期内繁忙,中长期空闲,初步判断是一个“抖动”,或者是“拥塞前兆”

2)1分钟Load>5,5分钟Load>1,15分钟Load<1:短期内繁忙,中期内紧张,很可能是一个“拥塞的开始”

3)1分钟Load>5,5分钟Load>5,15分钟Load>5:短中长期都繁忙,系统“正在拥塞”

4)1分钟Load<1,5分钟Load>1,15分钟Load>5:短期内空闲,中长期繁忙,不用紧张,系统“拥塞正在好转”

 

六、Load总结

[ Load<1,单核]

[Load==1,单核]

[Load>1,单核]

[Load==2,双核]

希望上面一幅图对大家理解Load Average有帮助,赶快uptime一下,看一下自己系统的负载吧。

 

 

# 总核数 = 物理CPU个数 X 每颗物理CPU的核数
# 总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数

# 查看物理CPU个数
cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l

# 查看每个物理CPU中core的个数(即核数)
cat /proc/cpuinfo| grep "cpu cores"| uniq

# 查看逻辑CPU的个数
cat /proc/cpuinfo| grep "processor"| wc -l

 

https://www.cnblogs.com/ketangxiaohai/p/9617897.html

### 使用 Perfetto SQL 查询系统负载的方法 Perfetto 提供了一种灵活的方式来查询和分析系统性能数据,其中包括系统负载的监控。以下是一些常用方法和具体示例,展示如何通过 Perfetto SQL 来查询系统负载。 #### 1. **`cpu_usage` 表** `cpu_usage` 表记录了 CPU 的使用情况,包括每个核心的利用率以及整体系统的 CPU 占用率。这有助于评估当前系统的计算能力是否被充分利用或是否存在瓶颈。 ```sql SELECT ts, cpu, value AS usage_percent FROM counter c JOIN cpu_counter_track t ON c.track_id = t.id WHERE name = 'cpu.utilization'; ``` #### 2. **`sched` 表** `sched` 表包含了调度器活动的历史记录,这对于理解线程何时处于运行状态、睡眠状态或是等待 I/O 阻塞非常重要。通过对这些信息进行聚合处理,可以获得更详细的系统负载。 ```sql WITH total_time_per_thread AS ( SELECT utid, SUM(dur) as total_duration_ms FROM sched GROUP BY utid ) SELECT thread.name AS thread_name, tt.total_duration_ms * 1e-6 AS total_runtime_s -- Convert microseconds to seconds FROM total_time_per_thread tt LEFT JOIN thread USING(utid); ``` #### 3. **`memory_snapshot` 和 `process_memory_map` 表** 对于内存方面的负载监测,可以结合 `memory_snapshot` 和 `process_memory_map` 表来进行深入研究。这样不仅可以观察全局内存消耗状况,还能针对特定进程做进一步剖析。 ```sql SELECT process.name AS proc_name, mss.value AS rss_kb -- Resident Set Size in kilobytes FROM memory_snapshot ms INNER JOIN process_memory_stat mss ON (ms.id=mss.snapshot_id) INNER JOIN process p ON (mss.upid=p.upid) WHERE stat_name="rss"; ``` #### 4. **综合查询:CPU + Memory 负载** 下面这个例子展示了如何同时提取 CPU 和内存两方面的主要指标,从而形成一幅完整的系统负载画像。 ```sql WITH system_load_data AS ( SELECT CAST(ts / 1000000 AS INT64) AS sec_since_epoch, AVG(value) OVER w_cpu AS avg_cpu_util_pct, MAX(mss.value) OVER w_mem AS max_rss_mb FROM counter c JOIN cpu_counter_track ct ON c.track_id=ct.id CROSS JOIN LATERAL unnest([c.ts]) _ts(sec_since_epoch), UNNEST(['rss']) AS mem_stats(stat_name), UNNEST([value*1e-6]) AS mem_values(rss_value_mb) WINDOW w_cpu AS (PARTITION BY FLOOR(c.ts/1000000)), w_mem AS () ) SELECT DISTINCT sl.sec_since_epoch, ROUND(sl.avg_cpu_util_pct, 2) AS average_cpu_usage_percentage, ROUND(MAX(sl.max_rss_mb), 2) AS peak_resident_set_size_megabytes FROM system_load_data sl; ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

hello_world!

你的鼓励将是我创作的最大动力!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值