cpu时间

导语 总结有关服务器的各项性能指标，以及如何判断服务器的性能状况出现问题，性能指标代表的含义。同时也总结Linux服务器上有关工具的各项参数含义，以及日常需要注意的参数信息。 CPU使用率和负载 首先需要分清楚 CPU使用率和机器负载 不是相同的概念，如果 CPU使用率 ，但是不一定代表机器负载同样也高。所以关于 CPU使用率和负载 的区别： CPU使用率：显示的是程序在运行期间占用的CPU百分比； CPU负载：显示的是一段时间内正在使用和等待使用的CPU平均任务数； 查看CPU使用率和负载 对于查看负载可以使用uptime,w命令，同时top，vmstat工具也可以同时观察CPU使用率和负载情况。 查看CPU核数： grep "model name" /proc/cpuinfo | wc -l uptime命令： 命令返回信息中的load average就是关于系统的平均负载，里面的三个数字分别代表着1分钟、5分钟、15分钟内的系统平均负载。 top工具 （如果是多核CPU，1查看各个CPU详细信息） top工具的第一行后面的三个值，分别也是代表之前的 1、5、15 分钟内的平均负载； 第三行关于CPU使用率各项参数的含义： (us)user：CPU在低nice值（高优先级）用户态所占用的时间；（大部分CPU时间都在执行此类程序） (sy)sytem：CPU处于内核所占用的时间

Node隔离与恢复 cat unschedule_node.yaml apiVersion: kind: Node metadata: name: k8s-node-1 labels: kubernetes.io/hostname: k8s-node-1 sepc: unschedulable: true kubectl replace -f unschedule_node.yaml kubectl patch node k8s-node-a -p '{"spec":{"unschedulable":"true"}' kubectl cordon k8s-node-1（对节点进行隔离） kubectl uncordon k8s-node-1（对节点进行恢复） Node的扩容 在新节点上安装Docker、kubelet、kube-proxy服务，并修改kubelet和kube-proxy的启动参数将Master URL指定为当前集群的Master的地址，最后启动这些服务。 更新资源对象的Label kubectl lable pod redis-master-bobr role=backend kubectl get pods -Lrole kubectl label pod redis-master-bobr0 role- kubectl label pod redis

转自http://3961409.blog.51cto.com/3951409/759708 所有的并发处理都有排队等候，唤醒，执行至少三个这样的步骤.所以并发肯定是宏观概念，在微观上他们都是序列被处理的，只不过资源不会在某一个上被阻塞(一般是通过时间片轮转)，所以在宏观上看多个几乎同时到达的请求同时在被处理。如果是同一时刻到达的请求也会根据优先级的不同，而先后进入队列排队等候执行。 并发与并行是两个既相似而又不相同的概念：并发性，又称共行性，是指能处理多个同时性活动的能力；并行是指同时发生的两个并发事件，具有并发的含义，而并发则不一定并行，也亦是说并发事件之间不一定要同一时刻发生。 并发的实质是一个物理CPU(也可以多个物理CPU) 在若干道程序之间多路复用，并发性是对有限物理资源强制行使多用户共享以提高效率。 并行性指两个或两个以上事件或活动在同一时刻发生。在多道程序环境下，并行性使多个程序同一时刻可在不同CPU上同时执行。 并发，是在同一个cpu上同时（不是真正的同时，而是看来是同时，因为cpu要在多个程序间切换）运行多个程序。 并行，是每个cpu运行一个程序。 打个比方。并发，就像一个人（cpu）喂2个孩子（程序），轮换着每人喂一口，表面上两个孩子都在吃饭。并行，就是2个人喂2个孩子，两个孩子也同时在吃饭。 来源： https://www.cnblogs.com

在如今的多核处理器时代，多线程技术发挥着巨大的作用，尤其对于大批量处理同类型IO密集型的任务，例如全库全表查找数据时，多线程是提升速度和性能的利器。 近期发布的另一篇文章已经详细介绍了线程池的技术原理。但平时的开发工作中，我们可能更加关注的是线程池的使用，线程数设置多大啊？队列大小设置多大啊，等问题。 这篇文章主要是针对前段时间对线程池的使用过程中，总结了几点参数设置方面的建议，希望对大家有用。 使用多线程时，会面临 线程数，队列大小(corePoolSize maxPoolSize queueCapacity) 三个重要参数的大小设置问题。 我根据自己前期的工作总结发现参数设置主要考虑下面几个方面： 1. 线程池中执行的任务性质。 计算密集型的任务比较占cpu，所以一般线程数设置的大小 等于或者略微大于 cpu的核数；但IO型任务主要时间消耗在 IO等待上，cpu压力并不大，所以线程数一般设置较大，例如 多线程访问数据库，数据库有128个表，可能就直接考虑使用128个线程。 2. CPU使用率。 当线程数设置较大时，会有如下几个问题：第一，线程的初始化，切换，销毁等操作会消耗不小的cpu资源，使得cpu利用率一直维持在较高水平。第二，线程数较大时，任务会短时间迅速执行，任务的集中执行也会给cpu造成较大的压力。第三， 任务的集中支持，会让cpu的使用率呈现锯齿状

设置资源请求数量 创建Pod的时候，可以为每个容器指定资源消耗的限制。Pod的资源请求限制则是Pod中所有容器请求资源的总和。 apiVersion: v1 kind: Pod metadata: name: requests-pod spec: containers: - image: busybox command: ["dd", "if=/dev/zero", "of=/dev/null"] name: main resources: requests: cpu: 200m memory: 10Mi 如果不指定CPU请求资源，表示不关心容器会分到多少CPU资源，有可能会一直分不到而处于等待状态。指定资源请求表示Pod对资源的最小需求，因此在调度的时候会如果Node剩余的资源不能满足Pod的需求，则不会调度到对应的Node上。Scheduler调度的时候并不关注在调度时具体的资源使用情况，而是根据现存Pod的资源请求情况来进行调度。这就会有问题，特别是当允许Pod使用超过请求的资源时。下面的图一看就能理解。 调度判断首先将不符合请求的Node排除在外，然后将符合要求的Node进行排序。节点排序根据资源请求数量的不同分为两个策略， LeastRequestPolicy 和 MostRequestPolicy 。从字面上我们可以看到，一个是优先分派到资源请求少的节点

安装 yum install -y sysstat sar -d 1 1 rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s rsec/s: 每秒读扇区数。即 delta(rsect)/s wsec/s: 每秒写扇区数。即 delta(wsect)/s rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算) wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算) avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio) avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。 await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio) svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio) %util:

概述： 用 'top -i' 看看有多少进程处于 Running 状态，可能系统存在内存或 I/O 瓶颈，用 free 看看系统内存使用情况，swap 是否被占用很多，用 iostat 看看 I/O 负载情况... 还有一种办法是 ps -ef | sort -k7 ，将进程按运行时间排序，看哪个进程消耗的cpu时间最多。 top: 主要参数 d：指定更新的间隔，以秒计算。 q：没有任何延迟的更新。如果使用者有超级用户，则top命令将会以最高的优先序执行。 c：显示进程完整的路径与名称。 S：累积模式，会将己完成或消失的子行程的CPU时间累积起来。 s：安全模式。 i：不显示任何闲置(Idle)或无用(Zombie)的行程。 n：显示更新的次数，完成后将会退出to 显示参数: PID（Process ID）：进程标示号。 USER：进程所有者的用户名。 PR：进程的优先级别。 NI：进程的优先级别数值。 VIRT：进程占用的虚拟内存值。 RES：进程占用的物理内存值。 SHR：进程使用的共享内存值。 S：进程的状态，其中S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值是负数。 %CPU：该进程占用的CPU使用率。 %MEM：该进程占用的物理内存和总内存的百分比。 TIME＋：该进程启动后占用的总的CPU时间。 Command：进程启动的启动命令名称，如果这一行显示不下

0x00 异步编程模式的历史 .NET Framework 提供了执行异步操作的三种模式： 异步编程模型 (APM) 模式（即 IAsyncResult 模式），在该模式下，异步操作需要使用 Begin 和 End 方法（例如，异步写入操作需要使用 BeginWrite 和 EndWrite 方法） 不建议新的开发使用此模式。 有关详细信息，请参阅 异步编程模型 (APM) 。 基于事件的异步模式 (EAP)，这种模式需要 Async 后缀，也需要一个或多个事件、事件处理程序委托类型和 EventArg 派生类型。 EAP 是在 .NET Framework 2.0 中引入的。 不建议新的开发使用这种模式。 有关详细信息，请参阅 基于事件的异步模式 (EAP) 。 基于任务的异步模式 (TAP)，该模式使用单一方法表示异步操作的开始和完成。 TAP 是在 .NET Framework 4 中引入的，并且它是在 .NET Framework 中进行异步编程的推荐使用方法。 C# 中的 async 和 await 关键词以及 Visual Basic 语言中的 Async 和 Await 运算符为 TAP 添加了语言支持。 有关详细信息，请参阅 基于任务的异步模式 (TAP) 。 现在主要使用TAP来编程。 0x01 Task和 Task<T> 任务是用于实现称之为 并发

在上一篇文章 Linux内核进程相关知识点总结 中介绍了进程相关的一些基础知识，包括进程的创建、运行以及终止等。这篇文章中主要介绍进程的调度。 进程调度 ：举个栗子，在一个单核处理器中，同一时刻只能有一个进程拥有处理器资源，其他的进程只能在就绪队列中排序，等待处理器空闲之后才有机会获取处理器资源并开始运行。在这种情况下，操作系统就需要从众多的就绪进程中选择一个最为合适的进程来运行，这就是进程调度器，其出现的目的就是提高处理器的利用率。 进程的优先级 ：Linux操作系统最早采用nice值来调整进程的优先级，取值范围是-20-19，默认值为0。Nice值越大，优先级越低。目前，Linux内核使用0-139的数值表示进程的优先级，数值越低，优先级越高。其中，0-99给实时进程用，100-139给普通进程用。另外，在用户空间有一个传统的变量nice值映射到普通进程的优先级，即100-139。 其中，static_prio指的是静态优先级，在进程启动时分配。内核不存储nice值，取而代之的是static_prio。内核中的宏NICE_TO_PRIO（）实现将nice值转换为static_prio。他之所以被称为静态优先级，是因为他不会随着时间而改变，用户可以通过系统调用来改变该值。 normal_prio是基于static_prio和调度策略计算出来的

阅读目录 　　手工操作 —— 穿孔卡片 　　批处理 —— 磁带存储和批处理系统 　　多道程序系统 　　分时系统 　　实时系统 　　通用操作系统 　　操作系统的进一步发展 　　操作系统的作用 手工操作 —— 穿孔卡片 1946年第一台计算机诞生--20世纪50年代中期，计算机工作还在采用手工操作方式。此时还没有操作系统的概念。 　　程序员将对应于程序和数据的已穿孔的纸带（或卡片）装入输入机，然后启动输入机把程序和数据输入计算机内存，接着通过控制台开关启动程序针对数据运行；计算完毕，打印机输出计算结果；用户取走结果并卸下纸带（或卡片）后，才让下一个用户上机。 手工操作方式两个特点： 　　（1）用户独占全机。不会出现因资源已被其他用户占用而等待的现象，但资源的利用率低。 　　（2）CPU 等待手工操作。CPU的利用不充分。 20世纪50年代后期，出现 人机矛盾 ：手工操作的慢速度和计算机的高速度之间形成了尖锐矛盾，手工操作方式已严重损害了系统资源的利用率（使资源利用率降为百分之几，甚至更低），不能容忍。唯一的解决办法：只有摆脱人的手工操作，实现作业的自动过渡。这样就出现了成 批处理 。 批处理 —— 磁带存储 　　批处理系统：加载在计算机上的一个 系统软件 ，在它的控制下，计算机能够自动地、成批地处理一个或多个用户的作业（这作业包括程序、数据和命令）。 联机批处理系统