[toc]
ECS运维指南之Linux系统诊断
目录
Linux启动与登陆问题
-
超详细系统启动与登陆异常排查点
-
grub.conf 文件内容被清空了怎么办
-
巧妙利用 strace 查找丢失的文件
-
小心 PAM 不让你登录
-
CentOS 登录卡住的原因被我找到了
Linux 性能问题
-
找到 Linux 虚机 Load 高的"元凶"
-
OOM killer 是被谁触发的
-
我的服务器内存去哪儿了
-
CPU 占用不高但网络性能很差的一个原因
-
一次 IO 异常捕获过程
Linux 主机网络问题
-
ifdown ifup 命令丢失处理
-
网络不通? strace 二度出手
-
TIME_WAIT & CLOSE_WAIT 的讨论总结
-
一次网络抖动经典案例分析
Linux 系统服务与参数问题
-
4 个 limits 生效的问题
-
6 步排查 ss& netstat 统计结果不一样的原因
-
为什么明明内存很充足但是 java 程序仍申请不到内存
-
请不要忽略 min_free_kbytes 的设置
最后的彩蛋
- 某地区口罩项目架构演进及优化经验
1.Linux启动与登陆问题
说明
Linux 启动与登录问题是 ECS 的高频问题,而往往处理不及时会直接影响到用户业务的正常可持续运行,因此也变成了我们处理问题优先级的重中之重。 在云环境上影响 ECS 启动与登录的因素非常多,镜像、管控、虚拟化、底层硬件、系统与文件异常等等,本文仅从系统与文件本身角度,在大量处理经验的基础上,归纳总结了一些可能会引起系统启动与登录问题的排查点,并给出几个比较常见的典型案例来具体展示和说明。
1.1 超详细系统启动与登陆异常排查点
1.1.1 系统启动异常
-
部分 CentOS 系统启动黑屏,无异常报错的场景,可以 fsck 一下系统盘。
-
根分区空间满,以及 inode 数量耗尽。
-
升级内核或者从老的共享实例迁移到独享规格导致的启动异常。
- 手动注入驱动 (mkinitrd virtio 相关驱动 )。
- 修改 grub 的启动顺序,优先尝试使用老内核启动。
- /boot 目录下面内核的关联文件是否全(下面仅为 demo,不同系统内核版 本文件不一致,部分内核版本 boot 下的 i386 目录也是有用的)。
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-amd64
-
/boot/grub/device.map
里面的 hda 改成 vda。 -
fstab/grub
中的 uuid 不对,可以直接修改为/dev/vda1
这种形式尝试。 数据盘分区异常加载起不来的场景,可以去注释 fstab 所有的行,添加类似下面的启动项尝试, 也适用于系统盘快照创建云盘挂载后,uuid 一致导致的启动异 常,改成非 UUID 的挂载即可。
/dev/vda1 / ext4 defaults 1 1
- 根目录权限 777(部分目录 777)也会导致启动异常,或者 ssh 登陆异常。
- 常见的关键目录缺失,有的是软链,也可以看看对应目录下面的文件数量(文件数量要跟同内核版本或者相差不大的版本对比),简单判断。
/bin /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 ;done
- 影响启动的参数。 如果参数设置不当,是会导致启动异常的,如
/etc/sysctl.conf
以及检查rc.local
的配置,profile
的检查。
vm.nr_hugepages
vm.min_free_kbytes
- CentOS 的 selinux 需要关闭。
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of three two values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
1.1.2 root 登陆异常
-
/etc/passwd
、/etc/shadow
( 用户名 root polikt dbus 等关键用户存在与否,文 件为空,格式乱(dos2unix)。 -
/etc/pam.d
目录下是否有为 空的文件及参数设置是否正常, 如常见的system-auth passwd
。 -
/etc/pam.d
下面所有文件里面涉及的 so 文件,看看文件是否存在,是否为空/ usr/lib64/security
。 -
查
/etc /lib64
、/bin
、/sbin
、/usr/bin
、/usr/sbin
等目录有没有 size 为 0 的文件。 -
/etc/profile
、/etc/profile.d
( 打 印 列 表 )、/etc/bashrc
、/root/.bash_profile
、/root/.bashrc
等涉及登陆环境设置的文件是否异常。 -
注意内核版本,是否存在新老内核,多更换几个内核试下。
-
系统日志也是一个比较重要的检查项(后面会介绍无法登陆怎么检查)。
-
Ubuntu 12.04 登陆异常在
/etc/login.defs
里面配置了错误的ERASECHAR
导致,恢复默认 0177 即可。
configuration error - cannot parse erasechar value
- 输入 root 后直接 login 失败三连,日志如下。
Feb 12 18:18:03 iZbp1cabe6lyx26ikmjie2Z login: FAILED LOGIN 1 FROM tty1 FOR root, Authentication failure
Feb 12 18:18:03 iZbp1cabe6lyx26ikmjie2Z login: FAILED LOGIN 2 FROM tty1 FOR (unknown), Authentication failure
Feb 12 18:18:03 iZbp1cabe6lyx26ikmjieZZ login: FAILED LOGIN SESSION FROM tty1 FOR (unknown), Authentication failure
找个同内核版本的机器对比发现没有 /etc/pam.d/login
。
rpm 包校验一下,确认 login 文件没了,手动创建一个,内容拷贝过来,好了。
[root@iZbp1cabe6lyx26ikmjie2Z pam.d]# rpm -V util-linux
missing c /etc/pam.d/login
[root@iZbp1cabe6lyx26ikmjie2Z 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-l
-
/etc/ssh/sshd_config
相关参数如LoginGraceTime/Allowusers/PermitRootLogin
。 -
问题不好确认的时候, 可以将 shadow 密码字段清空, 看看登陆是否正常, 可以判断是否到密码验证阶段了。 之前有过一篇关于 ssh 问题排查的文档,可参考:ssh问题排查指南
1.1.3 系统登陆不进去了,不挂盘的情况下怎么操作?
上面的检查点很多是需要切换到另外的系统环境下去做检查,比如挂载 LiveCD 或者 chroot 切换;但对于使用 ECS 的用户来说,阿里云暂还未提供实例挂载 ISO 镜像的功能,那么如何进行上面的操作呢?可以借助阿里云新推出的卸载系统盘功能,可以把系统盘卸载掉,作为数据盘挂载到一个新的机器,这样就可以执行上面的检查了。
1.1.4 场景覆盖
1.1.4.1 Linux 系统常见问题诊断覆盖以下场景
- 常用端口是否正确监听(包括ssh端口、80、443)
- 常用端口安全组检测(包括ssh端口、80、443)
tcp_timestamps&tcp_tw_recycle
参数检测- cpu占用高分析
- fstab配置问题
- 软链接缺失
- ssh相关文件权限异常(比如文件权限777)
- selinux启用检测
- hugepage参数检测
- iptables启用检测
/etc/security/limits.conf
配置检查/etc/passwd
等文件格式校验
1.1.4.2 Linux 系统常见启动问题修复覆盖以下场景
- 系统启动-fsck检测修复
- 系统启动-磁盘/inode占满
- 系统启动-系统文件/软链接检测
- 系统启动-根目录/ssh目录777
- 系统启动-fstab/grub校验
- 系统启动-selinux检测
- 系统启动-sysctl内核参数hugepage&minfree检测
- vnc登陆-sshdconfig配置检测
- vnc登陆-passwd/shadow文件格式&用户检测
- vnc登陆-pam.d文件&配置检测
- vnc登陆-相关目录0size文件检测
- vnc登陆-profile/bashrc检测
- vnc登陆-多内核检测
1.1.5 各种脚本
[OS离线修复脚本](https://public-beijing.oss-cn-beijing.aliyuncs.com/oo oos_noak.sh)
1.2 grub.conf 文件内容被清空了怎么办
简介
/boot/grub/grub.conf 被清空,系统启动就进入 grub 状态(CentOS 6.8)。
-
find /boot/grub/stage1
。 显示为(hd0,0)。 -
确认一下内核的具体版本
ls -l /boot
-
手动设置 grub 具体步骤如下
grub> 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 就等于重启整个系统了,刚才的设置就失效了如果没有报错的话,即可成功启动,进入到系统内部后需要继续支持。
-
mount -e remount,rw /
重新挂载分区为读写。 -
service network restart
。 如果提示 eth0 eth1 失败,ifconfig 看不到网卡的话。 -
lsmod |grep net
。 看下 virtio_net 这个驱动有没有,如果没有的话(网卡报错基本都不会有)。 -
insmod /lib/modules/2.6.32-696.3.2.el6.x86_64/kernel/drivers/net/virtio_ net.ko
。 -
重启网络服务,嗨 ~ 网通了。
-
登陆 ssh, 找个同版本系统的 grub.conf,拷贝一份过来, 不然重启之后又进 grub 了。参考文章
1.3 巧妙利用 strace 查找丢失的文件
问题描述
客户反馈系统无法远程登陆,实际系统启动本身就有问题。
根据报错信息来看,是系统内读取 user 有问题,需要挂盘查看。
-
挂盘后 chroot 如下
ihave no name
,这里本身就是有问题了,说明系统内缺少了什么文件导致异常。root@debian:~# chroot/mnt
[ I have no name !@debian / ] # -
strace 跟踪一下 chroot 的过程,看下丢失的文件。
strace -F -ff -t -tt -s 256 -o ch.out chroot /mnt
grep -i "no such" ch.out.pid |grep "so" -
查看对应文件的关系(测试机补图)。
-
确认系统上丢了最终的
libnss_files-2.12.so
,尝试拷贝一个。ifconfig eth1 < 网卡 IP> netmask < 掩码地址 >
route add default gw < 网关 IP> -
此时已经可以上网了,去拷贝一个同版本的文件试试吧。
1.4 小心 PAM 不让你登陆
问题描述
ssh 可以登陆,管理终端无法登陆 root,提示 login in...
先通过 ssh 方式登录系统,查看登录日志是否有异常。
$ cat /var/log/secure
Jun 2 09:26:48 iZbp1begsz1x269nxhtip4Z login: FAILED LOGIN 1 FROM tty1 FOR root,Authentication failure
似乎是 login 验证模块的问题进一步查看对应的配置文件 /etc/pam.d/login
。
$ cat /etc/pam.d/login
#%PAM-1.0
auth required pam_succeed_if.so user != root quiet
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_ securetty.so
auth substack system-auth
auth include postlogin
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open
session required pam_namespace.so
session optional pam_keyinit.so force revoke
session include system-auth
session include postlogin
-session optional pam_ck_connector.so
其中一行的作用为禁止本地登录,可以将其注释掉即可。
auth required pam_succeed_if.so user != root quiet
1.5 CentOS 登陆卡住的原因被我找到了
问题描述
系统登陆卡住,需要 ctrl +c 才能进去,如图。
如果一直等的话,会提示如下截图:
原因
/etc/profile 里面有 source /etc/profile 引起死循环,注释即可。
2.Linux 性能问题
说明
Linux 性能问题的排查和处理一直是系统管理和运维人员的"心头之患", CPU 负载高但找不到消耗大的进程;系统出现 OOM(Out of Memory)只会一味地增大内存容量,而没有很好地理解和分析问题背后产生的根因。而这些都对线上业务的可靠和稳定性提出了挑战。本文将阿里云售后遇到的 较为常见的几个系统性能问题进行展开分析,并给出一些合理的改进和优化方案。
2.1 找到 Linux 虚机 Load 高的"元凶"
问题描述
有客户反馈他们的一台 ECS 周期性地 load 升高,他们的业务流量并没有上升,需要 我们排查是什么原因造成的,是否因为底层异常?
要弄清 Linux 虚机 load 高,我们要搞清楚 Linux top 命令中 Load 的含义。
2.1.1 Load average 的值从何而来
在使用 top 命令检查系统负载的时候,可以看到 Load averages
字段,但是这个字段并不是表示 CPU 的繁忙程度,而是度量系统整体负载。
Load averages 采样是从 /proc/loadavg
中获取的:
0.00 0.01 0.05 1/161 29703
每个值的含义依次为:
lavg_1 (0.00) 1- 分钟平均负载
lavg_5 (0.01) 5- 分钟平均负载
lavg_15(0.05) 15- 分钟平均负载
nr_running (1)
在采样时刻,运行队列的任务的数目,与 /proc/stat 的 procs_running 表示相同意思, 这个数值是当前可运行的内核调度对象(进程,线程)。
nr_threads (161)
在采样时刻,系统中活跃的任务的个数(不包括运行已经结束的任务),即这个数值表示当前存 在系统中的内核可调度对象的数量。
last_pid(29703)
系统最近创建的进程的 PID,包括轻量级进程,即线程。
假设当前有两个 CPU,则每个 CPU 的当前任务数为 0.00/2=0.00
如果你看到 load average 数值是 10, 则表明平均有 10 个进程在运行或等待状态。 有可能系统有很高的负载但是 CPU 使用率却很低,或者负载很低而 CPU 利用率很高,因为这两者没有直接关系。源码中对于这一块的说明
static int loadavg_proc_show(struct seq_file *m,void *v)
{
unsigned long avnrun[3];
get_avenrun(avnrun,FIXED_1/200,0);
seq_printf(m,"%lu.%02lu %lu.%02lu %lu.%02lu %ld/%d %d\n",
LOAD_INT(avnrun[0]),LOAD_FRAC(avnrun[0]),
LOAD_INT(avnrun[1]),LOAD_FRAC(avnrun[1]),
LOAD_INT(avnrun[2]),LOAD_FRAC(avnrun[2]),
nr_running(),nr_threads,
task_active_pid_ns(current)->last_pid);
return 0;
}
Load 的计算函数:
static unsigned long
calc_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.
*/
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;
avenrun[0] = calc_load(avenrun[0],EXP_1,active);
avenrun[1] = calc_load(avenrun[1],EXP_5,active);
avenrun[2] = calc_load(avenrun[2],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) /* 1.0 as fixed-point */
#define LOAD_FREQ (5*HZ+1) /* 5 sec intervals */
#define EXP_1 1884 /* 1/exp(5sec/1min) as fixed-point */
#define EXP_5 2014 /* 1/exp(5sec/5min) */
#define EXP_15 2037 /* 1/exp(5sec/15min) */
#define CALC_LOAD(load,exp,n) \
load *= exp; \
load += n*(FIXED_1-exp); \
load >>= FSHIFT;
从这个函数中可以看到, 内核计算 load 采用的是一种平滑移动的算法,Linux 的系统负载指运行队列的平均长度, 需要注意的是:可运行的进程是指处于运行队列的进程, 不是指正在运行的进程。 即进程的状态是 TASK_RUNNING
或者 TASK_ UNINTERRUPTIBLE
。
Linux 内核定义一个长度为3的双字数组 avenrun,双字的低 11 位用于存放负载的小数部分,高 21 位用于存放整数部分。当进程所耗的 CPU 时间片数超过 CPU 在5秒内能够提供的时间片数时,内核计算上述的三个负载,负载初始化为 0。
假设最近 1、5、15 分钟内的平均负载分别为 load1、load5 和 load15,那么下一个计算时刻到来时,内核通过下面的算式计算负载:
load1 -= load1 - exp(-5 / 60) -+ n (1 - exp(-5 / 60 ))
load5 -= load5 - exp(-5 / 300) + n (1 - exp(-5 / 300))
load15 = load15 exp(-5 / 900) + n (1 - exp(-5 / 900))
其中,exp(x) 为 e 的 x 次幂,n 为当前运行队列的长度。
2.1.2 如何找出系统中 load 高时处于运行队列的进程
通过前 面的讲解, 我们已经明白有可能系统有很高的负载但是 CPU 使用率却很低, 或者负载很低而 CPU 利用率很高,这两者没有直接关系,如何用脚本统计出来处于运行队列的进程呢?
每隔 1s 统计一次:
#!/bin/bash
LANG=C
PATH=/sbin:/usr/sbin:/bin:/usr/bin
interval=1
length=86400
for i in $(seq 1 $(expr ${length} / ${interval}));do
date
LANG=C ps -eTo stat,pid,tid,ppid,comm --no-header | sed -e 's/^ \*//' | perl -nE 'chomp;say if (m!^\S*[RD]+\S*!)'
date
cat /proc/loadavg
echo -e "\n"
sleep ${interval}
done
从统计出来的结果可以看到:
at Jan 20 15:54:12 CST 2018
D 958 958 957 nginx
D 959 959 957 nginx
D 960 960 957 nginx
D 961 961 957 nginx
R 962 962 957 nginx
D 963 963 957 nginx
D 964 964 957 nginx
D 965 965 957 nginx
D 966 966 957 nginx
D 967 967 957 nginx
D 968 968 957 nginx
D 969 969 957 nginx
D 970 970 957 nginx
D 971 971 957 nginx
D 972 972 957 nginx
D 973 973 957 nginx
D 974 974 957 nginx
R 975 975 957 nginx
D 976 976 957 nginx
D 977 977 957 nginx
D 978 978 957 nginx
D 979 979 957 nginx
R 980 980 957 nginx
D 983 983 957 nginx
D 984 984 957 nginx
D 985 985 957 nginx
D 986 986 957 nginx
D 987 987 957 nginx
D 988 988 957 nginx
D 989 989 957 nginx
R 11908 11908 18870 ps
Sat Jan 20 15:54:12 CST 2018
25.76 20.60 19.00 12/404 11912
注:R 代表运行中的队列,D 是不可中断的睡眠进程
在 load 比较高的时候,有大量的 nginx 处于 R 或者 D 状态,他们才是造成 load 上升的元凶,和我们底层的负载确实是没有关系的。
最后也给大家 share 一下查 CPU 使用率比较高的线程小脚本:
#!/bin/bash
LANG=C
PATH=/sbin:/usr/sbin:/bin:/usr/bin
interval=1
length=86400
for i in $(seq 1 $(expr ${length} / ${interval}));do
date
LANG=C ps -eT -o%cpu,pid,tid,ppid,comm | grep -v CPU | sort -n -r | head -20
date
LANG=C cat /proc/loadavg
{ LANG=C ps -eT -o%cpu,pid,tid,ppid,comm | sed -e 's/^ *//' | tr -s ' ' | grep -v CPU | sort -n -r | cut -d ' ' -f 1 | xargs -I{} echo -n "{} + " && echo '0'; } | bc -l
sleep ${interval}
done
fuser -k $0
2.2 OOM killer 是被谁触发的
2.2.1 问题描述
用户发现自己的服务器 CPU 在某一时刻陡然升高,但从监控上看,同一时刻的业务量却并不高,客户怀疑是云服务器有问题,希望技术支持团队予以解决。
经过我们的排查, 发现 cpu 的两次间歇飙高是由于客户系统当时发生了 OOM(out of memory)的情况, 并触发了 oom-killer 造成的。 但客户并不接受这个结论, 认为是云服务器的异常导致了 cpu 飙高,而 cpu 的升高又导致了 oom 情况的发生。也就是对于 cpu 升高和 oom 谁为因果这件事上,客户和我们持完全相反的态度。
下面我们将通过对 oom 时系统日志的解读来说明 cpu 升高和 oom 之间的因果关系。