基于tmpfs 的nginx cache 优化

昨天简单说明了下基于tmpfs 的nginx proxy_cache 优化，今天整体说明下

参考图

 

 

流程说明

• 修改之前的
  对于nginx 使用了多级处理，ingress （也是基于nignx，openresty），对于服务的ib 也是就有nginx （openresty），同时lb 也包含一部分静态资源的能力
  service 包含了不同类型的服务（图片服务，接口服务，单体服务，静态资源服务），原有的cache 是基于本地磁盘的，在大量压测的时候发现了一些问题
  iowait 会有一些高，同时基于bcc-tools 的xfsslow 进行分析，发现有不少慢io 操作，主要是图片缩略图服务（里边会包含cpu 、内存、io 的处理）实际上对于
  缩略图部分已经了一些cache （磁盘），原有部分ingress 入口实际上也基于了proxy_cache 对于上游nginx proxy 的服务进行了cache，发现效果还是不太好
• 调整
  以前是基于磁盘的cache的，通过统计发现各个服务依赖的资源并不是很多（当前cache 的磁盘文件数据，与实际节点的内存还是差异不少的）而且内存使用
  率并不是很大（占用不到1/10） 而且考虑到实际我们的节点也不少，总体内存是大于当前服务占用的磁盘空间，所以基于简单平均，每个节点会挂载均分大小的
  tmpfs 文件系统，对于图片缩略图为了提供性能，同时也添加了内存文件系统（也是tmpfs）这样整体就包含了ingress， nginx， imageproxy 缩略图多级cache
  可以参考上图

问题

实际上nginx 官方也介绍过，tmpfs 毕竟是单机的，而且受限于内存，同时因为数据不是共享的，会分散在多个nginx 节点中数据会有冗余，造成内存浪费，当时还有
就是tmpfs 的易失性（重启数据会丢失），但是如果进行了多级处理对于性能的提升还是不错的

一些nginx 配置调整参考

参考配置
开启多线程模式+支持woker 进程抢占，woker 进程多connection 创建

 

user root;

worker_processes  auto;

worker_cpu_affinity auto;

error_log logs/error.log error;

events {

    use epoll;

    worker_connections  655360;

    accept_mutex off;

    multi_accept on;

    worker_aio_requests 1024; 

}

http {

    include common/*.conf;

    include app/*.conf;

    aio threads;

    aio_write on;

}

 

 

参考资料

https://www.cnblogs.com/rongfengliang/p/17146438.html
https://www.kernel.org/doc/html/v5.18/filesystems/tmpfs.html
https://en.wikipedia.org/wiki/Tmpfs
https://www.nginx.com/blog/cache-placement-strategies-nginx-plus/
https://github.com/iovisor/bcc
https://github.com/willnorris/imageproxy