ECS运维指南 之 Linux系统诊断.pdf
《ECS运维指南 之 Linux系统诊断.pdf》由会员分享,可在线阅读,更多相关《ECS运维指南 之 Linux系统诊断.pdf(95页珍藏版)》请在咨信网上搜索。
1、ECS 是当前阿里云的核心产品,又是很多云服务的基座产品,随着集团内部上云,越来越多的应用和服务构建在 ECS之上,而针对使用 ECS 的阿里云用户提交的售后问题也是多而广,为了更好地服务用户,并使得越来越多的用户能够“自助”了解 ECS 系统问题诊断的方法,阿里云全球技术支持中心 GTS 的 ECS 系统售后团队根据多年的丰富排查经验,总结并选取出一些可以抛砖引玉的处理思路和方案,希望可以“四两拨千斤”。前言Linux 启动与登录问题5超详细系统启动与登陆异常排查点5grub.conf 文件内容被清空了怎么办11巧妙利用 strace 查找丢失的文件13小心 PAM 不让你登录15CentO
2、S 登录卡住的原因被我找到了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 程序仍申请不到
3、内存78请不要忽略 min_free_kbytes 的设置86最后的彩蛋89某地区口罩项目架构演进及优化经验89目录Linux 启动与登录问题Linux启动与登录问题是 ECS 的高频问题,而往往处理不及时会直接影响到用户业务的正常可持续运行,因此也变成了我们处理问题优先级的重中之重。在云环境上影响 ECS 启动与登录的因素非常多,镜像、管控、虚拟化、底层硬件、系统与文件异常等等,本文仅从系统与文件本身角度,在大量处理经验的基础上,归纳总结了一些可能会引起系统启动与登录问题的排查点,并给出几个比较常见的典型案例来具体展示和说明。超详细系统启动与登陆异常排查点系统启动异常1.部分 CentOS
4、系统启动黑屏,无异常报错的场景,可以 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
5、-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:
6、/ /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超详细系统启动与登陆异常排查
7、点超详细系统启动与登陆异常排查点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
8、-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:/ Live
9、CD 或者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 出来的那个文
10、件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/重新挂载分
11、区为读写。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
12、 查找丢失的文件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引起死循环,注释即可。L
13、inux 性能问题Linux 性能问题的排查和处理一直是系统管理和运维人员的“心头之患”,CPU 负载高但找不到消耗大的进程;系统出现 OOM(OutofMemory)只会一味地增大内存容量,而没有很好地理解和分析问题背后产生的根因。而这些都对线上业务的可靠和稳定性提出了挑战。本文将阿里云售后遇到的较为常见的几个系统性能问题进行展开分析,并给出一些合理的改进和优化方案。找到 Linux 虚机 Load 高的“元凶”问题描述有客户反馈他们的一台 ECS 周期性地 load 升高,他们的业务流量并没有上升,需要我们排查是什么原因造成的,是否因为底层异常?要弄清 Linux 虚机 load 高,我们
14、要搞清楚 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)lo
15、ad*=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=at
16、omic_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.Som
17、e 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 an
18、d 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 的系统负载指运行队列的平均长度,需要注意
19、的是:可运行的进程是指处于运行队列的找到 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
20、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
21、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/bashLAN
22、G=CPATH=/sbin:/usr/sbin:/bin:/usr/bin找到 Linux 虚机 Load 高的“元凶”OOMkiller 是被谁触发的OOMkiller 是被谁触发的问题描述用户发现自己的服务器 CPU 在某一时刻陡然升高,但从监控上看,同一时刻的业务量却并不高,客户怀疑是云服务器有问题,希望技术支持团队予以解决。经过我们的排查,发现 cpu 的两次间歇飙高是由于客户系统当时发生了 OOM(outofmemory)的情况,并触发了 oom-killer 造成的。但客户并不接受这个结论,认为是云服务器的异常导致了 cpu 飙高,而 cpu 的升高又导致了 oom 情况的发生。也
23、就是对于 cpu 升高和 oom 谁为因果这件事上,客户和我们持完全相反的态度。下面我们将通过对 oom 时系统日志的解读来说明 cpu 升高和 oom 之间的因果关系。知识点梳理1.预备知识在解读日志之前,我们先回顾一下 linux 内核的内存管理。1.1 几个基本的概念(1)Page页处理器的最小寻址单元是字节或者字,而页是内存的管理单元。(2)Zone区(a)区存在的原因:有些硬件设备只能对特定的内存地址执行 DMA(directmemoryaccess)操作。OOMkiller 是被谁触发的25在一些架构中,实际物理内存是比系统可寻址的虚拟内存要大的,这就导致有些物理内存没有办法被永久
24、的映射在内核的地址空间中。区的划分也是直接以上面两个原因为依据的。(b)区的种类ZONE_DMA这个区包含的 page 可以执行 DMA 操作。这部分区域的大小和 CPU 架构有关,在 x86 架构中,该部分区域大小限制为 16MB。ZONE_DMA32类似于 ZOME_DMA,这个区也包含可以执行 DMA 操作的 page。该区域只存在于 64 位系统中,适合 32 位的设备访问。ZONE_NORMAL这个区包含可以正常映射到地址空间中的 page,或者说这个区包含了除了 DMA 和 HIGHMEM 以外的内存。许多内核操作都仅在这个区域进行。ZONE_HIGHMEM这个区包含的是 high
25、memory,也就是那些不能被永久映射到内核地址空间的页。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 内核分配内存的函数下面是内核分配内存的核心函数之一,它会分
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ECS运维指南 Linux系统诊断 ECS 指南 Linux 系统 诊断
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【Stan****Shan】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【Stan****Shan】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。