05｜容器CPU（1）：怎么限制容器的CPU使用？【request、limit】

最新推荐文章于 2024-04-20 19:08:26 发布
最新推荐文章于 2024-04-20 19:08:26 发布
阅读量2.2k 收藏 2
点赞数
分类专栏： 容器实战高手课 文章标签： linux 运维
原文链接：https://blog.csdn.net/u012271526/article/details/118094324
版权

从这一将开始，我们进入容器CPU这个模块。

容器在Linux系统中最核心的两个概念是 Namespace 和 Cgroups。 通过Cgroups 技术限制资源，可以分为很多类型，比如 CPU、Memory、Storage、Network等等。

今天说下如何限制容器的CPU 使用。
我们拿Kubernetes平台做例子，具体来看下面这个pod/container里的spec定义，在CPU资源相关的定义中有两项内容，分别是Request CPU和Limit CPU。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    env:
    resources:
      requests:	#请求资源，cpu.shares
        memory: "64Mi"
        cpu: "1"
      limits:	#限制资源，cpu.cfs_quota_us
        memory: "128Mi"
        cpu: "2"
…

上面Pod Spec 里的 Request CPU和Limit CPU的值，最后会通过 CPU Cgroup 的配置，来实现控制容器CPU 资源的作用。

那接下来我会先从进程的CPU使用讲起，然后带你在CPU Cgoup子系统中建立几个控制组，用这个例子为你讲解 CPU Cgroup 中三个重要的参数：

  • cpu.cfs_quota_us
  • cpu.cfs_period_us
  • cpu.shares


一、如何理解CPU使用和CPU Cgroup

CPU Cgroup最大的作用就是限制CPU使用


1.1 CPU 使用的分类

使用top命令，注意下图"%Cpu(s)"开头的这一行：
在这里插入图片描述
下面开始解释： 在这里插入图片描述 上图中的上半部分是用户态（user space）下半部分是内核态（kernel space），假设只有一个CPU。

【us】
当用户程序开始运行时，对应着第一个 ‘us’ 框，‘us’ 是 user 的缩写，代表 Linux 的用户态 CPU Usage，普通用户程序代码中，只要不是调用系统调用（System Call），这些代码指令消耗的CPU 都属于‘us’。

【sy】
当这个用户程序代码中调用了系统调用，比如说 read()去读取一个文件，这个时候用户进程就会从用户态切换到内核态。

内核态read()系统调用在读到真正 disk 上的文件前，就会进行一些文件系统层的操作，那么这些代码指令的消耗就属于‘sy’，这里就对应上面图中的第二个框 ’sy‘ 是 system的缩写，代表内核态CPU 使用。

【wa】
然后 read()系统调用会向Linux 的Block Layer 发出一个 I/O Request，触发一个真正的磁盘读取操作。

这个时候进程一般会被置为 TASK_UNINTERRUPTIBLE，Linux会把这段时间标示为 wa，对应图中第三个框，wa 是 iowait 的缩写，代表等待Disk I/O 的时间。

【sy】
当磁盘返回数据时，进程在内核态拿到数据，这里仍然是内核态的CPU 使用的"sy"，也就是图中的第四个框。

【us】
然后进程再从内核态切换回用户态，在内核态得到文件数据，这里进程又回到用户态的使用 us，对应图中的第五个框。

【id】
假设到这，进程就没事做了，CPU上也没有其他的进程需要运行。 系统就会进入到 id 这个步骤，也就是第六个框，id是 idle 的缩写。 代表系统处于空闲状态。

【hi】
如果这个时候机器的网络收到一个网络数据包，网卡就会发出一个中断（interrupt），响应的，CPU 会中断响应，然后进入中断服务程序。

这时 CPU 就会进入hi ，hi 是 hardware irq 的缩写，代表 CPU 处理硬中断的开销，由于中断服务处理需要关闭中断，所以这个硬中断不能时间太长。

【si】
中断后的工作必须要完成的，如果这些工作比较耗时怎么办呢？ Linux 中有一个软中断的概念（softirq） ，它可以完成这些耗时比较长的工作。

软中断：从网卡收到数据包的大部分工作，都是通过软中断来处理的。
CPU 会进入到第八个框，si， 这里的si 是softirq的缩写，代表CPU 处理软中断的开销。

hi，si 本身处理的时候不属于任何一个进程，它们的CPU 时间都不会进入到进程的CPU 时间。

  • PRI ：进程优先权，代表这个进程可被执行的优先级，其值越小，优先级就越高，越早被执行；
  • NI ：进程Nice值，代表这个进程的优先值；
  • %nice ：改变过优先级的进程的占用CPU的百分比；

PRI是比较好理解的，即进程的优先级，或者通俗点说就是程序被CPU执行的先后顺序，此值越小进程的优先级别越高。

【ni】
那NI呢？就是我们所要说的nice值了，其表示进程可被执行的优先级的修正数值。如前面所说，PRI值越小越快被执行，那么加入nice值后，将会使得PRI变为：PRI(new) = PRI(old) + nice。由此看出，PRI是根据NICE排序的，规则是NICE越小PR越前（小，优先权更大），即其优先级会变高，则其越快被执行。如果NICE相同则进程uid是root的优先权更大。

【st】
另外一个是st，st 是steal的缩写。是虚拟机里用的一个CPU 使用类型，表示有多少时间是被同一个宿主机上的其他虚拟机抢走的。

在这里插入图片描述

1.2 CPU Cgroup

Cgroups 是对指定进程做计算机资源限制的，CPU Cgroup 是Cgroups 其中的一个 Cgroups 子系统，它是用来限制进程的CPU 使用的。

cpu包括：

  • 用户态：us 和 ni
  • 内核态：sy

wa，hi，si 这些 I/O 或者中断相关的CPU 使用，CPU Cgroup 不会去做限制。

每个Cgroups 子系统都是通过一个虚拟文件系统挂载点的方式，挂到一个缺省的目录下，CPU Cgroup 一般在Linux 发行版里会放在 /sys/fs/cgroup/cpu 这个目录下。

在这个子系统的目录下，每个控制组（Control Group）都是一个子目录，各个控制组之间的关系就是一个树状的层级关系（hierarchy）

例如下图，每个group 就是一个控制组

在这里插入图片描述

自己创建一个目录 suhan1 控制组里面的内容如下，

    [root@hx19-dev01 suhan1]# pwd
    /sys/fs/cgroup/cpu/suhan1
    
    [root@hx19-dev01 suhan1]# ls -l
    总用量 0
    -rw-r--r--. 1 root root 0 6月  25 10:20 cgroup.clone_children
    --w--w--w-. 1 root root 0 6月  25 10:20 cgroup.event_control
    -rw-r--r--. 1 root root 0 6月  25 10:20 cgroup.procs
    -r--r--r--. 1 root root 0 6月  25 10:20 cpuacct.stat
    -rw-r--r--. 1 root root 0 6月  25 10:20 cpuacct.usage
    -r--r--r--. 1 root root 0 6月  25 10:20 cpuacct.usage_percpu
    -rw-r--r--. 1 root root 0 6月  25 10:20 cpu.cfs_period_us
    -rw-r--r--. 1 root root 0 6月  25 10:20 cpu.cfs_quota_us
    -rw-r--r--. 1 root root 0 6月  25 10:20 cpu.rt_period_us
    -rw-r--r--. 1 root root 0 6月  25 10:20 cpu.rt_runtime_us
    -rw-r--r--. 1 root root 0 6月  25 10:20 cpu.shares
    -r--r--r--. 1 root root 0 6月  25 10:20 cpu.stat
    -rw-r--r--. 1 root root 0 6月  25 10:20 notify_on_release
    -rw-r--r--. 1 root root 0 6月  25 10:20 tasks

在云平台里，大部分程序都不是实时调度进程，而是普通调度（SCHED_NORMAL） 类型进程，那什么是普通类型进程呢。

目前Linux中的普通调度的算法是 CFS（Complete Fair Scheduler 即完全公平调度器），直接看CPU Cgroup 和CFS相关的参数，一共有三个。

  • cpu.cfs_period_us【固定值】：它是CFS算法的一个调度周期，一般值是 100000十万，单位是微秒，就是 100ms

  • cpu.cfs_quota_us【实际值】：它表示CFS算法中，在一个调度周期里这个控制组被允许的运行时间，比如这个值为 50000时，就是 50ms。
    如果用这个值除以调度周期（cpu.cfs_period_us）50ms/100ms=0.5，表示这个控制组被允许使用的CPU最大配额就是0.5个CPU
    是一个绝对值，如果这个值是200000，也就是200ms，那么它除以 period，也就是 200ms/100ms=2，超过了1 ，表示这个控制组需要2个CPU的资源

  • cpu.shares【1024比例】：表示 CPU Cgroup 对于控制组之间的CPU 分配比例，缺省值是1024

    例如：
    group3 中的cpu.shares 是1024，group4 中的 cpu.shares 是 3072，那么 group3:group4 = 1:3

    比例说明什么呢：
    在一台4个CPU 的机器上，当 group3 和 group4 都需要4个CPU的时候，它们实际分配到的CPU 分别是，group3是1个，group4是3个。

实际操作举例如下：

在一台4个CPU的机器上，按照上面的cpu.shares 比例，实际分配的情况是 group3 是1个，group4是3个。

示例代码链接，下载到本地后操作：

    # 运行初始化的脚本：生成几个group文件夹，编译.c文件生成可执行文件
    $ bash training-main/cpu/cgroup_cpu/create_groups.sh

1.2.1 cpu.cfs_quota_us 示例

启动一个消耗2个CPU(200%) 的程序 threads-cpu，然后把这个pid加到group3的控制组里，命令如下：

$ ./training-main/cpu/cgroup_cpu/threads-cpu/threads-cpu 2 & echo $! > /sys/fs/cgroup/cpu/group2/group3/cgroup.procs

在没有修改 cpu.cfs_quota_us（实际值） 前，用top 命令可以查看到刚才启动的 threads-cpu 进程的cpu使用率如下图：
我的测试机器是8个CPU的
启动一个消耗2个CPU(200%) 的程序 threads-cpu
然后把这个控制组中的 cpu.cfs_quota_us 设置为 150000（150ms） ，这个值除以 cpu.cfs_period_us
即 150ms/100ms = 1.5 表示1.5个CPU ，同时把 cpu.shares 设置为 1024

    echo 150000 > /sys/fs/cgroup/cpu/group2/group3/cpu.cfs_quota_us
    echo 1024 > /sys/fs/cgroup/cpu/group2/group3/cpu.shares

这个时候再运行 top，会发现 threads-cpu 进程的CPU 使用减少到了 150%。
这个就是因为cpu.cfs_quota_us起了作用，限制了进程CPU的绝对值
在这里插入图片描述

但是 cpu.shares在这里插入代码片 的作用还没发挥出来，因为它是控制各个控制组之间的CPU的比例
而且一定要到整个节点中的CPU 都跑满的时候它才能发挥作用

1.2.2 cpu.shares 示例

下面理解下 cpu.shares
按照上面的设置好 group3 中的 cpu.cfs_quota_us 和 cpu.shares；
然后启动第二个程序，设置好 group4 里面的 cpu.cfs_quota_us 和 cpu.shares；

专栏中的测试机器是 4C 的，我这里使用的是 12C 的。

#group3中，启动一个占用4C的进程，并把 pid 写入到 group3 控制组里
$ ./threads-cpu/threads-cpu 6 &echo $! > /sys/fs/cgroup/cpu/group2/group3/cgroup.procs 

#group3 中设置好如下参数
$ cat /sys/fs/cgroup/cpu/group2/group3/cpu.cfs_quota_us 
    450000
$ cat /sys/fs/cgroup/cpu/group2/group3/cpu.shares       
    1024

#group4中，启动一个占用8C的进程，并把pid写入到group4控制组里
$ ./threads-cpu/threads-cpu 12 &echo $! > /sys/fs/cgroup/cpu/group2/group4/cgroup.procs   

#group4 中设置好如下参数
$ echo 1050000 > /sys/fs/cgroup/cpu/group2/group4/cpu.cfs_quota_us
$ echo 3072 > /sys/fs/cgroup/cpu/group2/group4/cpu.shares

说明：  
group3 启动6C，group4启动12C，把机器CPU跑满了；
group3 限制4.5C，group4限制10.5C；
group3:group4 的 shares值是 1:3

按理说top 显示CPU 实际使用率应该是 1:3的。  
我实际下来 和专栏里说的不一样。先放在这吧。

在这里插入图片描述

梳理：

  • cpu.cfs_quota_us 和 cpu.cfs_period_us 这两个值决定了每个控制组中所有进程的可使用CPU资源的最大值；
  • cpu.shares 决定了CPU Cgroup 子系统下控制组可用CPU的相对比例。只有当系统上CPU完全被占满的时候，这个比例才会在各个控制组间起作用；

1.3 现象解释

首先 kubernetes 为每个容器都在 CPU Cgroup 的子系统中建立一个控制组，然后把容器中进程写入到这个控制组中。

（1）Limit CPU 是容器可用的上限值：
容器CPU的上限值是由 cpu.cfs_quota_us 除以 cpu.cfs_period_us 得出的值决定的操作系统中 cpu.cfs_period_us 的值一般是个固定值，k8s不会去修改它，所以只修改 cpu.cfs_quota_us

（2）Request CPU ：
整个节点CPU都占满的情况，容器可以保证的需要的CPU数目。
是靠 cpu.shares 这个参数在CPU Cgroup中 cpu.shares == 1024 表示1个CPU的比例，那么request CPU的值就是n，给 cpu.shares 的赋值对应就是 n*1024

1.4 重点总结

每个进程的CPU Usage 只包含了用户态(us 或 ni) 和 内核态（sy）两部分，其他的系统CPU开销并不包含在进程的CPU使用中，而 CPU Cgroup 只是对进程的CPU 使用做了限制


CPU Cgroup中的三个参数：

  • cpu.cfs_quota_us：（一个调度周期里这个控制组被允许的运行时间） 除以 cpu.cfs_period_us
    （调度周期）得到的值决定了 CPU Cgroup 每个控制组中CPU 使用的上限值。
  • cpu.shares：决定了CPU Cgroup 子系统下控制组可用CPU的相对比例，当系统上CPU 完全被占满的时候，这个比例才会在各个控制组间起效。
  • Limit CPU 就是容器所在 Cgroup 控制组中的CPU 上限值（cpu.cfs_quota_us），Request CPU 的值就是控制组中的 cpu.shares 的值。

二、评论

问题1：
为什么说“云平台里呢，大部分程序都不是实时调度的进程，而是普通调度（SCHED_NORMAL）类型进程”？这块不是很明白
回答1：
进程如果设置为SCHED_FIFO 或者SCHED_RR实时调度类型，那么只要进程任务不结束，就不会把cpu资源让给SCHED_NORMAL进程。这种实时的进程，在实时性要比较高的嵌入式系统中会用到，但是云平台中提供互联网服务的应用中不太会去用实时调度。

回答2：
cpu.shares是个相对值，但是在Linux节点上一般的约定是以值1024为1个CPU的比例，当所有的配置都遵守这个约定的时候，那么给值N*1024, 就表示N个CPU的数量了。

回答3：
一般对于容器，是一个cgroup控制组里限制容器中的所有进程。

回答4：
网络I/O 没有wa状态部分。
hi/si 对于磁盘都是有的。

回答5：
cpu.cfs_quota_us 取值为 -1 表示不限制。

问题6：
有个疑问：假设给容器配置了 1.5 的 CPU，而宿主机上只有 1 个 CPU，其实现在来说配置多少个 CPU 应该指的使用多少的 CPU 的时间对吗？（ 而非简单地分配物理 CPU ）
回答6：
是的，这是一个调度时间的分配，而不是把物理cpu 分配给容器的进程。
对于你说的这种情况，就是不限制cpu的使用时间了。

三、课程疑问

makefile 定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作，因为 makefile就像一个Shell脚本一样，其中也可以执行操作系统的命令。

make是一个命令工具，是一个解释makefile中指令的命令工具

用gcc编译使用了POSIX thread的程序时通常需要加额外的选项，以链接到库。
此处直接加上-lpthread选项。
gcc xxx.c -o xxx -lpthread

ibmleeca
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
JSP内置对象:Request和Response的简单介绍及使用
10-27
JSP内置对象:Request和Response的简单介绍及使用，需要的朋友可以参考一下
request-limits:限制传入的 http 请求的大小
06-22
请求限制 限制传入的 http 请求的大小！ 如果你不想等待一个太大的请求，如果传入的 http 请求太大而你无法处理，这个模块将抛出一个错误事件 ＃用法： var opts = { uri : 'http://google.com' } , s = request ( opts , function ( e , r , b ) { //if the size is more than 255bytes an error event will happen } ) limit ( s , 255 ) ＃测试： npm t
Windows服务器上lsass.exe进程CPU使用率异常问题排查方法
01-10
近期有几台服务器相继出现 lsass.exe 占用CPU过高，也不算太高，而且过了一段时间又会恢复正常，CPU过高直接造成网站打开很慢，周而反复。 在CPU跑高的时候，伴随着一个现像就是网络的浮动，有时候上传居然达到了30M – 90M/s，对外攻击，第一时间就想到有可能是这个原因，那具体怎么查呢？ 常见的对外文件，这东西网上搜一下就能找到。 代码如下:<?php set_time_limit(86400); ignore_user_abort(True); $packets = 0; $http = $_REQUEST[‘http’]; $rand = $_REQUEST[‘exit’];
pod探针
qq_45873113的博客
08-20 400
目录一、资源限制1、Pod 和 容器 的资源请求和限制2、CPU 资源单位3、内存 资源单位二、重启策略三、健康检查：又称为探针（Probe） 一、资源限制 当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。 当为 Pod 中的容器指定了 request 资源时，调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。ku
request、limit资源配额
weixin_45226922的博客
12-12 159
即最低要求requests所指定的资源，最高以limits为上限。优先级较Best-Effort高一点： 节点资源不足时，如果没有Best-Effort类型的容器，会删除该类容器。但是这种容器优先级是最低的：节点CPU或MEM资源不够时，会优先把该类容器杀掉以回收资源。具有最高优先级，资源不足时会优先删除Best-Effort和Burstable类容器以确保其运行。根据这两个参数的配置，k8s在集群资源不足的时候有不同的处理策略 – Quality of Service (QoS)
Kubernetes中设置 CPU 的 requests 和 limits详解
力哥讲技术
04-17 3659
在 Kubernetes 中，您有两种方法来指定一个 pod 可以使用多少 CPU： Requests通常用于确定平均消耗。 Limits设置允许的最大资源数。 Kubernetes 调度器使用 requests 来确定 pod 应该分配到集群中的哪个节点。 由于调度器并不知道实际消耗（pod 尚未启动），它需要一个提示。
Kubernetes之request 和 limit详解
qq_34870707的博客
05-01 5189
Kubenertes资源分配之Request和Limit解析
两篇关于k8s 内存和CPU的 request 和 limit讲解很详尽的文章
xu282934741的博客
10-22 6099
https://www.cnblogs.com/CCE-SWR/p/10494025.html https://www.cnblogs.com/CCE-SWR/p/10530980.html
Linux性能监控（CPU监控）
热门推荐
白衣不染尘的博客
11-27 1万+
# Linux性能监控（CPU监控） 主要分为四类： cup监控 内存监控命令 IO性能 网络性能 cup监控 关于CPU，有3个重要的概念：上下文切换（context switchs），运行队列（Run queue）和使用率（utilization）。 上下文切换： 　　 目前流行的CPU在同一时间内只能运行一个线程，超线程的处理器可以在同一时间运行多个线程（包括多核CPU），Linux内核会...
关于Kubernetes中资源限制 requests和limits 的一些笔记整理
山河已无恙
08-11 1528
今天和小伙伴们分享K8s中pod资源限制的一些笔记博文内存涉及pod中通过request和limits实现资源的申请和限制理解不足小伙伴帮忙指正，生活加油_我们的痛苦来源于“夸父追日”一般的对“更好”的追求，也来自于自己的自卑与狂妄。学习之前，我们要准备下实验环境，新建一个新的命名空间，并且切换过去。.........
@RequestBody的使用详解
08-25
主要介绍了@RequestBody的使用详解，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
esp-request:该项目不再受支持，请使用
05-17
该项目不再受支持，请使用 int download_callback ( request_t *req, char *data, int len) { req_list_t *found = req-> response -> header ; while (found-> next != NULL ) { found = found-> next ; ESP_...
k8s容器资源limit和requests
beijihukk的博客
09-17 1834
Example 2-3. Resource limits apiVersion: v1 kind: Pod metadata: name: random-generator spec: containers: - image: k8spatterns/random-generator:1.0 name: random-generator resources: requests: cpu: 100m memory: 100Mi limits: cpu: 200m memory: 200M
K8s--容器资源限制
小螺号的博客
03-26 602
文章目录一、限制类型二、为Pod设置资源限制1.内存限制示例2.CPU限制示例三、为namespace设置资源限制1.创建LinitRange对象，并设置限制范围2.创建pod，测试上述限制是否成功四、为namespace设置资源配额1.创建ResourceQuota对象2.为 Namespace 配置Pod配额 一、限制类型 Kubernetets中对资源的限制类型主要有两类： request(资源需求)：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。 limit(资源限额)：即运行P
docker容器limit和inode问题
weiguang1017的专栏
08-28 3463
之前以为只是aufs或overlay才有这个问题。。。但今天发现devicemapper存储也存在该问题。 解决： 编辑docker配置文件 /etc/sysconfig/docker other_args="-g /home/q/docker --default-ulimit nofile=65535 --log-driver=none" 保存后，重启docker服务。
k8s --容器资源限制
ly660402的博客
03-07 3188
Kubernetes采用request和limit两种限制类型来对资源进行分配。 request(资源需求)：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。 limit(资源限额)：即运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。 资源类型: CPU 的单位是核心数，内存的单位是字节。 一个容器申请0.5个CPU，就相当于申请1个CPU的一半，你也可以加个后缀m 表示千分之一的概念。比如说100m的CPU，100豪的CPU和0.1个CPU都是一样
K8S CPU 请求和限制，是否有很好的选择？
关注微信公众号【开源Linux】，后台回复『10T』，领取10T学习资源大放送，涵盖Linux、虚拟化、容器、云计算、网络、Python、Go等书籍和视频
05-11 762
Limits 和 Requests 并不是 CPU 管理的灵丹妙药，在某些情况下，其他替代方案可能是更好的选择在这篇博文中，您将了解到：CPU requests 如何工作CPU limits 如何工作按编程语言分类的现状限制不是最佳选择的情况您可以使用哪些替代方法来限制Kubernetes CPU RequestsRequests 在 Kubernetes 中有两个目的：调度可用性首先，它们告诉 ...
K8s 服务质量等级
小胡子
03-15 424
K8s 服务质量等级
linux18：进程等待
最新发布
m0_73919066的博客
04-20 1068
1：子进程创建的目的是要完成父进程指派的某个任务，当子进程运行完毕退出时，父进程需要通过进程等待的方式，回收子进程资源，获取子进程退出信息（子进程有无异常？没有异常结果是否正确？检查退出码查看错误原因）2：父进程如果一直不回收，就可能造成子进程‘僵尸进程’的问题，子进程一直得不到父进程的回收，进而造成内存泄漏。3：子进程一旦变成僵尸状态，那就刀枪不入，“杀人不眨眼”的kill -9 也无能为力杀死一个已经死去的进程。只能通过进程等待将他进行回收。
Fatal error in launcher: Unable to create process using D:\python.exe D:\Scripts\pip.exe install jieba : ???????????
11-04
这个错误通常是由于环境变量配置不正确或者Python安装文件损坏导致的。您可以尝试以下几种方法来解决这个问题： 1. 检查环境变量配置是否正确，确保Python的安装路径已经添加到了系统的环境变量中。 2. 重新安装Python，并确保安装文件没有损坏。 3. 尝试使用Python的绝对路径来运行pip命令，例如：`"D:\worksoft\pyhon\python.exe" "D:\worksoft\python\Scripts\pip.exe" install request`。 4. 尝试使用管理员权限运行命令提示符或者PowerShell。 5. 尝试升级pip到最新版本，使用命令：`python -m pip install --upgrade pip`。 6. 如果您使用的是虚拟环境，请确保已经激活虚拟环境。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值