11-进程运行机制及状态切换
一. 进程使用内存问题
1 内存泄漏：Memory Leak
指程序中用malloc或new申请了一块内存，但是没有用free或delete将内存释放，导致这块内存一直处于占用状态
2 内存溢出：Memory Overflow
指程序申请了10M的空间，但是在这个空间写入10M以上字节的数据，就是溢出,类似红杏出墙，nginx 申请root用户内存rm -rf /
3 内存不足：OOM
OOM 即 Out Of Memory，“内存用完了”,在情况在java程序中比较常见。系统会选一个进程将之杀死，
在日志messages中看到类似下面的提示
X X 10:20:30 kernel: Out of memory: Kill process 9527 (java) score 88 or sacrifice child
当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时，就会抛出这个
error，因为这个问题已经严重到不足以被应用处理）。
原因：
给应用分配内存太少：比如虚拟机本身可使用的内存（一般通过启动时的VM参数指定）太少。
应用用的太多，并且用完没释放，浪费了。此时就会造成内存泄露或者内存溢出。
使用的解决办法：
1，限制java进程的max heap，并且降低java程序的worker数量，从而降低内存使用
2，给系统增加swap空间
[root@centos7 ~]# cat /proc/sys/vm/overcommit_memory 0
说明：
Linux默认是允许memory overcommit的，只要你来申请内存我就给你，寄希望于进程实际上用不到那么多内存，但万一用到那么多了呢？Linux设计了一个OOM killer机制挑选一个进程出来杀死，以腾出部分内存，如果还不够就继续。也可通过设置内核参数 vm.panic_on_oom 使得发生OOM时自动重启系统。这都是有风险的机制，重启有可能造成业务中断，杀死进程也有可能导致业务中断。所以Linux 2.6之后允许通过内核参数 vm.overcommit_memory 禁止memory overcommit。
vm.overcommit_memory 接受三种取值:
0 – Heuristic overcommit handling. 这是缺省值，它允许overcommit，但过于明目张胆的overcommit会被拒绝，比如malloc一次性申请的内存大小就超过了系统总内存。Heuristic的意思是“试探式的”，内核利用某种算法猜测你的内存申请是否合理，它认为不合理就会拒绝overcommit。 1 – Always overcommit. 允许overcommit，对内存申请来者不拒。内核执行无内存过量使用处理。使用这个设置会增大内存超载的可能性，但也可以增强大量使用内存任务的性能。 2 – Don’t overcommit. 禁止overcommit。 内存拒绝等于或者大于总可用 swap 大小以及overcommit_ratio 指定的物理 RAM 比例的内存请求。如果希望减小内存过度使用的风险，这个设置就是最好的。
设置内核参数（不推荐），不允许内存申请过量：
echo 2 > /proc/sys/vm/overcommit_memory echo 80 > /proc/sys/vm/overcommit_ratio echo 2 > /proc/sys/vm/panic_on_oom
vm.overcommit_memory = 1 redis,部署redis,申请内存来着不拒，增强大量使用内存任务的性能
net.core.somaxconn = 16384 三次握手 server 端 ESTABLISHED状态到 还没被 accept() 系统调用取走 之间是 accept queue 队列
进程状态
进程的基本状态
创建状态：进程在创建时需要申请一个空白PCB(process control block进程控制块)，向其中填写控制和管理进程的信息，完成资源分配。如果创建工作无法完成，比如资源无法满足，就无法被调度运行，把此时进程所处状态。
就绪状态：进程已准备好，已分配到所需资源，只要分配到CPU就能够立即运行
执行状态：进程处于就绪状态被调度后，进程进入执行状态
阻塞状态：正在执行的进程由于某些事件（I/O请求，申请缓存区失败）而暂时无法运行，进程受到阻塞。在满足请求时进入就绪状态等待系统调用
终止状态：进程结束，或出现错误，或被系统终止，进入终止状态。无法再执行
VSZ: Virtual memory SiZe，虚拟内存集，线性内存
RSS: ReSident Size, 常驻内存集
STAT：进程状态
R：running 运行态
在该状态的进程才可能在CPU上运行。而同一时刻可能有多个进程处于可执行状态
S: interruptable sleeping 睡眠态可中断
处于这个状态的进程因为等待某某事件的发生（比如等待socket连接、等待信号量），而被挂起。这些进程的task_struct结构被放入对应事件的等待队列中。当这些事件发生时（由外部中断触发、或由其他进程触发），对应的等待队列中的一个或多个进程将被唤醒，CPU就这么一两个，进程动辄几十上百个，如果不是绝大多数进程都在睡眠，CPU又怎么响应得过来
D: uninterruptable sleeping 睡眠态不可中断
kill -9竟然杀不死，很少见这个状态
T: stopped 停止态
暂停于内存，但不会被调度，除非手动启动
Z: zombie
僵尸态，结束进程，父进程结束前，子进程不关闭，杀死父进程可以关闭僵死态的子进程
[root@centos7 ~]# ps aux|grep nginx root 945 0.0 0.0 28224 672 ? Ss 07:22 0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf nginx 947 0.0 0.7 55756 29176 ? S 07:22 0:05 nginx: worker process nginx 948 0.0 0.7 55756 29176 ? S 07:22 0:05 nginx: worker process [root@centos7 ~]# ps aux|grep nginx root 945 0.0 0.0 28224 672 ? Ss 07:22 0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf nginx 947 0.0 0.7 55756 29176 ? R 07:22 0:05 nginx: worker process nginx 948 0.0 0.7 55756 29176 ? R 07:22 0:05 nginx: worker process
nginx 947 0.2 0.7 55756 29176 ? R 07:22 0:33 nginx: worker process nginx 948 0.2 0.7 55756 29176 ? S 07:22 0:33 nginx: worker process
构建僵尸态
kill -19 3799 root 3799 0.0 0.1 8440 5444 pts/1 Ts 00:19 0:00 -bash
kill tail进程 僵尸态 root@ubuntu2004:~# ps aux |grep Z USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 8685 0.0 0.0 0 0 pts/1 Z+ 03:37 0:00 [tail] <defunct>
僵尸态进程怎么处理？
kill -18 3799
kill 父进程救活父进程或重启机器
孤儿进程
如果在子进程在退出前，父进程先退出,这时子进程将成为孤儿进程，因为它的父进程已经死了。孤儿进程会被PID=1的systemd进程收养，成为systemd的子进程.
注意，孤儿进程还会继续运行，而不会随父进程退出而终止，只不过其父进程发生了改变。
systemd(1)─sshd(930)───sshd(2892)─┬─bash(9128)───screen(9263)───screen(9264)───bash(9265)───ping(9273)
新爹
systemd(1)├─screen(9264)───bash(9265)───ping(9273)
#利用()实现当前shell的子进程,&实现后台执行,子进程结束后
(sleep 100 &) root@ubuntu2004:~# pstree -p|grep sleep #孤儿进程 |-sleep(9465
root@ubuntu2004:~# (sleep 100 )& [1] 9417
root@ubuntu2004:~# pstree -s `pidof sleep` 正常
systemd───sshd───sshd───bash───sleep
