漳州专业网站建设公司,太仓网站建设,做个app需要多少费用,怎么添加字体到电脑wordpress写在前面 博文内容为 Linux 性能指标 CPU 上下文切换认知内容涉及#xff1a; 上下文认知#xff0c;发生上下文切换的场景有哪些上下文指标信息查看#xff0c;内核上下文切换事件跟踪#xff0c;系统上下文切换统计上下文异常场景分析#xff0c;CPU亲和性配置优化上下文…写在前面 博文内容为 Linux 性能指标 CPU 上下文切换认知内容涉及 上下文认知发生上下文切换的场景有哪些上下文指标信息查看内核上下文切换事件跟踪系统上下文切换统计上下文异常场景分析CPU亲和性配置优化上下文 理解不足小伙伴帮忙指正 ,生活加油 99%的焦虑都来自于虚度时间和没有好好做事所以唯一的解决办法就是行动起来认真做完事情战胜焦虑战胜那些心里空荡荡的时刻而不是选择逃避。不要站在原地想象困难行动永远是改变现状的最佳方式 上下文认知
什么是CPU上下文切换
通俗的话讲,给定的CPU在某个时间点仅可以运行一个进程,为了制造出单处理器同时运行多个任务的假象(实际受限系统调度器调度策略 调度优先级), 每个进程完成他们的任务一般都需要停止和启动很多次。 Linux内核就要不断地在不同的进程间切换。这种不同进程间的切换称为上下文切换
上下文切换时, CPU要保存旧进程的所有上下文信息,并取出新进程的所有上下文信息。上下文中包含了 Linux 跟踪新进程的大量信息,其中包括: 进程正在执行的指令,分配给进程的内存,进程打开的文件等
所以实际上上下文切换涉及大量信息的移动,上下文切换的开销可以是相当大的
上下文切换可以是内核调度的结果。简单来讲为了保证公平地给每个进程分配处理器时间,内核会周期性地中断正在运行的进程,在适当的情况下,内核调度器会决定开始另一个进程,而不是让当前进程继续执行。
每次这种周期性中断或定时发生时,系统都可能进行上下文切换。每秒定时中断的次数与架构和内核版本有关。
一个检查中断频率的简单方法是用 /proc/interrupts 文件,它可以确定已知时长内发生的中断次数。
通过这个命令可以观察到5秒钟内定时器中断次数的变化
┌──[rootvms81.liruilongs.github.io]-[~]
└─$cat /proc/interrupts | grep time; sleep 5 ;cat /proc/interrupts | grep time0: 337 0 IO-APIC-edge timerLOC: 9896498 9871317 Local timer interrupts0: 337 0 IO-APIC-edge timerLOC: 9901529 9876213 Local timer interrupts
┌──[rootvms81.liruilongs.github.io]-[~]
└─$LOC 即为本地定时器中断
上面定时器的启动频率为 (9896498-9901529)/5 1000,即每秒要中断 1000次同时也可以理解为内核在 sleep 进程执行中每秒发生 1000 次 CPU 定时中断 如果上下文切换明显多于定时器中断,那么这些切换极有可能是由I/O请求或其他长时间运行的系统调用(如休眠)造成的。当应用请求的操作不能立即完成时,内核启动该操作,保存请求进程,并尝试切换到另一个已就绪进程。这能让处理器尽量保持忙状态。 #上下文切换数量
cs$(vmstat 1 1 | awk NR3{print $12})实际中调度策略不同定时器中断的意义也不一样
实时调度策略 如FIFO先进先出和时间片轮转RR这些策略依赖于定时中断来确保实时进程的及时执行但同时也需要考虑非实时进程的调度以避免饥饿
普通调度策略 如CFS定时中断用于动态调整时间片以实现公平性和效率的平衡
什么是上下文
当多个进程进行切换时内核会包含前一个和后一个进程的相关信息。每次一个进程让出CPU时内核都会存储进程当前的操作状态当以后该进程再次被调度回CPU时可以从相同的位置恢复操作。
这些操作状态数据又被称为上下文包含CPU的寄存器数据以及程序的计数器数据。
CPU 寄存器是 CPU 内置的容量小、但速度极快的内存。程序计数器则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。
给进程切换CPU时间片就是所谓的上下文切换。CPU 上下文切换就是先把前一个任务的 CPU 上下文也就是 CPU 寄存器和程序计数器保存起来然后加载新任务的上下文到这些寄存器和程序计数器最后再跳转到程序计数器所指的新位置运行新任务
保存下来的上下文会存储在系统内核中并在任务重新被分配到时间片时再次被加载这样看起来系统实际中同时运行多个任务具体和对应的CPU 调度策略有关系不同调度策略分配时间片策略不同。
只有进程会发生上下文切换么
实际上不仅进程会发生CPU上下文切换线程,协程和中断也会发生CPU上下文切换。CPU上下文切换包括:
进程上下文切换线程上下文切换协程上下文切换中断上下文切换
进程上下文切换涉及到虚拟内存、栈、全局变量等用户空间资源以及内核堆栈、寄存器等内核空间的状态。这种切换发生在进程调度时例如
CPU时间片用完、系统资源不足、进程通过 sleep 函数主动挂起、高优先级进程抢占时间片、硬件中断时CPU上的进程被挂起转而执行内核中的中断服务
进程上下文切换
Linux 按照特权等级把进程的运行空间分为内核空间和用户空间分别对应着下图中 CPU 特权等级的 Ring 0 和 Ring 3。 内核空间Ring 0具有最高权限可以直接访问所有资源用户空间Ring 3只能访问受限资源不能直接访问内存等硬件设备必须通过系统调用陷入到内核中才能访问这些特权资源。
进程既可以在用户空间运行又可以在内核空间中运行。
进程在用户空间运行时被称为进程的用户态而陷入内核空间的时候被称为进程的内核态。
从用户态到内核态的转变需要通过系统调用来完成。比如当我们查看文件内容时就需要多次系统调用来完成首先调用 open() 打开文件然后调用 read() 读取文件内容.
这里可以通过 bcc 或者 perf 工具来跟踪系统调用
采集数据
┌──[rootliruilongs.github.io]-[~]
└─$perf record -g $(which cat) test.log
Holler
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.012 MB perf.data (2 samples) ]
┌──[rootliruilongs.github.io]-[~]
└─$输出数据
┌──[rootliruilongs.github.io]-[~]
└─$perf script perf_script.txt
┌──[rootliruilongs.github.io]-[~]
└─$cat perf_script.txt
cat 3070 403.637613: 250000 cpu-clock:pppH: ffffffffa2afb616 vma_interval_tree_remove0x156 ([kernel.kallsyms])ffffffffa2b12068 unlink_file_vma0x48 ([kernel.kallsyms])ffffffffa2b05da1 free_pgtables0x71 ([kernel.kallsyms])ffffffffa2b1176a unmap_region0x10a ([kernel.kallsyms])ffffffffa2b13bcd __do_munmap0x20d ([kernel.kallsyms])ffffffffa2b156f6 mmap_region0x2f6 ([kernel.kallsyms])ffffffffa2b15de0 do_mmap0x380 ([kernel.kallsyms])ffffffffa2ae69b8 vm_mmap_pgoff0xd8 ([kernel.kallsyms])ffffffffa2b131b8 ksys_mmap_pgoff0x58 ([kernel.kallsyms])ffffffffa284b2a3 __x64_sys_mmap0x33 ([kernel.kallsyms])ffffffffa2805089 x64_sys_call0x3b9 ([kernel.kallsyms])ffffffffa35c2f36 do_syscall_640x56 ([kernel.kallsyms])ffffffffa36000df entry_SYSCALL_64_after_hwframe0x67 ([kernel.kallsyms])7ff93a740cb7 mmap640x17 (/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)7ff93a724601 _dl_map_object0x1f1 (/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)cat 3070 403.637863: 250000 cpu-clock:pppH: ffffffffa28a5a6f do_user_addr_fault0x2ff ([kernel.kallsyms])ffffffffa35c6ed7 exc_page_fault0x77 ([kernel.kallsyms])ffffffffa3600bb7 asm_exc_page_fault0x27 ([kernel.kallsyms])ffffffffa2eb6130 copy_user_generic_unrolled0xa0 ([kernel.kallsyms])ffffffffa2ac3705 filemap_read0x165 ([kernel.kallsyms])ffffffffa2ac3a62 generic_file_read_iter0xe2 ([kernel.kallsyms])ffffffffa2c6ecfb ext4_file_read_iter0x5b ([kernel.kallsyms])ffffffffa2b9b65a new_sync_read0x10a ([kernel.kallsyms])ffffffffa2b9bff3 vfs_read0x103 ([kernel.kallsyms])ffffffffa2b9eac7 ksys_read0x67 ([kernel.kallsyms])ffffffffa2b9eb69 __x64_sys_read0x19 ([kernel.kallsyms])ffffffffa2806a8a x64_sys_call0x1dba ([kernel.kallsyms])ffffffffa35c2f36 do_syscall_640x56 ([kernel.kallsyms])ffffffffa36000df entry_SYSCALL_64_after_hwframe0x67 ([kernel.kallsyms])7ff93a5f37e2 read0x12 (/usr/lib/x86_64-linux-gnu/libc.so.6)┌──[rootliruilongs.github.io]-[~]
└─$
也可以使用 strace 命令
┌──[rootliruilongs.github.io]-[~]
└─$strace cat test.log
execve(/usr/bin/cat, [cat, test.log], 0x7ffcc8683ce8 /* 35 vars */) 0
brk(NULL) 0x55f45d320000
arch_prctl(0x3001 /* ARCH_??? */, 0x7fffbabbec00) -1 EINVAL (无效的参数)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 0x7f05f1400000
access(/etc/ld.so.preload, R_OK) -1 ENOENT (没有那个文件或目录)
openat(AT_FDCWD, /etc/ld.so.cache, O_RDONLY|O_CLOEXEC) 3
newfstatat(3, , {st_modeS_IFREG|0644, st_size62779, ...}, AT_EMPTY_PATH) 0
mmap(NULL, 62779, PROT_READ, MAP_PRIVATE, 3, 0) 0x7f05f13f0000
close(3) 0
openat(AT_FDCWD, /lib/x86_64-linux-gnu/libc.so.6, O_RDONLY|O_CLOEXEC) 3
read(3, \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0P\237\2\0\0\0\0\0..., 832) 832
pread64(3, \6\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 784, 64) 784
pread64(3, \4\0\0\0 \0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0..., 48, 848) 48
pread64(3, \4\0\0\0\24\0\0\0\3\0\0\0GNU\0I\17\357\204\3$\f\221\2039x\324\224\323\236S..., 68, 896) 68
newfstatat(3, , {st_modeS_IFREG|0755, st_size2220400, ...}, AT_EMPTY_PATH) 0
pread64(3, \6\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 784, 64) 784
mmap(NULL, 2264656, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 0x7f05f11c7000
mprotect(0x7f05f11ef000, 2023424, PROT_NONE) 0
mmap(0x7f05f11ef000, 1658880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) 0x7f05f11ef000
mmap(0x7f05f1384000, 360448, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bd000) 0x7f05f1384000
mmap(0x7f05f13dd000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x215000) 0x7f05f13dd000
mmap(0x7f05f13e3000, 52816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) 0x7f05f13e3000
close(3) 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 0x7f05f11c4000
arch_prctl(ARCH_SET_FS, 0x7f05f11c4740) 0
set_tid_address(0x7f05f11c4a10) 3659
set_robust_list(0x7f05f11c4a20, 24) 0
rseq(0x7f05f11c50e0, 0x20, 0, 0x53053053) 0
mprotect(0x7f05f13dd000, 16384, PROT_READ) 0
mprotect(0x55f45d2aa000, 4096, PROT_READ) 0
mprotect(0x7f05f143a000, 8192, PROT_READ) 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur8192*1024, rlim_maxRLIM64_INFINITY}) 0
munmap(0x7f05f13f0000, 62779) 0
getrandom(\xc0\x67\xb1\x59\x59\xe4\xa9\xdc, 8, GRND_NONBLOCK) 8
brk(NULL) 0x55f45d320000
brk(0x55f45d341000) 0x55f45d341000
openat(AT_FDCWD, /usr/lib/locale/locale-archive, O_RDONLY|O_CLOEXEC) 3
newfstatat(3, , {st_modeS_IFREG|0644, st_size6213280, ...}, AT_EMPTY_PATH) 0
mmap(NULL, 6213280, PROT_READ, MAP_PRIVATE, 3, 0) 0x7f05f0bd7000
close(3) 0
newfstatat(1, , {st_modeS_IFCHR|0600, st_rdevmakedev(0x88, 0), ...}, AT_EMPTY_PATH) 0
openat(AT_FDCWD, test.log, O_RDONLY) 3
newfstatat(3, , {st_modeS_IFREG|0644, st_size7, ...}, AT_EMPTY_PATH) 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 0x7f05f0bb5000
read(3, Holler\n, 131072) 7
write(1, Holler\n, 7Holler
) 7
read(3, , 131072) 0
munmap(0x7f05f0bb5000, 139264) 0
close(3) 0
close(1) 0
close(2) 0
exit_group(0) ?exited with 0
┌──[rootliruilongs.github.io]-[~]
└─$
在内核函数调用的过程有没有发生 CPU 上下文的切换呢
CPU 寄存器里原来用户态的指令位置需要先保存起来。接着为了执行内核态代码CPU 寄存器需要更新为内核态指令的新位置。最后才是跳转到内核态运行内核任务。
系统调用结束后CPU 寄存器需要恢复原来保存的用户态然后再切换到用户空间继续运行进程。所以一次系统调用的过程其实是发生了两次 CPU 上下文切换。
系统调用过程中并不会涉及到虚拟内存等进程用户态的资源也不会切换进程。这跟我们通常所说的进程上下文切换是不一样的
进程上下文切换是指从一个进程切换到另一个进程运行。而系统调用过程中一直是同一个进程在运行。
系统调用过程通常称为特权模式切换而不是上下文切换。但实际上系统调用过程中CPU 的上下文切换还是无法避免的。
进程上下文切换跟系统调用又有什么区别呢
进程是由内核来管理调度的进程的切换只能发生的内核态进程的上下文不仅包括了虚拟内存、栈、全局变量等用户空间的资源还包括了内核堆栈、寄存器等内核空间的状态。
进程的上下文切换就比系统调用时多了一步
在保存当前进程的内核状态和 CPU 寄存器之前需要先把该进程的虚拟内存、栈等保存下来而加载了下一进程的内核态后还需要刷新进程的虚拟内存和用户栈。
每次上下文切换都需要几十纳秒到数微秒的 CPU 时间。这个时间还是相当可观的特别是在进程上下文切换次数较多的情况下很容易导致 CPU 将大量时间耗费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上进而大大缩短了真正运行进程的时间。这也是导致平均负载升高的一个重要因素尤其是这 CPU 处于饱和状态的时候。
Linux 通过 TLBTranslation Lookaside Buffer来管理虚拟内存到物理内存的映射关系。
当虚拟内存更新后TLB 也需要刷新内存的访问也会随之变慢。特别是在多处理器系统上缓存是被多个处理器共享的刷新缓存不仅会影响当前处理器的进程还会影响共享缓存的其他处理器的进程。
什么时候会切换进程上下文?
进程切换时需要切换上下文默认调度策略情况下Linux 为每个 CPU 维护了一个就绪队列将活跃进程即正在运行和正在等待 CPU 的进程按照优先级和等待 CPU 的时间排序然后选择最需要 CPU 的进程也就是优先级最高和等待 CPU 时间最长的进程来运行。
进程在什么时候才会被调度到 CPU 上运行呢
实际上调度策略不同优先级不同调度结果也不同大多数情况下 当某个进程的分配的时间片耗尽了就会被系统挂起切换到其它正在等待 CPU 的进程运行。 进程在系统资源不足比如内存不足时要等到资源满足后才可以运行这个时候进程也会被挂起并由系统调度其他进程运行。 当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时自然也会重新调度。 当有优先级更高的进程运行时为了保证高优先级进程的运行当前进程会被挂起由高优先级进程来运行。 发生硬件中断时CPU 上的进程会被中断挂起转而执行内核中的中断服务程序。
进程本质上是由线程构成当一个进程为单线程时可以理解线程就是进程。
线程上下文切换
线程与进程最大的区别在于
线程是调度的基本单位所谓内核中的任务调度实际上的调度对象是线程进程则是资源拥有的基本单位即系统资源的申请给线程提供了虚拟内存、全局变量等资源
对于线程和进程我们可以这么理解
当进程只有一个线程时可以认为进程就等于线程。当进程拥有多个线程时这些线程会共享相同的虚拟内存和全局变量等资源。这些资源在上下文切换时是不涉及的。线程也有自己的私有数据比如栈和寄存器等这些在上下文切换时也是需要保存的。
线程的上下文切换实际上就可以分为两种情况
前后两个线程属于不同的进程切换过程和进程切换时一样的前后两个线程属于同一个进程虚拟内存和全局变量共享只需要切换线程的私有数据。
所以理论上从上下文切换的角度考虑多线程的资源消耗小与多进程。
既然线程可以共享进程的数据重而在上下文切换节省切换时数据的保存和刷新那么是否存在可以共享线程的数据重而节省更多的时间这就是协程。
协程的上下文切换
协程是一种用户态的轻量级线程完全由用户程序控制协程创建和销毁的开销非常小共享进程的内存空间和资源不需要操作系统分配独立的栈空间和寄存器状态因为它们不需要内核介入。
协程间的上下文切换完全在用户态进行开销非常小。实际上如果为单线程的协程上下文切换如果协程不执行系统调用是不会涉及到CPU上下文切换的。当协程执行系统调用时会涉及到从用户态切换到内核态
实际的协程上下文切换分为:
多个线程的不同协程上下文切换多个进程的不同协程上下文切换
协程的上下文切换开销远小于线程因为:
线程切换涉及到更多的状态信息如所有寄存器、线程堆栈等,协程切换主要是保存和恢复少量的状态信息如程序计数器和少量寄存器。
中断上下文切换
处理器还周期性地从硬件设备接收中断。当设备有事件需要内核处理时,它通常就会触发这些中断。
比如,如果磁盘控制器刚刚完成从驱动器取数据块的操作,并准备好提供给内核,那么磁盘控制器就会触发一个中断。对内核收到的每个中断,如果已经有相应的已注册的中断处理程序,就运行该程序,否则将忽略这个中断。
中断处理程序在系统中具有很高的运行优先级,并且通常执行速度也很快,查看/proc/interrupts文件可以显示出哪些CPU上触发了哪些中断。
┌──[rootvms81.liruilongs.github.io]-[~]
└─$cat /proc/interruptsCPU0 CPU10: 337 0 IO-APIC-edge timer1: 10 0 IO-APIC-edge i80428: 1 0 IO-APIC-edge rtc09: 0 0 IO-APIC-fasteoi acpi12: 16 0 IO-APIC-edge i804214: 0 0 IO-APIC-edge ata_piix15: 0 0 IO-APIC-edge ata_piix17: 57939 0 IO-APIC-fasteoi ioc018: 14 9800 IO-APIC-fasteoi ens3224: 0 0 PCI-MSI-edge PCIe PME, pciehp25: 0 0 PCI-MSI-edge PCIe PME, pciehp26: 0 0 PCI-MSI-edge PCIe PME, pciehp27: 0 0 PCI-MSI-edge PCIe PME, pciehp
.......................THR: 0 0 Threshold APIC interruptsDFR: 0 0 Deferred Error APIC interruptsMCE: 0 0 Machine check exceptionsMCP: 37 37 Machine check pollsERR: 0MIS: 0PIN: 0 0 Posted-interrupt notification eventPIW: 0 0 Posted-interrupt wakeup event
┌──[rootvms81.liruilongs.github.io]-[~]
└─$快速查看中断的次数
#发生中断数量irq$(vmstat 1 1 | awk NR3{print $11})中断处理会打断进程的正常调度和执行转而调用中断处理程序响应设备事件。而在打断其他进程时就需要将进程当前的状态保存下来这样在中断结束后进程仍然可以从原来的状态恢复运行。
跟进程上下文不同中断上下文切换并不涉及到进程的用户态。所以即便中断过程打断了一个正处在用户态的进程也不需要保存和恢复这个进程的虚拟内存、全局变量等用户态资源。
中断上下文切换其实只包括内核态中断服务程序执行所必需的状态包括 CPU 寄存器、内核堆栈、硬件中断参数等。
可以这么理解中断上下文切换发生的时候CPU并没有离开内核态所以不需要用户态的东西只是需要部分内核态数据。所以中断上下文切换相比进程上下文切换消耗更少的资源
对同一个 CPU 来说中断处理比进程拥有更高的优先级所以中断上下文切换并不会与进程上下文切换同时发生。同样道理由于中断会打断正常进程的调度和执行所以大部分中断处理程序都短小精悍以便尽可能快的执行结束。
即便是保存少量的内核态数据中断上下文切换也需要消耗 CPU切换次数过多也会耗费大量的 CPU甚至严重降低系统的整体性能。
上下文指标信息查看
内核上下文切换事件跟踪
通过确定上下文切换的位置可以分析哪些进程或线程导致了频繁的上下文切换从而优化系统性能。
确定内核中发生上下文切换的位置可以使用 sched:sched_switch 内核跟踪点
sched:sched_switch 是 BPFBerkeley Packet Filter工具集中用于跟踪内核上下文切换事件的跟踪点
# ./stackcount -P t:sched:sched_switch__schedulescheduleworker_threadkthreadret_from_forkkworker/0:2 [25482]1__schedulescheduleschedule_hrtimeout_range_clockschedule_hrtimeout_rangeep_pollSyS_epoll_waitentry_SYSCALL_64_fastpathepoll_waitLsun/nio/ch/SelectorImpl;::lockAndDoSelectLsun/nio/ch/SelectorImpl;::selectLio/netty/channel/nio/NioEventLoop;::selectLio/netty/channel/nio/NioEventLoop;::runInterpreterInterpretercall_stubJavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)thread_entry(JavaThread*, Thread*)JavaThread::thread_main_inner()JavaThread::run()java_start(Thread*)start_threadjava [4996]1... (omitted for brevity)__schedulescheduleschedule_preempt_disabledcpu_startup_entryxen_play_deadarch_cpu_idle_deadcpu_startup_entrycpu_bringup_and_idleswapper/1 [0]289从这些栈跟踪中我们可以得出以下结论
有一个工作线程kworker和一个Java进程导致了上下文切换。有一个CPU大部分时间都是空闲的swapper/1 [0]。
运行命令(进程)的上下文切换次数统计
┌──[rootliruilongs.github.io]-[~]
└─$yum -y install perf
........使用了 Linux 的 perf stat命令来收集关于 sleep 2 命令执行期间的性能计数器统计信息
┌──[rootliruilongs.github.io]-[~]
└─$perf stat sleep 2Performance counter stats for sleep 2:12.04 msec task-clock # 0.006 CPUs utilized1 context-switches # 0.083 K/sec1 cpu-migrations # 0.083 K/sec74 page-faults # 0.006 M/sec3,328,860 cycles # 0.276 GHz0 instructions # 0.00 insn per cycle289,196 branches # 24.020 M/sec12,686 branch-misses # 4.39% of all branches2.034208658 seconds time elapsed0.000000000 seconds user0.032226000 seconds sys┌──[rootliruilongs.github.io]-[~]
└─$
统计信息的解释
task-clock任务时钟表示命令执行的总时间(以毫秒为单位)。context-switches上下文切换次数表示在命令执行期间发生的进程上下文切换次数。cpu-migrationsCPU 迁移次数表示在命令执行期间发生的进程在不同 CPU 之间的迁移次数。page-faults缺页错误次数表示在命令执行期间发生的内存页面错误次数可以简单理解为类似缓存穿透。cyclesCPU 周期数表示命令执行期间的 CPU 周期数。instructions指令数表示命令执行期间执行的指令数。branches分支数(分支预测的次数)表示命令执行期间执行的分支指令数。branch-misses分支未命中数表示命令执行期间发生的分支预测错误次数。
汇总数据
seconds time elapsed 命令的总执行时间seconds user用户空间时间seconds user系统空间时间
sleep 2 命令主要在内核态执行用户态执行时间几乎为 0。任务执行期间发生了 1 次上下文切换和 1 次 CPU 迁移。任务执行期间发生了 74 次页面错误。 由于 sleep 命令本身不执行很多指令因此指令数为 0,分支缺失率为 4.39%。
使用了 Linux 的 perf 命令来收集关于 dd if/dev/zero of/dev/null bs2048 count100000 命令执行期间的性能计数器统计信息。 ┌──[rootliruilongs.github.io]-[~]
└─$dd if/dev/zero of/dev/null bs2048 count100000
记录了1000000 的读入
记录了1000000 的写出
204800000字节205 MB195 MiB已复制0.0863494 s2.4 GB/s
┌──[rootliruilongs.github.io]-[~]
└─$perf stat !!
perf stat dd if/dev/zero of/dev/null bs2048 count100000
记录了1000000 的读入
记录了1000000 的写出
204800000字节205 MB195 MiB已复制0.0960513 s2.1 GB/sPerformance counter stats for dd if/dev/zero of/dev/null bs2048 count100000:96.63 msec task-clock # 0.993 CPUs utilized 3 context-switches # 31.046 /sec 1 cpu-migrations # 10.349 /sec 86 page-faults # 889.991 /sec not supported cycles not supported instructions not supported branches not supported branch-misses 0.097339885 seconds time elapsed0.052670000 seconds user0.044566000 seconds sys┌──[rootliruilongs.github.io]-[~]
└─$系统级上下文切换统计
vmstat 是一个用于报告虚拟内存统计信息的工具也可以用来监控系统的整体性能和健康状况
┌──[rootliruilongs.github.io]-[~]
└─$vmstat -S m 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st1 0 0 32658 9 3600 0 0 7 1 31 53 0 0 100 0 00 0 0 32658 9 3600 0 0 0 0 440 794 0 0 100 0 00 0 0 32658 9 3600 0 0 0 0 425 774 0 0 100 0 0
┌──[rootliruilongs.github.io]-[~]
└─$procs 列显示了进程和线程的相关统计信息。
r 表示正在运行的进程或线程数。b 表示处于阻塞状态的进程或线程数。
system 列显示了系统调用和上下文切换的相关统计信息。
in 表示每秒的中断数。cs 表示每秒的上下文切换数。
cpu 列显示了 CPU 的使用情况统计信息。
us 表示用户空间进程的 CPU 使用率。sy 表示系统空间进程的 CPU 使用率。id 表示 CPU 空闲时间的百分比。wa 表示等待 I/O 操作的 CPU 时间的百分比。st 表示被虚拟化软件如果有偷取的 CPU 时间的百分比。
pcp dstat 是 Performance Co-Pilot 的一个工具它结合了dstat和pmval命令的功能提供了实时系统性能监控的功能。
┌──[rootliruilongs.github.io]-[~]
└─$ pcp dstat
You did not select any stats, using -cdngy by default.
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read writ| recv send| in out | int csw0 0 97 0 0| 0 0 | 126 637 | 0 0 |1036 11110 0 95 2 0| 0 0 | 66 302 | 0 0 |1135 12560 0 96 0 0|4094B 0 | 66 318 | 0 0 |1368 15540 0 98 0 0| 0 0 | 186 318 | 0 0 | 940 10130 0 96 0 0| 0 0 | 126 310 | 0 0 |1180 13021 0 96 1 0|4098B 0 | 66 310 | 0 0 |1114 11861 0 97 0 0| 0 0 | 186 326 | 0 0 |1225 13460 0 98 0 0| 0 0 | 126 318 | 0 0 |1070 11500 0 97 0 0| 0 0 | 66 310 | 0 0 |1005 10931 0 91 1 0|4099B 0 | 186 310 | 0 0 |2564 32551 0 93 0 0| 92k 56k| 126 326 | 0 0 |1807 2085
.......
┌──[rootliruilongs.github.io]-[~]
└─$CPU 使用情况usr用户态 CPU 使用率sys内核态 CPU 使用率idl空闲 CPU 使用率wai等待 I/O 的 CPU 使用率stl偷取的 CPU 使用率磁盘读写统计read读取的字节数writ写入的字节数网络接收和发送统计recv接收的字节数send发送的字节数分页统计in页面读取数out页面写入数系统调用和上下文切换统计int系统调用次数csw上下文切换次数
pcp dstat 命令默认选项是 -cdngy 等同于 --cpu-disk--net--page--sys,可以同时查看多组数据
也可以查看指定的指标信息查看 CPU 和进程信息每个 2 秒获取一次数据获取 8 组数据
[rootworkstation ~]# pkill sha1sum
[1] Terminated sha1sum /dev/zero
[rootworkstation ~]# pcp dstat --time --cpu --proc 2 8
----system---- ----total-usage---- ---procs---time |usr sys idl wai stl|run blk new
17-09 05:03:50| | 0 0
17-09 05:03:52| 0 0 100 0 0| 0 0 0
17-09 05:03:54| 1 0 100 0 0| 0 0 0
17-09 05:03:56| 0 0 100 0 0| 0 0 0
17-09 05:03:58| 0 0 100 0 0| 0 0 0
17-09 05:04:00| 0 0 100 0 0| 0 0 0
17-09 05:04:02| 0 0 100 0 0| 0 0 0
17-09 05:04:04| 0 0 100 0 0| 0 0 0指标说明
时间戳time显示采样时的日期和时间。CPU 使用情况usr用户态 CPU 使用率sys内核态 CPU 使用率idl空闲 CPU 使用率wai等待 I/O 的 CPU 使用率stl偷取的 CPU 使用率。进程统计信息run运行中的进程数blk被阻塞的进程数new新进程数。
也可以使用短命令的方式-c显示 CPU 使用情况。
自愿非自愿上下文切换查看
上下文切换可以分为
voluntary自愿involuntary非自愿
查询单个进程
通过查看/proc/{PID}/status文件我们可以看到某个进程的自愿和非自愿上下文切换的次数。
┌──[rootvms99.liruilongs.github.io]-[~]
└─$cat /proc/$$/status | grep voluntary
voluntary_ctxt_switches: 272
nonvoluntary_ctxt_switches: 1
┌──[rootvms99.liruilongs.github.io]-[~]
└─$voluntary_ctxt_switches: 272表示当前进程自愿上下文切换的次数为 272 次。自愿上下文切换通常是由进程主动让出 CPU 时间片引起的例如进程等待 I/O 操作完成或调用 sched_yield() 函数。
nonvoluntary_ctxt_switches: 1表示当前进程非自愿上下文切换的次数为 1 次。非自愿上下文切换通常是由操作系统调度器强制进行的例如当进程的时间片用完或高优先级进程抢占 CPU 时。
查询所有进程
┌──[rootliruilongs.github.io]-[~]
└─$pidstat -w 5
Linux 5.15.0-112-generic (liruilongs.github.io) 2024年09月04日 _x86_64_ (4 CPU)08时08分02秒 UID PID cswch/s nvcswch/s Command
08时08分07秒 0 14 13.77 0.00 rcu_sched
08时08分07秒 0 15 0.20 0.00 migration/0
08时08分07秒 0 21 0.20 0.00 migration/1
08时08分07秒 0 27 0.20 0.00 migration/2
08时08分07秒 0 33 0.20 0.00 migration/3
08时08分07秒 0 43 2.00 0.00 kcompactd0
08时08分07秒 0 56 4.19 0.00 kworker/2:1-events
08时08分07秒 0 111 2.99 0.00 kworker/u8:2-writeback
08时08分07秒 0 120 0.40 0.00 kworker/3:1H-kblockd
08时08分07秒 0 133 5.99 0.00 kworker/1:2-events
08时08分07秒 0 191 0.60 0.00 kworker/1:1H-kblockd这个工具需要注意旧版本可能没有上下文相关的指标
cswch:表示每秒自愿上下文切换voluntary context switches的次数nvcswch:表示每秒非自愿上下文切换non voluntary context switches的次数
pidstat 默认显示进程的指标数据加上 -t 参数后才会输出线程的指标
实战
上下文频繁切换导致的CPU饱和分析
Sysbench是一个开源的、模块化的、跨平台的多线程性能测试工具主要用于评估计算机系统在不同负载条件下的性能。
┌──[rootliruilongs.github.io]-[~]
└─$apt install sysbench -y当前的 CPU 指标信息
┌──[rootliruilongs.github.io]-[~]
└─$vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b 交换 空闲 缓冲 缓存 si so bi bo in cs us sy id wa st0 0 0 5195216 60404 1353744 0 0 140 43 620 4679 2 2 97 0 00 0 0 5195216 60404 1353744 0 0 0 0 439 762 1 0 98 0 00 0 0 5195216 60404 1353744 0 0 0 32 491 818 1 0 99 0 00 0 0 5195216 60412 1353736 0 0 0 16 425 683 1 0 99 0 00 0 0 5195216 60412 1353744 0 0 0 0 414 700 1 0 99 0 0
┌──[rootliruilongs.github.io]-[~]
└─$模拟系统多线程饱和调度
┌──[rootliruilongs.github.io]-[~]
└─$sysbench --threads10 --max-time300 threads run
WARNING: --max-time is deprecated, use --time instead
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)Running the test with following options:
Number of threads: 10
Initializing random number generator from current timeInitializing worker threads...Threads started!^C
┌──[rootliruilongs.github.io]-[~]
└─$通过 vmstat 来打印CPU 相关指标信息
┌──[rootliruilongs.github.io]-[~]
└─$vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b 交换 空闲 缓冲 缓存 si so bi bo in cs us sy id wa st9 0 0 5196448 60212 1353692 0 0 148 45 282 3355 1 1 98 0 05 0 0 5196448 60212 1353732 0 0 0 0 77739 1342743 32 53 16 0 09 0 0 5196448 60212 1353732 0 0 0 0 79785 1383450 28 56 16 0 07 0 0 5196448 60212 1353732 0 0 0 0 79945 1411280 27 57 16 0 07 0 0 5196224 60220 1353724 0 0 0 20 81862 1377316 29 55 16 0 0
┌──[rootliruilongs.github.io]-[~]
└─$
可以看到 中断数in和上下文切换数cs大幅度增大用户态和内核态 CPU 使用率同时增大主要为内核态(sy)CPU 呈现饱和状态空闲率(id)为 16%
同时系统就绪队列增加有进程在等待CPU时间但数量不是特别高如果上面的指标长时间保持可能需要排查是什么问题导致。
可以通过 pistat 来定位进程或在线程。通过 /proc/interrupts 分析中断类型
# -d 参数表示高亮显示变化的区域
$ watch -d cat /proc/interruptsCPU0 CPU1
...
RES: 2450431 5279697 Rescheduling interrupts
...每秒多少上下文切换才算正常
当上下文切换次数超过一万次或者切换次数出现数量级的增长时可能会出现性能问题。实际情况中可能还需要根据 自愿切换和非自愿切换来分情况讨论
自愿上下文切换变多了说明进程都在等待资源有可能发生了 I/O 等其他问题非自愿上下文切换变多了说明进程都在被强制调度也就是都在争抢 CPU说明 CPU 的确成了瓶颈中断次数变多了说明 CPU 被中断处理程序占用还需要通过查看 /proc/interrupts 文件来分析具体的中断类型。
配置CPU亲和性优化上下文
CPU 配置亲和性限制特定进程仅在特定的CPU或内核上运行(也称为CPU绑定或CPU亲和性)可以减少上下文切换
当进程被限制在特定的CPU上运行时操作系统会减少将其从一个CPU迁移到另一个CPU的可能性从而减少了上下文切换的开销。上下文切换涉及保存和恢复进程的CPU状态是一个相对昂贵的操作。
缓存局部性如果进程频繁访问内存中的某些区域将其绑定到某个CPU可以确保这些区域的数据和指令更可能驻留在该CPU的缓存中从而提高了缓存命中率降低了访问延迟。
taskset
taskset 是一个在 Linux 系统中用于设置或检索进程 CPU 亲和性(affinity)的命令行工具。通过 taskset你可以控制进程应该在哪些 CPU 核心或哪些 CPU 集合上运行。这对于性能调优和故障隔离特别有用。
更改已运行进程的 CPU 亲和性
┌──[rootliruilongs.github.io]-[~]
└─$taskset -pc 0 3960506
pid 3960506s current affinity list: 0,1
pid 3960506s new affinity list: 0
┌──[rootliruilongs.github.io]-[~]
└─$通过 /prod/{PID}/status 查看 CPU 亲和性
┌──[rootliruilongs.github.io]-[~]
└─$egrep Cpu /proc/3960506/status
Cpus_allowed: 1
Cpus_allowed_list: 0通过 systemd 的 service unit 文件配置
systemd 提供了简单的方法可用实现 CPU 资源的亲和性限制。通过在服务的 unit 文件中[Service]块中添加CPUAffinity即可。
[Service]
CPUAffinity1-3CPUAffinity0-3允许进程在 CPU 核心 0、1、2 和 3 上运行。CPUAffinity0,2,3允许进程在 CPU 核心 0、2 和 3 上运行但不允许在核心 1 上运行
如果一个 unit 文件中有多行 CPUAffinity 指令systemd 确实会合并这些设置但合并的方式是逻辑 OR而不是逻辑 AND。这意味着只要在任何一行 CPUAffinity 中列出的 CPU 核心进程都有权限运行。
也可以使用 命令行的方式
┌──[rootliruilongs.github.io]-[~]
└─$systemctl set-property service name CPUAffinityvalue使用 cgroup 的 cpuset 进行 CPU 亲和性限制
这里需要注意 cgroup 版本不同对应的限制方式也不同在 v2 版本中不直接支持 cpuset 控制器。cpuset 控制器是 cgroup v1 中的一个功能它允许管理员为 cgroup 中的进程分配特定的 CPU 核心和内存节点在 cgroup v2 中cpuset 功能被整合到了统一的资源管理中并且不再提供单独的 cpuset 控制器。
Cgroup V1
创建一个 cgroup
┌──[rootvms99.liruilongs.github.io]-[~]
└─$mkdir -p /sys/fs/cgroup/cpuset/cpuset0配置 cpuset,这里配置 CPU 允许在 0,1 对应的 CPU 上运行
┌──[rootvms99.liruilongs.github.io]-[~]
└─$echo 0-1 /sys/fs/cgroup/cpuset/cpuset0/cpuset.cpus
┌──[rootvms99.liruilongs.github.io]-[~]
└─$cat /sys/fs/cgroup/cpuset/cpuset0/cpuset.cpus
0-1将进程添加到 cgroup, 这里是 tasks 文件和 Cgroup v2 版本不同
┌──[rootvms99.liruilongs.github.io]-[~]
└─$echo 40604 /sys/fs/cgroup/cpuset/cpuset0/tasks
┌──[rootvms99.liruilongs.github.io]-[~]
└─$cat /sys/fs/cgroup/cpuset/cpuset0/tasks
40604验证配置
┌──[rootvms99.liruilongs.github.io]-[~]
└─$cat /proc/40604/status | grep Cpu
Cpus_allowed: 00000000,00000000,00000000,00000003
Cpus_allowed_list: 0-1┌──[rootvms99.liruilongs.github.io]-[~]
└─$printf %032x\n $((2**02**1))
00000000000000000000000000000003Cgroup V2
cgroup v2 中控制应用程序的 CPU 亲和性需要启用特定的 CPU 控制器,并创建一个专用的控制组。建议在 /sys/fs/cgroup/ 根控制组群中至少创建两级子控制组
验证 /sys/fs/cgroup/cgroup.controllers 文件中是否提供了 cpu 和 cpuset 控制器
┌──[rootliruilongs.github.io]-[~]
└─$cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory hugetlb pids rdma misc为 /sys/fs/cgroup/ 根控制组的直接子组启用了 cpu 和 cpuset 控制器。子组 是可以指定进程的 Cgroup 层级并根据标准对每个进程应用控制检查的地方,用户可以在任意级别读取 cgroup.subtree_control 文件的内容以了解子组中哪些控制器可用于启用。默认情况下根控制组中的 /sys/fs/cgroup/cgroup.subtree_control 文件包含 memory 和 pids 控制器。
┌──[rootliruilongs.github.io]-[~]
└─$cat /sys/fs/cgroup/cgroup.subtree_control
memory pids
┌──[rootliruilongs.github.io]-[~]
└─$echo cpu /sys/fs/cgroup/cgroup.subtree_control
┌──[rootliruilongs.github.io]-[~]
└─$echo cpuset /sys/fs/cgroup/cgroup.subtree_control
┌──[rootliruilongs.github.io]-[~]
└─$cat /sys/fs/cgroup/cgroup.subtree_control
cpuset cpu memory pids
┌──[rootliruilongs.github.io]-[~]
└─$创建 /sys/fs/cgroup/Example/ 目录,/sys/fs/cgroup/Example/ 目录定义了一个子组。此外上一步为这个子组启用了 cpu 和 cpuset 控制器。
┌──[rootliruilongs.github.io]-[~]
└─$mkdir /sys/fs/cgroup/Example/
┌──[rootliruilongs.github.io]-[~]
└─$cat /sys/fs/cgroup/Example/cgroup.controllers
cpuset cpu memory pids创建 /sys/fs/cgroup/Example/ 目录时一些 cgroups-v2 接口文件以及 cpu 和 cpuset 特定于控制器的文件也会在目录中自动创建。/sys/fs/cgroup/Example/目录还包含 memory 和 pids 控制器的特定于控制器的文件
┌──[rootliruilongs.github.io]-[~]
└─$ls /sys/fs/cgroup/Example/
cgroup.controllers cpuset.cpus.exclusive memory.oom.group
cgroup.events cpuset.cpus.exclusive.effective memory.peak
cgroup.freeze cpuset.cpus.partition memory.reclaim
cgroup.kill cpuset.mems memory.stat
cgroup.max.depth cpuset.mems.effective memory.swap.current
cgroup.max.descendants cpu.stat memory.swap.events
cgroup.procs cpu.weight memory.swap.high
cgroup.stat cpu.weight.nice memory.swap.max
cgroup.subtree_control memory.current memory.swap.peak
cgroup.threads memory.events memory.zswap.current
cgroup.type memory.events.local memory.zswap.max
cpu.idle memory.high pids.current
cpu.max memory.low pids.events
cpu.max.burst memory.max pids.max
cpuset.cpus memory.min pids.peak
cpuset.cpus.effective memory.numa_stat
┌──[rootliruilongs.github.io]-[~]
└─$启用 /sys/fs/cgroup/Example/ 中与 CPU 相关的控制器以获取仅与 CPU 相关的控制器
──[rootliruilongs.github.io]-[~]
└─$echo cpu /sys/fs/cgroup/Example/cgroup.subtree_control
┌──[rootliruilongs.github.io]-[~]
└─$echo cpuset /sys/fs/cgroup/Example/cgroup.subtree_control创建 /sys/fs/cgroup/Example/tasks/ 目录,/sys/fs/cgroup/Example/tasks/ 目录定义了一个子组以及只与 cpu 和 cpuset 控制器相关的文件。
┌──[rootliruilongs.github.io]-[~]
└─$mkdir /sys/fs/cgroup/Example/tasks/
┌──[rootliruilongs.github.io]-[~]
└─$cat /sys/fs/cgroup/Example/tasks/cgroup.controllers
cpuset cpu
┌──[rootliruilongs.github.io]-[~]
└─$配置 CPU 亲和性
┌──[rootliruilongs.github.io]-[~]
└─$echo 1 /sys/fs/cgroup/Example/tasks/cpuset.cpus
┌──[rootliruilongs.github.io]-[~]
└─$通过 httpd 的服务测试
┌──[rootliruilongs.github.io]-[~]
└─$systemctl enable --now httpd
┌──[rootliruilongs.github.io]-[~]
└─$pgrep httpd
879
1096
1098
1105
1106
11313
┌──[rootliruilongs.github.io]-[~]
└─$cat /proc/1105/status | grep Cpu
Cpus_allowed: 3
Cpus_allowed_list: 0-1将服务的 PID 添加到 Example/tasks 子组中
┌──[rootliruilongs.github.io]-[~]
└─$echo 1105 /sys/fs/cgroup/Example/tasks/cgroup.procs验证配置
┌──[rootliruilongs.github.io]-[~]
└─$cat /proc/1105/status | grep Cpu
Cpus_allowed: 2
Cpus_allowed_list: 1
┌──[rootliruilongs.github.io]-[~]
└─$
┌──[rootvms99.liruilongs.github.io]-[~]
└─$printf %032x\n $((2**1))
00000000000000000000000000000002关于 CPU 上下文就可小伙伴们分享到这里 ^_^
博文部分内容参考
© 文中涉及参考链接内容版权归原作者所有如有侵权请告知 《BPF Performance Tools》读书笔记
《Linux性能优化》中文版
极客时间 《Linux 性能优化实战》 课程笔记 © 2018-2024 liruilongergmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)
