ECS运维指南 之 Linux系统诊断.pdf

ECS 是当前阿里云的核心产品，又是很多云服务的基座产品，随着集团内部上云，越来越多的应用和服务构建在 ECS之上，而针对使用 ECS 的阿里云用户提交的售后问题也是多而广，为了更好地服务用户，并使得越来越多的用户能够“自助”了解 ECS 系统问题诊断的方法，阿里云全球技术支持中心 GTS 的 ECS 系统售后团队根据多年的丰富排查经验，总结并选取出一些可以抛砖引玉的处理思路和方案，希望可以“四两拨千斤”。前言Linux 启动与登录问题5超详细系统启动与登陆异常排查点5grub.conf 文件内容被清空了怎么办11巧妙利用 strace 查找丢失的文件13小心 PAM 不让你登录15CentOS 登录卡住的原因被我找到了16Linux 性能问题18找到 Linux 虚机 Load 高的“元凶”18OOMkiller 是被谁触发的24我的服务器内存去哪儿了32CPU 占用不高但网络性能很差的一个原因37一次 IO 异常捕获过程46Linux 主机网络问题50ifdownifup命令丢失处理50网络不通？strace 二度出手52TIME_WAIT&CLOSE_WAIT 的讨论总结57一次网络抖动经典案例分析65Linux 系统服务与参数问题704 个 limits 生效的问题706 步排查 ss&netstat统计结果不一样的原因75为什么明明内存很充足但是 java 程序仍申请不到内存78请不要忽略 min_free_kbytes 的设置86最后的彩蛋89某地区口罩项目架构演进及优化经验89目录Linux 启动与登录问题Linux启动与登录问题是 ECS 的高频问题，而往往处理不及时会直接影响到用户业务的正常可持续运行，因此也变成了我们处理问题优先级的重中之重。在云环境上影响 ECS 启动与登录的因素非常多，镜像、管控、虚拟化、底层硬件、系统与文件异常等等，本文仅从系统与文件本身角度，在大量处理经验的基础上，归纳总结了一些可能会引起系统启动与登录问题的排查点，并给出几个比较常见的典型案例来具体展示和说明。超详细系统启动与登陆异常排查点系统启动异常1.部分 CentOS 系统启动黑屏，无异常报错的场景，可以 fsck 一下系统盘。2.根分区空间满，以及 inode 数量耗尽。3.升级内核或者从老的共享实例迁移到独享规格导致的启动异常。3.1 手动注入驱动(mkinitrdvirtio 相关驱动)。3.2 修改 grub的启动顺序，优先尝试使用老内核启动。3.3 /boot 目录下面内核的关联文件是否全（下面仅为 demo，不同系统内核版本文件不一致，部分内核版本 boot 下的 i386 目录也是有用的）。6超详细系统启动与登陆异常排查点config-4.9.0-7-amd64 initrd.img-4.9.0-7-amd64 System.map-4.9.0-7-amd64 vmlinuz-4.9.0-7-amd643.4/boot/grub/device.map 里面的 hda 改成 vda。4.fstab/grub 中的uuid 不对，可以直接修改为/dev/vda1 这种形式尝试。数据盘分区异常加载起不来的场景，可以去注释 fstab 所有的行，添加类似下面的启动项尝试，也适用于系统盘快照创建云盘挂载后，uuid 一致导致的启动异常，改成非 UUID 的挂载即可。/dev/vda1/ext4 defaults 1 15.根目录权限 777（部分目录 777）也会导致启动异常，或者 ssh 登陆异常。可参考下面的文章仅限修复尝试。https:/ /sbin/lib /lib32/lib64/etc/boot/usr/bin/usr/sbin/usr/lib/usr/lib64 等目录或文件缺失for i in/bin /sbin/lib /lib32/lib64/etc/boot/usr/bin/usr/sbin/usr/lib/usr/lib64;do ls-l$i|wc-l;done7.影响启动的参数。如果参数设置不当，是会导致启动异常的，如/etc/sysctl.conf 以及检查 rc.local的配置，profile 的检查。vm.nr_hugepages vm.min_free_kbytes超详细系统启动与登陆异常排查点超详细系统启动与登陆异常排查点configuration error-cannot parse erasechar value9.输入 root 后直接 login 失败三连，日志如下。找个同内核版本的机器对比发现没有/etc/pam.d/login。rpm 包校验一下，确认 login 文件没了，手动创建一个，内容拷贝过来，好了。rootiZbp1cabe6lyx26ikmjie2Z pam.d#rpm-V util-linuxmissing c/etc/pam.d/loginrootiZbp1cabe6lyx26ikmjie2Z pam.d#rpm-ql util-linux|egrep-vi gz|mo|share/etc/mtab/etc/pam.d/chfn/etc/pam.d/chsh/etc/pam.d/login/etc/pam.d/runuser/etc/pam.d/runuser-l/etc/pam.d/su/etc/pam.d/su-l10./etc/ssh/sshd_config 相关参数如LoginGraceTime/Allowusers/Permit-RootLogin。11.问题不好确认的时候，可以将 shadow 密码字段清空，看看登陆是否正常，可以判断是否到密码验证阶段了。之前有过一篇关于 ssh 问题排查的文档，可参考：https:/ LiveCD 或者chroot 切换；但对于使用 ECS 的用户来说，阿里云暂还未提供实例挂载 ISO 镜像的超详细系统启动与登陆异常排查点超详细系统启动与登陆异常排查点脚本共享给大家 OS 参数收集脚本：https:/public-beijing.oss-cn- 优化脚本 github 链接：https:/ 优化脚本 OSS 链接：https:/xiaoling-public.oss-cn- 离 线 修 复 脚 本：https:/public-beijing.oss-cn- 文件内容被清空了怎么办 root(hd0,0)#是说跟分区在第一块硬盘的第 1 个分区 实际对于前面的 find 出来的那个文件grub kernel/boot/vmlinuz-2.6.32-696.3.2.el6.x86_64 ro root=/dev/vda1#指明内核路径和根分区，注意 ro 是只读grub initrd /boot/initramfs-2.6.32-696.3.2.el6.x86_64.img#指明 initramfs路径启动系统加载驱动grub boot#启动上面指定的系统，如果是 reboot 就等于重启整个系统了，刚才的设置就失效了如果没有报错的话，即可成功启动，进入到系统内部后需要继续支持。12grub.conf 文件内容被清空了怎么办4.mount-eremount,rw/重新挂载分区为读写。5.servicenetworkrestart。如果提示 eth0eth1 失败，ifconfig 看不到网卡的话。6.lsmod|grepnet。看下 virtio_net这个驱动有没有，如果没有的话（网卡报错基本都不会有）。7.insmod/lib/modules/2.6.32-696.3.2.el6.x86_64/kernel/drivers/net/virtio_net.ko。8.重启网络服务，嗨 网通了。9.登陆 ssh，找个同版本系统的 grub.conf，拷贝一份过来，不然重启之后又进grub 了。参考 https:/ strace 查找丢失的文件巧妙利用 strace 查找丢失的文件3.查看对应文件的关系（测试机补图）。4.确认系统上丢了最终的 libnss_files-2.12.so，尝试拷贝一个。ifconfig eth1 netmask route add default gw 5.此时已经可以上网了，去拷贝一个同版本的文件试试吧。小心 PAM 不让你登录CentOS 登录卡住的原因被我找到了CentOS 登录卡住的原因被我找到了问题现象系统登陆卡住，需要 ctrl+c才能进去，如图。如果一直等的话，会提示如下截图：CentOS 登录卡住的原因被我找到了17原因/etc/profile里面有source/etc/profile引起死循环，注释即可。Linux 性能问题Linux 性能问题的排查和处理一直是系统管理和运维人员的“心头之患”，CPU 负载高但找不到消耗大的进程；系统出现 OOM（OutofMemory）只会一味地增大内存容量，而没有很好地理解和分析问题背后产生的根因。而这些都对线上业务的可靠和稳定性提出了挑战。本文将阿里云售后遇到的较为常见的几个系统性能问题进行展开分析，并给出一些合理的改进和优化方案。找到 Linux 虚机 Load 高的“元凶”问题描述有客户反馈他们的一台 ECS 周期性地 load 升高，他们的业务流量并没有上升，需要我们排查是什么原因造成的，是否因为底层异常？要弄清 Linux 虚机 load 高，我们要搞清楚 Linuxtop 命令中 Load 的含义。Loadaverage 的值从何而来在使用 top 命令检查系统负载的时候，可以看到 Load averages 字段，但是这个字段并不是表示 CPU 的繁忙程度，而是度量系统整体负载。Load averages 采样是从/proc/loadavg 中获取的：找到 Linux 虚机 Load 高的“元凶”last_pid);return 0;Load 的计算函数：static unsigned longcalc_load(unsigned long load，unsigned long exp，unsigned long active)load*=exp;load+=active*(FIXED_1-exp);return load FSHIFT;/*calc_load-update the avenrun load estimates 10 ticks after the*CPUs have updated calc_load_tasks.*/20找到 Linux 虚机 Load 高的“元凶”void calc_global_load(void)unsigned long upd=calc_load_update+10;long active;if(time_before(jiffies，upd)return;active=atomic_long_read(&calc_load_tasks);active=active 0?active*FIXED_1:0;avenrun0=calc_load(avenrun0，EXP_1，active);avenrun1=calc_load(avenrun1，EXP_5，active);avenrun2=calc_load(avenrun2，EXP_15，active);calc_load_update+=LOAD_FREQ;/*These are the constant used to fake the fixed-point load-average*counting.Some notes:*-11 bit fractions expand to 22 bits by the multiplies:this gives*a load-average precision of 10 bits integer+11 bits fractional*-if you want to count load-averages more often，you need more*precision，or rounding will get you.With 2-second counting freq,*the EXP_n values would be 1981，2034 and 2043 if still using only*11 bit fractions.*/extern unsigned long avenrun;/*Load averages*/extern void get_avenrun(unsigned long*loads，unsigned long offset，int shift);#define FSHIFT 11 /*nr of bits of precision*/#define FIXED_1 (1=FSHIFT;从这个函数中可以看到，内核计算 load 采用的是一种平滑移动的算法，Linux 的系统负载指运行队列的平均长度，需要注意的是：可运行的进程是指处于运行队列的找到 Linux 虚机 Load 高的“元凶”找到 Linux 虚机 Load 高的“元凶”从统计出来的结果可以看到：at Jan 20 15:54:12 CST 2018D 958 958 957 nginxD 959 959 957 nginxD 960 960 957 nginxD 961 961 957 nginxR 962 962 957 nginxD 963 963 957 nginxD 964 964 957 nginxD 965 965 957 nginxD 966 966 957 nginxD 967 967 957 nginxD 968 968 957 nginxD 969 969 957 nginxD 970 970 957 nginxD 971 971 957 nginxD 972 972 957 nginxD 973 973 957 nginxD 974 974 957 nginxR 975 975 957 nginxD 976 976 957 nginxD 977 977 957 nginxD 978 978 957 nginxD 979 979 957 nginxR 980 980 957 nginxD 983 983 957 nginxD 984 984 957 nginxD 985 985 957 nginxD 986 986 957 nginxD 987 987 957 nginxD 988 988 957 nginxD 989 989 957 nginxR 11908 11908 18870 psSat Jan 20 15:54:12 CST 201825.76 20.60 19.00 12/404 11912注：R 代表运行中的队列，D 是不可中断的睡眠进程在 load 比较高的时候，有大量的 nginx 处于 R 或者 D 状态，他们才是造成 load 上升的元凶，和我们底层的负载确实是没有关系的。最后也给大家 share 一下查 CPU 使用率比较高的线程小脚本：#!/bin/bashLANG=CPATH=/sbin:/usr/sbin:/bin:/usr/bin找到 Linux 虚机 Load 高的“元凶”OOMkiller 是被谁触发的OOMkiller 是被谁触发的问题描述用户发现自己的服务器 CPU 在某一时刻陡然升高，但从监控上看，同一时刻的业务量却并不高，客户怀疑是云服务器有问题，希望技术支持团队予以解决。经过我们的排查，发现 cpu 的两次间歇飙高是由于客户系统当时发生了 OOM（outofmemory）的情况，并触发了 oom-killer 造成的。但客户并不接受这个结论，认为是云服务器的异常导致了 cpu 飙高，而 cpu 的升高又导致了 oom 情况的发生。也就是对于 cpu 升高和 oom 谁为因果这件事上，客户和我们持完全相反的态度。下面我们将通过对 oom 时系统日志的解读来说明 cpu 升高和 oom 之间的因果关系。知识点梳理1.预备知识在解读日志之前，我们先回顾一下 linux 内核的内存管理。1.1 几个基本的概念（1）Page页处理器的最小寻址单元是字节或者字，而页是内存的管理单元。（2）Zone区（a）区存在的原因：有些硬件设备只能对特定的内存地址执行 DMA（directmemoryaccess）操作。OOMkiller 是被谁触发的25在一些架构中，实际物理内存是比系统可寻址的虚拟内存要大的，这就导致有些物理内存没有办法被永久的映射在内核的地址空间中。区的划分也是直接以上面两个原因为依据的。（b）区的种类ZONE_DMA这个区包含的 page 可以执行 DMA 操作。这部分区域的大小和 CPU 架构有关，在 x86 架构中，该部分区域大小限制为 16MB。ZONE_DMA32类似于 ZOME_DMA，这个区也包含可以执行 DMA 操作的 page。该区域只存在于 64 位系统中，适合 32 位的设备访问。ZONE_NORMAL这个区包含可以正常映射到地址空间中的 page，或者说这个区包含了除了 DMA 和 HIGHMEM 以外的内存。许多内核操作都仅在这个区域进行。ZONE_HIGHMEM这个区包含的是 highmemory，也就是那些不能被永久映射到内核地址空间的页。32 位的 x86 架构中存在三种内存区域，ZONE_DMA，ZONE_NORMAL，ZONE_HIGHMEM。根据地址空间划分的不同，三个区域的大小不一样：1）1G 内核空间/3G 用户空间ZONE_DMA 8962)4G 内核空间/4G 用户空间ZONE_DMA 3968M64 位的系统由于寻址能力的提高，不存在 highmem 区，所以 64 位系统中存在的区有 DMA，DMA32 和 NORMAL 三个区。26OOMkiller 是被谁触发的ZONE_DMA 4G1.2 内核分配内存的函数下面是内核分配内存的核心函数之一，它会分配 2 的 order 次方个连续的物理页内存，并将第一页的逻辑地址返回。unsigned long _get_free_pages(gfp_t gfp_mask，unsigned int order)内核空间的内存分配函数和用户空间最大的不同就是每个函数会有一个 gfp_mask 参数。其中 gfp代表的就是我们上面的内存分配函数_get_free_pages()。gfp_mask 可以分成三种：行为修饰符（actionmodifier）,区修饰符（zonemodifier）和类型（type）。（1）行为修饰符是用来指定内核该如何分配内存的。比如分配内存时是否可以进行磁盘 io，是否可以进行文件系统操作，内核是否可以睡眠（sleep）等等。（2）区修饰符指定内存需要从哪个区来分配。（3）类型是行为修饰符和区修饰符结合之后的产物。在一些特定的内存分配场合下，我们可能需要同时指定多个行为修饰符和区修饰符，而 type 就是针对这些固定的场合，将所需要的行为修饰符和区修饰符都整合到了一起，这样使用者只要指定一个 type 就可以了。不同 type 所代表的含义可以参看下面的表格：2.日志解读 下面是从 oomkiller 被触发到进程到被杀掉的一个大概过程，我们来具体看一下。OOMkiller 是被谁触发的OOMkiller 是被谁触发的33366 pages reserved pid uid tgid total_vm rss nr_ptes swapents oom_score_adj name 355 0 355 4868 66 13 0 0 upstart-udev-br 361 0 361 12881 145 28 0 -1000 systemd-udevd 499 0 499 3814 60 13 0 0 upstart-socket-562 0 562 5855 79 15 0 0 rpcbind 644 106 644 5398 142 16 0 0 rpc.statd 775 0 775 3818 58 12 0 0 upstart-file-br.（此处有省略）10396 104 10396 21140 12367 44 0 0 nginx10397 104 10397 21140 12324 44 0 0 nginx10398 104 10398 21140 12324 44 0 0 nginx10399 104 10399 21140 12367 44 0 0 nginxOut of memory:Kill process 10366(nginx)score 6 or sacrifice childKilled process 10366(nginx)total-vm:84784kB，anon-rss:49156kB，file-rss:520kB先来看一下第一行，它给出了 oomkiller 是由谁触发的信息。nginx invoked oom-killer:gfp_mask=0 x200da，order=0，oom_score_adj=0 order=0告诉我们所请求的内存的大小是多少，即 nginx 请求了 2 的 0 次方这么多个 page 的内存，也就是一个 page，或者说是 4KB。gfp_mask 的最后两个 bit 代表的是 zonemask，也就是说它指明内存应该从哪个区来分配。FlagvalueDescription 0 x00u 0 implicitly means allocate from ZONE_NORMAL_GFP_DMA0 x01uAllocatefromZONE_DMAifpossible_GFP_HIGHMEM0 x02uAllocatefromZONE_HIGHMEMifpossible（这里有一点需要注意，在 64 位的 x86 系统中，是没有 highmem 区的，64 位OOMkiller 是被谁触发的OOMkiller 是被谁触发的这里我们说一下一个常见的误区，就是有人会认为触发了 oomkiller 的进程就是问题的罪魁祸首，比如我们这个例子中的这个 nginx 进程。其实日志中 invokeoomkiller 的这个进程有时候可能只是一个受害者，因为其他应用进程已将系统内存用尽，而这个 invokeoomkiller 的进程恰好在此时发起了一个分配内存的请求而已。在系统内存已经不足的情况下，任何一个内存请求都可能触发oomkiller 的启动。oomkiller 的启动会使系统从用户空间转换到内核空间。内核会在短时间内进行大量的工作，比如计算每个进程的 oom 分值，从而筛选出最适合杀掉的进程。我们从日志中也可以看到这一筛选过程：pid uid tgid total_vm rss nr_ptes swapents oom_score_adj name 355 0 355 4868 66 13 0 0 upstart-udev-br 361 0 361 12881 145 28 0 -1000 systemd-udevd 499 0 499 3814 60 13 0 0 upstart-socket-562 0 562 5855 79 15 0 0 rpcbind 644 106 644 5398 142 16 0 0 rpc.statd 775 0 775 3818 58 12 0 0 upstart-file-br.10396 104 10396 21140 12367 44 0 0 nginx10397 104 10397 21140 12324 44 0 0 nginx10398 104 10398 21140 12324 44 0 0 nginx10399 104 10399 21140 12367 44 0 0 nginx本例中，一个 nginx 进程被选中作为缓解内存压力的牺牲进程：Out of memory:Kill process 10366(nginx)score 6 or sacrifice childKilled process 10366(nginx)total-vm:84784kB，anon-rss:49156kB，file-rss:520kB整个过程进行的时间很短，只有毫秒级别，但是工作量计算量很大，这就导致了 cpu 短时间内迅速飙升，出现峰值。但这一切工作都由内核在内核空间中完OOMkiller 是被谁触发的我的服务器内存去哪儿了我的服务器内存去哪儿了背景：收到报警，系统的内存使用率触发阈值（部分图是后补的）。我的服务器内存去哪儿了我的服务器内存去哪儿了2.发现 cache 才 1.7G，slab 非常高，4.4G，slab 内存简单理解为是系统占用的。使用 slabtop 继续分析。我的服务器内存去哪儿了我的服务器内存去哪儿了5.每个 socket 的 inode 也不一样。当时看到的现场有几万个 fd，基本全是 socket，每个 inode 都是占用空间的，且 proc 文件系统是全内存的。所以我们才会看到 slab 中 proc_inode_cache内存占用高。建议：建议用户需要从程序上优化相关的 server 端 CPU 占用不高但网络性能很差的一个原因CPU 占用不高但网络性能很差的一个原因什么是 RPS/RFSRPS（ReceivePacketSteering）主要是把软中断的负载均衡到各个 cpu，简单来说，是网卡驱动对每个流生成一个 hash 标识，这个 HASH 值得计算可以通过四元组来计算（SIP，SPORT，DIP，DPORT），然后由中断处理的地方根据这个 hash标识分配到相应的 CPU 上去，这样就可以比较充分的发挥多核的能力了。通俗点来说就是在软件层面模拟实现硬件的多队列网卡功能，如果网卡本身支持多队列功能的话 RPS 就不会有任何的作用。该功能主要针对单队列网卡多 CPU 环境，如网卡支持多队列则可使用 SMPirqaffinity 直接绑定硬中断。图 1只有 RPS 的情况下（来源网络）由于 RPS 只是单纯把数据包均衡到不同的 cpu，这个时候如果应用程序所在的 cpu和软中断处理的 cpu 不是同一个，此时对于 cpucache 的影响会很大，那么 RFS（Receiveflowsteering）确保应用程序处理的 cpu 跟软中断处理的 cpu 是同一个，这样就充分利用 cpu 的 cache，这两个补丁往往都是一起设置，来达到最好的优化效果，主要是针对单队列网卡多 CPU 环境。CPU 占用不高但网络性能很差的一个原因CPU 占用不高但网络性能很差的一个原因c)处理中断的 CPU 总是会变，导致了更多的 context switch。d）也存在一些情况，启动了 irqbalance，但是并没有生效，没有真正去设置处理中断的 cpu。如何查看网卡的队列数1.Combined 代表队列个数，说明我的测试机有 4 个队列。#ethtool-l eth0Channel parameters for eth0:Pre-set maximums:RX:0TX:0Other:0Combined:4Current hardware settings:RX:0TX:0Other:0Combined:42.以 CentOS7.6 为例，系统处理中断的记录在/proc/interrupts 文件里面，默认这个文件记录比较多，影响查看，同时如果 cpu 核心也非常多的话，对于阅读的影响非常大。#cat/proc/interrupts CPU0 CPU1 CPU2 CPU3 0:141 0 0 0 IO-APIC-edge timer 1:10 0 0 0 IO-APIC-edge i8042 4:807 0 0 0 IO-APIC-edge serial 6:3 0 0 0 IO-APIC-edge floppy 8:0 0 0 0 IO-APIC-edge rtc0 9:0 0 0 0 IO-APIC-fasteoi acpi 10:0 0 0 0 IO-APIC-fasteoi virtio3 11:22 0 0 0 IO-APIC-fasteoi uhci_hcd:usb1 12:15 0 0 0 IO-APIC-edge i8042 14:0 0 0 0 IO-APIC-edge ata_piix 15:0 0 0 0 IO-APIC-edge ata_piix 24:0 0 0 0 PCI-MSI-edge virtio1-configCPU 占用不高但网络性能很差的一个原因CPU 占用不高但网络性能很差的一个原因Linux 3.10.0-957.5.1.el7.x86_64(iZwz98aynkjcxvtra0f375Z)05/26/2020 _x86_64_ (4 CPU)05:10:06 PM CPU%user%nice%system%iowait%steal%idle05:10:07 PM all 5.63 0.00 3.58 1.02 0.00 89.7705:10:07 PM 0 6.12 0.00 3.06 1.02 0.00 89.8005:10:07 PM 1 5.10 0.00 5.10 0.00 0.00 89.8005:10:07 PM 2 5.10 0.00 3.06 2.04 0.00 89.8005:10:07 PM 3 5.10 0.00 4.08 1.02 0.00 89.8005:10:07 PM CPU%user%nice%system%iowait%steal%idle05:10:08 PM all 8.78 0.00 15.01 0.69 0.00 75.5205:10:08 PM 0 10.00 0.00 16.36 0.91 0.00 72.7305:10:08 PM 1 4.81 0.00 13.46 1.92 0.00 79.8105:10:08 PM 2 10.91 0.00 15.45 0.91 0.00 72.7305:10:08 PM 3 9.09 0.00 14.55 0.00 0.00 76.36sar 小技巧打印 idle 小于 10 的核心sar-P 1,3,5,7 1|tail-n+3|awk$NF10 print$0看所有核心是否有单核打满的把 1357 换成 ALL 即可sar-P ALL 1|tail-n+3|awk$NF10 print$0再贴一个 4c8g 规格的配置（ecs.c6.xlarge），可以看到 4c 也给了四个队列，但是默认设置的是在 cpu0 和 2 上处理中断#grep-i input/proc/interrupts 27:1932 0 0 0 PCI-MSI-edge virtio2-input.0 29:2 0 1627 0 PCI-MSI-edge virtio2-input.1 32:1974 0 0 0 PCI-MSI-edge virtio2-input.2 35:3 0 284 0 PCI-MSI-edge virtio2-input.3#for i in$(egrep-input./proc/interrupts|awk-F:print$1);do cat/proc/irq/$i/smp_affinity_list;done1313原因是 cpu 是超线程的，每个 vCPU 绑定到一个物理 CPU 超线程,所以即使是 4 个队列默认也在 2CPU 占用不高但网络性能很差的一个原因CPU 占用不高但网络性能很差的一个原因改这两个任意一个文件，另一个文件会同步更改。为了方便理解，咱们直接看十进制的文件 smp_affinity_list 即可。如果这一步没看明白，注意前面的/proc/interrupts 的输出#for i in$(egrep-input./proc/interrupts|awk-F:print$1);do cat/proc/irq/$i/smp_affinity_list;done1313手动设置处理中断的 CPU 号码可以直接 echo 修改，下面就是将序号 27 的中断放到 cpu0 上处理，一般建议可以把 cpu0 空出来#echo 0 /proc/irq/27/smp_affinity_list#cat/proc/irq/27/smp_affinity_list0关于 bitmaskf 是十六进制的值对应的 二进制是 1111（可以理解为 4c 的配置设置为 f 的话，所有的 cpu 参与处理中断）二进制中的每个位代表了服务器上的每个 CPU.一个简单的 demo CPU 序号 二进制 十六进制 CPU 0 0001 1 CPU 1 0010 2 CPU 2 0100 4 CPU 3 1000 85.2 需要对每块网卡每个队列分别进行设置。如对 eth0 的 0 号队列设置：echo ff /sys/class/net/eth0/queues/rx-0/rps_cpus这里的设置方式和中断亲和力设置的方法是类似的。采用的是掩码的方式，但是这里通常要将所有的 CPU 设置进入，如：4core，f8core，ff16core，ffff32core，ffffffff默认在 0 号 cpu 上CPU 占用不高但网络性能很差的一个原因/sys/class/net/eth0/queues/rx-0/rps_cpus#cat/sys/class/net/eth0/queues/rx-0/rps_cpusf6.设置 RFS 的方式。需要设置两个地方：6.1 全局表：rps_sock_flow_table 的条目数量。通过一个内核参数控制：#sysctl-a|grep net.core.rps_sock_flow_entriesnet.core.rps_sock_flow_entries=0#sysctl-w net.core.rps_sock_flow_entries=1024net.core.rps_sock_flow_entries=10246.2 每个网卡队列 hash 表的条目数：#cat/sys/class/net/eth0/queues/rx-0/rps_flow_cnt0#echo 256 /sys/class/net/eth0/queues/rx-0/rps_flow_cnt#cat/sys/class/net/eth0/queues/rx-0/rps_flow_cnt256需要启动 RFS，两者都需要设置。建议机器上所有的网卡队列设置的 rps_flow_cnt 相加应该小于或者等于rps_sock_flow_entries。因为是 4 个队列，因此每个队列设置 256，可以根据实际情况增大。46一次 IO 异常捕获过程一次 IO 异常捕获过程简介：遇到一个 IO 异常飙升的问题，IO 起飞后系统响应异常缓慢，看不到现场一直无法定位问题，检查对应时间点应用日志也没有发现异常的访问，这种问题怎么办呢？1.采集系统 IO，确认 IO 异常发生在系统盘，还是数据盘，使用系统自带的 iostat 即可采集#iostat-d 3 -k-x-t 3006/12/2018 09:52:33 AMDevice:rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm%utilxvda 0.00 0.39 0.08 0.70 1.97 5.41 18.81 0.03 44.14 1.08 0.08xvdb 0.00 0.00 0.00 0.00 0.00 0.00 8.59 0.00 1.14 1.09 0.0006/12/2018 09:52:36 AMDevice:rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svct