unix使用整数来追踪打开的文件，我们把这个整数叫做文件描述符(file descriptors)运行中的进程可以查看/proc/pid/fd来看他占用的文件描述符，当然也有更简单的方法，使用lsof指令就可以查看与文件有关的信息-a file:查看文件占用（-a加不加都行[root@master 8432]# lsof -a /var/lib/docker/volumes/metadata.db COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dockerd 8432 root mem-W REG 253,1 ...

describe k8s pod的时候，会看到一行QoS Class，这玩意对于k8s里的应用，就好像oom_score_adj之于linux应用，决定着当资源紧张的时候，pod被驱逐的优先顺序k8s不想oomscore一样可以直接通过调节数值来定义，他分成固定的三类：GuaranteedBurstableBestEffort决定一个应用的QoS Class是哪一类的，是他们对资源限制的配置，当你给应用配置了cpu及内存的request和limit并且两者值相等的时候，他的种类为Guaranteed，当你至少配置了一项cpu或者内存的request的时候，他的种类为Burstable，当...

ps -ef | grep找出应用pidecho -1000 > /proc/$pid/oom_score_adjoom_score_adj是内核给应用打的一个分数，区间在-1000~1000，越大越优先被杀，-1000代表禁止oom杀该进程，可以用来保护一些重要的程序，比如ssh，免得服务挂了后连登录都登不进去当发生oom的时候，dmesg打印出的消息里面可以看到被杀的进程的oom分数核心进程：咦，内核，你手里拿的什么内核(举起oom)：是一会要用到的神奇妙妙工具

供应商反应测试环境里面自己的java应用频繁重启，排查之kubectl describe pod，看了下重启了4次，Terminated，退出code 137看到137基本心里有数了，登录top看了下，java进程吃了7个g内存，free看了下宿主机可用内存所剩无几，ps -ef看下java启动命令，-XX后面跟着一串按比例吃资源的参数查看yaml，果然没设置资源上限，java进程直接按宿主条件去要资源，后面又持续新增内存要求，宿主机内存不够把他给砍了配置4g资源上限后重启，对比监控数据可以看到，原本无上限启动后就占了5g，设置上限后重启应用只占了1g多，效果明显使用java -XX:+...

https://help.aliyun.com/document_detail/412618.html?spm=5176.2020520152.help.19.740b16ddtBrgBC#section-elq-kxx-bzx状态含义常见原因Pendingpod无法被调度到node上污点、容忍问题资源/依赖不足端口耗尽ImagePullBackOff已调度，无法拉取镜像镜像信息不正确镜像仓库网络不通CrashLoopBackOff应用程序有问题查看日志检查应用检查容器健康检查的配置Completed应用已执行完毕没有持续运行的后台程序、或程序已执行完毕Terminatingpod正在删...