CPU性能篇-平均负载-Day 01

news2024/11/27 16:34:21

1. 平均负载

1.1 什么是平均负载

平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。

1.1.1 什么是可运行状态

指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用 top 命令看到的，处于 R 状态（Running 或 Runnable）的进程。

1.1.2 什么是不可中断状态

不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 top 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。
 

比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。

1.1.3 总结

既然平均的是活跃进程数，那么最理想的，就是每个 CPU 上都刚好运行着一个进程，这样每个 CPU 都得到了充分利用。比如当平均负载为 2 时，意味着什么呢？

  • 在只有 2 个 CPU 的系统上，意味着所有的 CPU 都刚好被完全占用。
  • 在 4 个 CPU 的系统上，意味着 CPU 有 50% 的空闲。
  • 而在只有 1 个 CPU 的系统中，则意味着有一半的进程竞争不到 CPU。

1.2 平均负载为多少时合理

平均负载最理想的情况是等于 CPU 个数。

1.2.1 查看系统cpu逻辑个数

[root@test-apollo ~]# grep 'model name' /proc/cpuinfo | wc -l # 这里为4个CPU
4

# 用top也可以 但是cpu如果很多的时候，top可能显示不完全
top - 17:27:31 up 3 days,  2:00,  2 users,  load average: 0.06, 0.03, 0.05
Tasks: 189 total,   1 running, 188 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.3 us,  0.0 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.3 us,  0.7 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.3 us,  0.7 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

1.3 分析平均负载的三个时间段

  • 如果 1 分钟、5 分钟、15 分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。
  • 但如果 1 分钟的值远小于 15 分钟的值，就说明系统最近 1 分钟的负载在减少，而过去 15 分钟内却有很大的负载。
  • 反过来，如果 1 分钟的值远大于 15 分钟的值，就说明最近 1 分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦 1 分钟的平均负载接近或超过了 CPU 的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。

1.4 如何关注生产的平均负载

当平均负载高于 CPU 数量 70% 的时候，就应该分析排查负载高的问题了，因为一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。
 

但 70% 这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。当发现负载有明显升高趋势时，比如说负载翻倍了，再去做分析和调查。

2. 平均负载与 CPU 使用率的区别

2.1 平均负载

平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待 I/O 的进程。

2.2 CPU 使用率

CPU 使用率指单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。比如：

  • CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
  • I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
  • 大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。

3. 平均负载案例分析

3.1 使用工具及系统

3.1.1 系统、配置及使用的软件

系统：CentOS 7(linux都可以)
工具：iostat、mpstat、pidstat等
机器配置：2 CPU，8GB 内存。
安装包：stress 和 sysstat 包。

3.1.2 工具介绍

  • stress包：是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。
  • stress-ng：stress的进阶版，更加强大，弥补的使用stress包测试IO时，%iowait无法升高的问题。
  • sysstat包：包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。
  • mpstat：是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
  • pidstat：是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。
  • iotop: 是一个类似 top 的工具，用来显示实时的磁盘活动。

3.1.3 注意事项

每个场景都需要开三个终端，登录到同一台 Linux 机器中。

3.1.4 工具包安装与升级

3.1.4.1 sysstat包升级

由于CentOS 7 自带的sysstat包版本太低，导致pidstat输出中没有%wait，升级到11.5.5版本以后就可以看到。
官网地址：http://sebastien.godard.pagesperso-orange.fr。
下载最新稳定版本即可。

[root@test-apollo ~]# wget http://pagesperso-orange.fr/sebastien.godard/sysstat-12.4.5.tar.xz
[root@test-apollo ~]# rpm -e --nodeps sysstat
[root@test-apollo ~]# yum -y install gcc gcc-c++
[root@test-apollo ~]# tar Jxf sysstat-12.4.5.tar.xz
[root@test-apollo ~]# cd sysstat-12.4.5/
[root@test-apollo sysstat-12.4.5]# ./configure --prefix=/usr
[root@test-apollo sysstat-12.4.5]# make install
[root@test-apollo ~]# pidstat -V
sysstat version 12.4.5
(C) Sebastien Godard (sysstat <at> orange.fr)

3.1.4.2 stress-ng包安装

在虚拟机测试过程中使用stress，会导致iowait无法升高，因为案例中stress使用的是 sync() 系统调用，它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机，缓冲区可能比较小，无法产生大的IO压力，这样大部分就都是系统调用的消耗了。

解决办法：使用stress的下一代stress-ng，它支持更丰富的选项，比如 stress-ng -i 1 --hdd 1 --timeout 600（--hdd表示读写临时文件）。

[root@test-apollo ~]# yum -y install stress-ng

3.1.4.3 stress包安装
[root@test-apollo ~]# yum -y install stress

3.2 场景一：CPU 密集型进程

3.2.1 在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景

[root@test-apollo ~]# stress --cpu 1 --timeout 600
stress: info: [1630] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

3.2.2 在第二个终端运行 uptime 查看平均负载的变化情况

[root@test-apollo ~]# watch -d uptime # -d, 参数表示高亮显示变化的区域
……省略部分输出
17:58:42 up 8 min,  3 users,  load average: 1.22, 0.76, 0.35 # 1分钟的负载，会慢慢变成1或者超过

3.2.3 在第三个终端运行 mpstat 查看 CPU 使用率的变化情况

从终端三中可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。

[root@test-apollo ~]# mpstat -P ALL 5 # -P ALL 表示监控所有CPU，后面数字5表示间隔5秒后输出一组数据
Linux 3.10.0-1062.el7.x86_64 (test-apollo)      08/08/2022      _x86_64_        (2 CPU)

05:59:35 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:59:40 PM  all   50.20    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   49.60
05:59:40 PM    0    0.20    0.00    0.40    0.00    0.00    0.00    0.00    0.00    0.00   99.40
05:59:40 PM    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00

3.2.4 用 pidstat 来查询使用cpu100%的进程

[root@test-apollo ~]# pidstat -u 5 1 # 间隔5秒后输出一组数据
Linux 3.10.0-1062.el7.x86_64 (test-apollo)      08/09/2022      _x86_64_        (2 CPU)

11:30:46 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
11:30:51 AM     0      3757  100.00    0.00    0.00    0.00  100.00     0  stress  # 从这里可以明显看到，stress 进程的 CPU 使用率为 100%。
11:30:51 AM     0      3826    0.00    0.20    0.00    0.00    0.20     1  pidstat

Average:      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
Average:        0      3757  100.00    0.00    0.00    0.00  100.00     -  stress
Average:        0      3826    0.00    0.20    0.00    0.00    0.20     -  pidstat

3.3 场景二：I/O 密集型进程

3.3.1 模拟I/O 压力

首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync。

[root@test-apollo ~]# stress-ng -i 1 --hdd 1 --timeout 600
stress-ng: info:  [3454] dispatching hogs: 1 hdd, 1 io

3.3.2 查看平均负载

在第二个终端运行 uptime 查看平均负载的变化情况。

[root@test-apollo ~]# watch -d uptime
……省略部分输出
18:08:50 up 18 min,  3 users,  load average: 1.13, 0.92, 0.64 # 1分钟的负载会慢慢变成1甚至超过

3.3.3 查看cpu使用率

第三个终端运行 mpstat 查看 CPU 使用率的变化情况

[root@test-apollo ~]# mpstat -P ALL 5 1 # 从下图可以看到，磁盘IO等待已经%97.8了
Linux 3.10.0-1062.el7.x86_64 (test-apollo)      08/09/2022      _x86_64_        (2 CPU)

10:17:11 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
10:17:16 AM  all    0.10    0.00    0.90   49.05    0.00    0.00    0.00    0.00    0.00   49.95
10:17:16 AM    0    0.20    0.00    1.80   97.80    0.00    0.20    0.00    0.00    0.00    0.00
10:17:16 AM    1    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.80

Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:     all    0.10    0.00    0.90   49.05    0.00    0.00    0.00    0.00    0.00   49.95
Average:       0    0.20    0.00    1.80   97.80    0.00    0.20    0.00    0.00    0.00    0.00
Average:       1    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.80

从上面可以看到，1 分钟的平均负载会慢慢增加到 1.13，其中 iowait 高达 97.80%。这说明，平均负载的升高是由于 iowait 的升高。


3.3.4 查找导致负载变高的进程

[root@test-apollo ~]# pidstat -u 5 1 # 可以看到 负载升高还是由stress-ng造成的
Linux 3.10.0-1062.el7.x86_64 (test-apollo)      08/09/2022      _x86_64_        (2 CPU)

11:33:53 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
11:33:58 AM     0         9    0.00    0.20    0.00    1.79    0.20     0  rcu_sched
11:33:58 AM     0       507    0.00    0.20    0.00    0.00    0.20     1  kworker/1:1H
11:33:58 AM     0      3819    0.00    0.40    0.00    0.60    0.40     1  kworker/1:1
11:33:58 AM     0      3825    0.00    0.20    0.00    0.00    0.20     0  kworker/0:0
11:33:58 AM     0      3828    0.40   24.90    0.00    0.20   25.30     0  stress-ng-hdd
11:33:58 AM     0      3829    0.00   11.16    0.00    1.79   11.16     1  stress-ng-io
11:33:58 AM     0      3830    0.00    7.37    0.00    1.20    7.37     1  kworker/u4:0
11:33:58 AM     0      3924    0.00    0.40    0.00    0.00    0.40     0  pidstat

Average:      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
Average:        0         9    0.00    0.20    0.00    1.79    0.20     -  rcu_sched
Average:        0       507    0.00    0.20    0.00    0.00    0.20     -  kworker/1:1H
Average:        0      3819    0.00    0.40    0.00    0.60    0.40     -  kworker/1:1
Average:        0      3825    0.00    0.20    0.00    0.00    0.20     -  kworker/0:0
Average:        0      3828    0.40   24.90    0.00    0.20   25.30     -  stress-ng-hdd
Average:        0      3829    0.00   11.16    0.00    1.79   11.16     -  stress-ng-io
Average:        0      3830    0.00    7.37    0.00    1.20    7.37     -  kworker/u4:0
Average:        0      3924    0.00    0.40    0.00    0.00    0.40     -  pidstat

3.4 场景三：大量进程的场景

当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。

3.4.1 使用 stress模拟 8 个进程

[root@test-apollo ~]# stress -c 8 --timeout 600
stress: info: [4544] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd

3.4.2 查看系统负载

由于系统只有 2 个 CPU，明显比 8 个进程要少得多，因而，系统的 CPU 处于严重过载状态，平均负载高达 6.85

[root@test-apollo ~]# uptime
 10:32:36 up 16:42,  4 users,  load average: 6.85, 3.79, 2.42

3.4.3 查看进程

从下面返回的结果可以看出，8 个进程（stress）在争抢 2 个 CPU，每个进程等待 CPU 的时间（ %wait 列）高达 75%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。

[root@test-apollo ~]# pidstat -u 5 1
Linux 3.10.0-1062.el7.x86_64 (test-apollo)      08/09/2022      _x86_64_        (2 CPU)

11:35:34 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
11:35:39 AM     0      3996   24.95    0.00    0.00   74.85   24.95     1  stress
11:35:39 AM     0      3997   24.95    0.00    0.00   75.25   24.95     0  stress
11:35:39 AM     0      3998   24.95    0.00    0.00   75.25   24.95     0  stress
11:35:39 AM     0      3999   24.95    0.00    0.00   75.25   24.95     0  stress
11:35:39 AM     0      4000   24.95    0.00    0.00   74.85   24.95     1  stress
11:35:39 AM     0      4001   24.95    0.00    0.00   75.05   24.95     1  stress
11:35:39 AM     0      4002   24.75    0.00    0.00   74.45   24.75     0  stress
11:35:39 AM     0      4003   24.95    0.00    0.00   75.25   24.95     1  stress
11:35:39 AM     0      4006    0.00    0.20    0.00    0.00    0.20     0  pidstat

Average:      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
Average:        0      3996   24.95    0.00    0.00   74.85   24.95     -  stress
Average:        0      3997   24.95    0.00    0.00   75.25   24.95     -  stress
Average:        0      3998   24.95    0.00    0.00   75.25   24.95     -  stress
Average:        0      3999   24.95    0.00    0.00   75.25   24.95     -  stress
Average:        0      4000   24.95    0.00    0.00   74.85   24.95     -  stress
Average:        0      4001   24.95    0.00    0.00   75.05   24.95     -  stress
Average:        0      4002   24.75    0.00    0.00   74.45   24.75     -  stress
Average:        0      4003   24.95    0.00    0.00   75.25   24.95     -  stress
Average:        0      4006    0.00    0.20    0.00    0.00    0.20     -  pidstat

4. 总结平均负载

平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时，也要注意：

  • 平均负载高有可能是 CPU 密集型进程导致的；
  • 平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；
  • 大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。
  • 当发现负载高的时候，可以使用 mpstat、pidstat 等工具，辅助分析负载的来源。

5. 使用百分比公式

(1.73-1)/1*100%=73%




 

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2189828.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

如何轻松查看你的 Windows 版本? 检查电脑Windows版本号五种方法

如何轻松查看你的 Windows 版本? 检查电脑Windows版本号五种方法

很多朋友发现windows拥有许多版本&#xff0c;比如如家庭版、企业版、专业版和教育版等&#xff0c;而每个版本都有相应的版本号&#xff0c;那么&#xff0c;怎么知道电脑windows版本呢&#xff1f;下面分享五种查看方法 自 1985 年首次推出以来&#xff0c;Windows 操作系统…
阅读更多...
IntelliJ IDEA 2024.2 新特性概览

IntelliJ IDEA 2024.2 新特性概览

文章目录 1、重点特性:1.1 改进的 Spring Data JPA 支持1.2 改进的 cron 表达式支持1.3 使用 GraalJS 作为 HTTP 客户端的执行引擎1.4 更快的编码时间1.5 K2 模式下的 Kotlin 性能和稳定性改进 2、用户体验2.1 改进的全行代码补全2.2 新 UI 成为所有用户的默认界面2.3 Search E…
阅读更多...
利用CRITIC客观权重赋权法进行数值评分计算——算法过程

利用CRITIC客观权重赋权法进行数值评分计算——算法过程

1、概述 ‌CRITIC客观评价法是一种基于指标的对比强度和指标之间的冲突性来确定指标客观权数的方法。‌ 该方法适用于判断数据稳定性&#xff0c;并且适合分析指标或因素之间有着一定的关联的数据‌。 CRITIC方法的基本原理包括两个主要概念&#xff1a;对比强度和指标之间的…
阅读更多...
Linux学习笔记（六）：服务管理，监控，RPM包管理，yum包管理工具，Linux启动管理，网络管理

Linux学习笔记（六）：服务管理，监控，RPM包管理，yum包管理工具，Linux启动管理，网络管理

Linux学习笔记&#xff08;六&#xff09;&#xff1a;服务管理&#xff0c;监控&#xff0c;RPM包管理&#xff0c;yum包管理工具&#xff0c;Linux启动管理&#xff0c;网络管理 1. 服务管理 1.1 service 启动/停止服务 service 命令是最常用的服务管理工具之一&#xff0c…
阅读更多...
介质的分类

介质的分类

在有损的麦克斯韦方程中等效介电常数如下 所以理想介质的介电常数接近于实数&#xff0c;导体介电常数接近于复数 介质分类中不规定εμσ是实数还是复数&#xff0c;带入这个麦克斯韦方程组就行。不过在有损介质的电磁波公式推导中老师做出εμσ是实数的假设
阅读更多...
【微服务】负载均衡 - LoadBalancer（day4）

【微服务】负载均衡 - LoadBalancer（day4）

下述所有代码都是在订单服务中修改的&#xff0c;商品服务并不需要修改&#xff0c;只需要启动多个实例即可。 引入 在介绍Eureka组件的最后&#xff0c;留下了一个问题就是&#xff0c;无论启动多少个实例&#xff0c;只能调用第一个。原因是因为服务调用时获取的是一个实例…
阅读更多...
LM74912-Q1用作电源开关

LM74912-Q1用作电源开关

LM74912电路设计及开发 LM74912-Q1&#xff0c;此芯片集成过压和短路保护以及故障输出功能的汽车理想二极管。正常的型号如下&#xff1a;LM74912QRGERQ1。 注&#xff1a; Q1的后缀指示此器件满足车规级器件/芯片要求。 一、原理框图 如下为芯片的简单应用框图&#xff1b;…
阅读更多...
【可答疑】基于51单片机的数字时钟（含仿真、代码、报告等）

【可答疑】基于51单片机的数字时钟（含仿真、代码、报告等）

✨哈喽大家好&#xff0c;这里是每天一杯冰美式oh&#xff0c;985电子本硕&#xff0c;大厂嵌入式在职0.3年&#xff0c;业余时间做做单片机小项目&#xff0c;有需要也可以提供就业指导&#xff08;免费&#xff09;~ &#x1f431;‍&#x1f409;这是51单片机毕业设计100篇…
阅读更多...
脱口秀演员调侃王楚钦引争议

脱口秀演员调侃王楚钦引争议

听说脱口秀演员调侃王楚钦输球&#xff0c;野生喜剧回应暂停演出合作&#xff0c;这不仅引发了关于脱口秀表演冒犯边界的讨论&#xff0c;也让我们反思言论自由与尊重他人之间的界限。 脱口秀作为一种艺术形式&#xff0c;其核心在于通过幽默、讽刺的方式&#xff0c;对社会现象…
阅读更多...
畅享免费服务：PDF 转图片在线转换软件的魅力

畅享免费服务：PDF 转图片在线转换软件的魅力

为了方便在社交媒体上分享文档内容&#xff0c;还为了更好地适应特定的编辑需求&#xff0c;将 PDF 文件转换为图片格式都具有重要的意义。而如今&#xff0c;幸运的是&#xff0c;有许多pdf转图片在线转换免费工具为我们提供了便捷、高效的 PDF 转图片服务。接下来&#xff0c…
阅读更多...
如何使用ssm实现基于SSM的宠物服务平台的设计与实现+vue

如何使用ssm实现基于SSM的宠物服务平台的设计与实现+vue

TOC ssm779基于SSM的宠物服务平台的设计与实现vue 绪论 1.1 研究背景 当前社会各行业领域竞争压力非常大&#xff0c;随着当前时代的信息化&#xff0c;科学化发展&#xff0c;让社会各行业领域都争相使用新的信息技术&#xff0c;对行业内的各种相关数据进行科学化&#x…
阅读更多...
浅谈模型量化：非对称 vs 对称

浅谈模型量化：非对称 vs 对称

模型量化的背后究竟做了什么&#xff1f;本文将以 INT8 为例&#xff0c;结合计算和代码演示&#xff0c;向你展示其中的一些原理。 相关论文: LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale 相关文章: 《07. 模型参数与显存的关系&#xff0c;以及不同精…
阅读更多...
【机器学习】探索GRU：深度学习中门控循环单元的魅力

【机器学习】探索GRU：深度学习中门控循环单元的魅力

目录 &#x1f354; GRU介绍 &#x1f354; GRU的内部结构图 2.1 GRU结构分析 2.2 GRU工作原理 2.4 Bi-GRU介绍 2.3 使用Pytorch构建GRU模型 2.5 GRU优缺点 &#x1f354; 小结 学习目标 &#x1f340; 了解GRU内部结构及计算公式. &#x1f340; 掌握Pytorch中GRU工具…
阅读更多...
map和 set

map和 set

[本节目标] 关联式容器 键值对 树形结构的关联式容器 底层结构 &#x1f3f7;️ 关联式容器 序列式容器&#xff1a;vector list 栈 队列 (类似以前学习的线性表)… 关联式容器&#xff1a; map set … 关联式容器&#xff0c;数据与数据之间有很强的关联&#xff0c;并…
阅读更多...
C++函数指针类型

C++函数指针类型

// // Created by 徐昌真 on 2024/10/5. // #include <iostream>//函数指针类型 指针变成了一个类型 类似int这种 用于反复调用这个函数指针的情况 避免频繁创建一堆的函数指针using namespace std;typedef void (*fptr)(int a, double b, char c); //typedef 将fptr定义…
阅读更多...
LLaVA-MoLE：解决多模态大模型指令微调中的数据冲突问题

LLaVA-MoLE：解决多模态大模型指令微调中的数据冲突问题

人工智能咨询培训老师叶梓 转载标明出处 多模态大模型&#xff08;MLLMs&#xff09;通过指令微调&#xff08;instruction finetuning&#xff09;&#xff0c;能够执行各种任务&#xff0c;如理解图表、处理文档和回答基于图像的问题。但是&#xff0c;当从不同领域混合指令…
阅读更多...
29 基于51单片机的汽车倒车防撞报警器系统

29 基于51单片机的汽车倒车防撞报警器系统

目录 一、主要功能 二、硬件资源 三、程序编程 四、实现现象 一、主要功能 本课题基于微控制器控制器&#xff0c; 设计一款汽车倒车防撞报警器系统。 要求&#xff1a; 要求&#xff1a;1.配有距离&#xff0c; 用于把车和障碍物之间的距离信号送入控制器。 2.配有报警系…
阅读更多...
MyBatis-Plus 字段对应不上或字段在MySQL中为关键字

MyBatis-Plus 字段对应不上或字段在MySQL中为关键字

MyBatis-Plus 名称对应不上比如在新增时如果名字对应不上或者改字段字段在MySQL中为关键子&#xff0c;在执行SQL操作的时候都会报错 解决方法 问题&#xff1a;如果是表名出现对应不上 解决方法&#xff1a;在Java实体类上加TableName("数据库表名") 问题&#…
阅读更多...
家具行业数字化转型利器：三品PLM系统全生命周期管理方案

家具行业数字化转型利器：三品PLM系统全生命周期管理方案

家具行业数字化转型利器&#xff1a;三品PLM系统全生命周期管理方案 在当今竞争激烈的家具行业中&#xff0c;面对设计图纸版本混乱、成本估算不准确、生产流程不透明等挑战&#xff0c;传统的研发管理模式显得力不从心。 而PLM产品生命周期管理系统的引入&#xff0c;为行业…
阅读更多...
P1088 [NOIP2004 普及组] 火星人

P1088 [NOIP2004 普及组] 火星人

思路就是 全排列中找到题目所给的组合 然后加上的最小数就是往后面数几个组合 就是要求的那个排列 然后输出 我写的那一份代码ac了两个点 其他 全部tle 估计是比较的时间复杂度太高了暴力写法的时间复杂度比内置函数要大很多 暴力208ms 内置31ms 暴力 #include<bits/std…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023