可以看到 低优先级的进程 暂用了比较高的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
- fin_wait1状态
net.ipv4.tcp_orphan_retries=0 发送FIN报文的重试次数，0相当于8
- fin_wait2状态
net.ipv4.tcp_fin_timeout=60 保持在FIN_WAIT_2的状态时间
- 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数量