nice-ni 耗光cpu

可以看到 低优先级的进程 暂用了比较高的CPU时间。

top 命令中可以看到 NI 为19， 其优先级最低 但是使用cpu 最高。

说明这个进程需要经行优化了，

通过gdb 发现此进程一直都在处理报文，写缓存。

由于使用了dpdk， 此进程用来接收dpdk的报文数据解析。此时流量大约3-5g。

报文量多。此处逻辑 需要调整。以及进程优先级也需要调整

顺便说一说 http server端的优化

• TCP的keepalive

　　　　维护与client的防火墙的活跃网络包
　　　　检测实际断掉的连接

　　　　net.ipv4.tcp_keepalive_time=7200 发送心跳周期

　　　　net.ipv4.tcp_keepalive_intvl=75 探测包发送间隔
　　　　net.ipv4.tcp_keepalive_probes=9 探测包重试次数

• 减少关闭连接的timewait

1. 　　fin_wait1状态

　　　　net.ipv4.tcp_orphan_retries=0 发送FIN报文的重试次数，0相当于8

1. 　　fin_wait2状态

　　　　net.ipv4.tcp_fin_timeout=60 保持在FIN_WAIT_2的状态时间

1. time_wait状态

　　　　net.ipv4.tcp_tw_reuse=1 开启后client端仍可以使用处于TIME_WAIT的端口，由于时间戳的存在，操作系统可以设置net.ipv4.tcp_timestamps=1拒绝迟到的报文

　　　　net.ipv4.tcp_max_tw_buckets TIME_WAIT的连接数量
　　　　net.ipv4.tcp_tw_recycle=0 开启后client和server都可以使用TIME_WAIT的端口，无法避免报文延迟和重复造成的混乱

lingering延迟关闭TCP连接

当server主动关闭连接的时候，调用close状态，当client仍发送数据到缓冲区，服务仍会给client发送RST包关闭连接，导致了client收到了RST而忽略了http的response

server端的配置

lingering_close off为关闭，on为由server判断是否使用 
lingering_time 30s 功能启用时，最长的读取用户内容的时长，到达后立刻关闭
lingering_timeout 5s 检测client是否仍有请求内容到达，若超时后扔没有数据到达，则立刻关闭连接
读写超时通过RST立刻释放连接，代替四次握手

• 应用层协议优化

TLS和SSL握手优化的ssl_session_cache off

off为不使用，http server告诉client不使用
none为不使用
builtin为使用，当一个client两次连接都命中一个worker才生效
shared:name:size为使用，定义共享内存
Ticket会话验证票证

http server 会将会话的session作为ticket加密发送给client，client下次发起TLS连接的带上ticket，由nginx解密验证恢复会话，但是这样破换了nginx的TSL/SSL的安全机制，有安全风险，需要经常更换

• HTTP长连接

可以减少握手次数，减少并发连接消耗服务器资源，降低TCP拥塞控制

• 压缩包体

google pertools分析nginx

gpertools

• 文本展示 pprof --text
• 图形展示 pprof --pdf 需要依赖graphviz和libunwind

文本结果

2 0.9% 51.3% 166 73.5% ngx_epoll_process_event
1 0.4% 96.5%   2  0.9% ngx_open_and_stat_file

每统计周期为10ms

• 当前函数执行总共花费的统计周期
• 当前函数执行时间的百分比
• 当前函数及其之前函数执行时间的百分比
• 当前函数及其所调用函数消耗的统计周期总和
• 当前函数及其所调用函数执行时间总和的百分比
• 函数名

stub_status模块监控

• Active connections 当前client与Nginx间的TCP连接数，等于Reading+Writing+Waiting
• accept 从nginx启动，与client建立的连接数
• handler 从nginx启动，处理过的client连接数，如果没有超出worker_connections，应该是与accept相同
• requests 从nginx启动，处理过的client请求数，由于keepalive，所以会大于handler
• Reading 正在读取HTTP请求头的连接总数，接收完Reading就是Writing状态了
• Writing 正在向Client发送响应的连接总数
• Waiting 当前空闲的keepalive数量