linux运维与实践

-3、怎么理解下面的三个内核参数

[root@k8s-master kubernetes]# sysctl -a 2>&1 | grep -i keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200

创建socket时如果开启了SO_KEEPALIVE，那么如果一个连续7200s内都没有数据交换，tcp将发送探测报文，如果对端返回reset，那么自身关闭连接，如果对端无响应，那么每隔75s发送一次探测报文尝试获取回应，最多尝试9次后关闭连接。上面的参数时全局设置，可以在创建socket时针对每一个连接单独配置。

 

-2、怎么理解top命令输出中的关于内存的几个子段？

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                      
32646 nfsnobo+  20   0  674024 351152   8588 S  5.7 18.7 347:56.05 prometheus                                                                                                   
 3032 root      20   0  975900 230732   1800 S  0.0 12.3 111:03.40 docker-containe                                                                                              
25336 root      20   0  895848  83312  12624 S  3.7  4.4   1389:00 kubelet                                                                                                      
 5821 1001      20   0 1681844  72352    980 S  0.3  3.8  13:01.14 java                                                                                                         
 5685 1001      20   0 1681844  68212   1260 S  0.0  3.6  12:56.81 java      


VIRT 是进程虚拟内存的大小，只要是进程申请过的内存，即便还没有真正分配物理内存，也会计算在内。(进程虚拟内存地址空间大小)
RES 是常驻内存的大小，也就是进程实际使用的物理内存大小，但不包括 Swap 和共享内存。
SHR 是共享内存的大小，比如与其他进程共同使用的共享内存、加载的动态链接库以及程序的代码段等。
%MEM 是进程使用物理内存占系统总内存的百分比。

统计所有进程的物理内存使用量，应该使用/proc/< pid >/smaps中的PSS计算(包含进程的每一个内存映射的统计值,并把共享的内存进行了平均分摊)
参考命令：awk '/Pss:/{ sum += $2 } END { print sum }' /proc/{PID}/smaps

 

-1、free -h命令输出中的buff/cache是什么意思？

man free
DESCRIPTION
       free  displays  the  total  amount of free and used physical and swap memory in the system, as well as the buffers and caches used by the kernel. The information is
       gathered by parsing /proc/meminfo. The displayed columns are:

       total  Total installed memory (MemTotal and SwapTotal in /proc/meminfo)

       used   Used memory (calculated as total - free - buffers - cache)

       free   Unused memory (MemFree and SwapFree in /proc/meminfo)

       shared Memory used (mostly) by tmpfs (Shmem in /proc/meminfo, available on kernels 2.6.32, displayed as zero if not available)

       buffers
              Memory used by kernel buffers (Buffers in /proc/meminfo)

       cache  Memory used by the page cache and slabs (Cached and Slab in /proc/meminfo)

       buff/cache
              Sum of buffers and cache

       available
              Estimation of how much memory is available for starting new applications, without swapping. Unlike the data provided by the cache or free fields, this  field
              takes  into  account  page  cache  and also that not all reclaimable memory slabs will be reclaimed due to items being in use (MemAvailable in /proc/meminfo,
              available on kernels 3.14, emulated on kernels 2.6.27+, otherwise the same as free)

Buffers 是对原始磁盘块的临时存储，也就是用来缓存磁盘的数据，通常不会特别大（20MB 左右）。这样，内核就可以把分散的读写集中起来，统一优化磁盘的读写，比如可以把多次小的读写合并成单次大的读写等等。（比如存储系统）
Cached 是从磁盘读写文件的页缓存，也就是用来缓存从文件读写的数据。这样，下次访问这些文件数据时，就可以直接从内存中快速获取或写入，而不需要再次访问缓慢的磁盘。

 

0、每一个OS线程都有一个固定大小的内存块(一般会是2MB)来做栈，可以通过ulimit -a查看。这个栈会用来存储当前正在被调用或挂起(指在调用其它函数时)的函数的内部变量。这个固定大小的栈同时很大又很小。因为2MB的栈对于一个小小的goroutine来说是很大的内存浪费，而对于一些复杂的任务（如深度嵌套的递归）来说又显得太小。因此，Go语言做了它自己的『线程』。

 

1、容器云计算节点负载值高，通过top可以看到Load Average：70.1  71.3  70.8，虚拟机有8个cpu：

cpu使用率高导致（R状态）？

同时在top中观察一段时间，消耗cpu最高的为docker进程，峰值为125%左右，应该也不算高。top的cpu的统计数据中us、sy、wa都不高，id值为95，说明负载高的原因并不是cpu使用率高导致的。

不可中断状态的进程数过多导致（D状态）？

通过 ps aux | awk '{if($8 ~ /D/) print $0}' 可以找出状态为D（Disk Sleep)，即不可中断状态的进程，发现存在10几个nmon进程，确认这些进程是监控进程后，通过 ps aux | awk '{if($8 ~ /D/) print $2}' | xargs kill -9强制杀掉这些进程，负载逐渐下降至2左右。

 

 （D状态进程即不可中断状态的进程应该是不响应异步信号kill才对，为什么kill会生效呢？）

mpstat -P ALL可以看到所有cpu的使用情况，包括iowait

 

2、虚拟机执行 df -h无响应，通过strace df，发现卡在一个nfs的挂载点上面，这个是临时挂载的，umount问题解决。

处于D（uninterruptiblesleep）状态的进程通常是在等待IO，比如磁盘IO，网络IO，其他外设IO，如果进程正在等待的IO在较长的时间内都没有响应，那么就很会不幸地被ps看到了，同时也就意味着很有可能有IO出了问题，可能是外设本身出了故障，也可能是比如挂载的远程文件系统已经不可访问了（由down掉的NFS服务器引起的D状态），上述问题正是由这个远程NFS服务器不可用导致的。

 

3、在umount某个文件系统时，如果出现device is busy的提示，可以通过 lsof | grep {挂载点} 查看有哪些进程正在占用挂载点中的文件的文件句柄，这些进程处理完之后就可以正常umount。

 

 4、使用 cat /dev/null > 方式删除文件而不用 rm，因为用 rm 删除的文件，进程可能不会释放文件，空间也就不会释放。

 

5、常见的exit code退出状态码含义https://imroc.io/kubernetes-troubleshooting-guide/zh/debug/analysis-exitcode.html

 

6、linux内核中的conntrack模块的作用，在nat中的作用可以先这么简单理解：有A B C三台机器作为一个局域网，均具有私网地址，其中A还具有公网地址，那么B访问外网如xxx.com时都会进行SNAT将A的公网作为源ip与xxx.com建立tcp链接，那么链接建立之后xxx.com的回包中目的ip地址是A的公网地址，正式conntrack表中维护了这个snat信息，才能正确的将包再转发到B中。

参看链接：

https://www.cnblogs.com/embedded-linux/p/7043569.html

 

7、获取脚本名称

filename=“/usr/bin/iptables”
basename ${filename}

or


${0##*/}

 

8、linux中软链接和硬链接的区别

echo conttent > file1

为文件file1创建硬链接
ln file1 file2

[root@k8s-master test]# ls -ali
total 24
20141 drwxr-xr-x.  2 root root  4096 Jul  9 21:34 .
 8193 drwxrwxrwt. 11 root root 12288 Jul  9 21:34 ..
20151 -rw-r--r--.  2 root root     8 Jul  9 21:33 file1
20151 -rw-r--r--.  2 root root     8 Jul  9 21:33 file2

可以看到file1和file2的inode是一样的，这两个dentry指向同一个inode(文件)

为文件file1创建软链接
ln -s file1 file3

[root@k8s-master test]# ls -ail
total 20
20141 drwxr-xr-x.  2 root root  4096 Jul  9 21:46 .
 8193 drwxrwxrwt. 11 root root 12288 Jul  9 21:45 ..
20151 -rw-r--r--.  1 root root     8 Jul  9 21:33 file1
20152 lrwxrwxrwx.  1 root root     5 Jul  9 21:45 file3 -> file1

删除file1,file3会依旧指向file1，但会变成dangling link
[root@k8s-master test]# ls -ali
total 16
20141 drwxr-xr-x.  2 root root  4096 Jul  9 21:53 .
 8193 drwxrwxrwt. 11 root root 12288 Jul  9 21:53 ..
20152 lrwxrwxrwx.  1 root root     5 Jul  9 21:45 file3 -> file1
[root@k8s-master test]# cat file3 
cat: file3: No such file or directory
[root@k8s-master test]# 


可见file1和file3的inode不同，软链接文件file3是一种特殊的文件

区别：

软链接可以链接文件和目录、可以跨文件系统进行链接
硬链接只能链接文件，不能跨文件系统链接