一次nginx崩溃事件的实战记录

目录

• 一、事件描述
• 二、检查分析
• 三、处理
• 四、附录
• 总结

一、事件描述

2023年春节复工第一天，项目组同事反馈说业务系统中图像处理代理Nginx服务于1月23日发生崩溃，完成了重启操作，检查nginx的日志有如下报错：

2023/01/23 11:07:07 [crit] 3237#3237: *2253009 pwritev() "/var/cache/nginx/client_temp/0000743846"
failed (28: No space left on device),
client: 10.14.32.3, server: localhost,
request: "POST /Test HTTP/1.1", host: "10.14.32.2:5500"

二、检查分析

1）检查当前文件系统使用情况，未出现分区使用超限情况，应该是nginx重启后缓存释放了；

2）检查nginx配置文件，为对缓存进行额外配置，在编译时配置了缓存目录，如下：

nginx version: nginx/1.16.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
built with OpenSSL 1.1.1k 25 Mar 2021
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-openssl=/home/software/openssl-1.1.1k --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt=‘-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC’ --with-ld-opt=‘-Wl,-z,relro -Wl,-z,now -pie’

配置项说明：执行对应模块时nginx所保留的临时文件
–http-client-body-temp-path=/var/cache/nginx/client_temp
–http-proxy-temp-path=/var/cache/nginx/proxy_temp
–http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
–http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
–http-scgi-temp-path=/var/cache/nginx/scgi_temp

3) 配置Nginx静态文件缓存

##代理cache##proxy_connect_timeout 500;#跟后端服务器连接的超时时间_发起握手等候响应超时时间proxy_read_timeout 600;#连接成功后_等候后端服务器响应的时间_即已经进入后端的排队之中等候处理的过程时间proxy_send_timeout 500;#后端服务器数据回传时间_即在规定时间内后端服务器必须传完所有数据的时长proxy_buffer_size 128k;#代理请求缓存区_这个缓存区间会保存用户的头信息以供Nginx进行规则处理_一般只要能保存下头信息即可proxy_buffers 4 128k;#同上 告诉Nginx保存单个用户的几个Buffer最大用多大空间proxy_busy_buffers_size 256k;#如果系统很忙的时候可以申请更大的proxy_buffers 官方推荐*2proxy_temp_file_write_size 128k;#proxy缓存临时文件的大小proxy_temp_path /usr/local/nginx/temp;#用于指定本地目录用来缓冲较大的代理请求的目录，如果编译配置了--http-proxy-temp-path，也可以采取默认proxy_cache_path /usr/local/nginx/cache levels=1:2 keys_zone=cache_proxy:200m inactive=1d max_size=30g;#设置web缓存区名为cache_proxy,内存缓存空间大小为200M，自动清除超过1天没有被访问过的缓存数据，硬盘缓存空间大小30g;levels=1:2定义目录深度，并且第一层目录为1个字符，第二层目录为2个字符#这里配置的需要缓存的静态资源后缀名location ~* “\.(jpg|jpeg|png|gif|html|css|js|woff2|woff|map)?$” {proxy_pass http://fdfs;proxy_cache cache_proxy;proxy_cache_valid 200 24h; #200状态缓存24小时proxy_cache_valid 302 10m; #302状态缓存10分钟proxy_set_header Host $host;expires -1;add_header X-Cache-Status $upstream_cache_status; #在http头部增加一个字>段显示是否命中缓存}#reload后，当出现cache manager process进程时表明缓存已经建立成功

三、处理

1）针对本次场景，最简单就是迁移目录到存储空间更大的存储上；

2）配置定期清理缓存，nginx缓存虽然可带来吞吐量和性能的提升，但有时候缓存过期后并不会释放，这时我们可借助nginx + ngx_cache_purge 模块，手动清理缓存；

wget http://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gztar -zxvf ngx_cache_purge-2.3.tar.gzcp /sbin/nginx /sbin/nginx.backnginx -V./configure --prefix=/etc/nginx (略) --add-module=/root/app/ngx_cache_purge-2.3 make -j2 #是 make 编译， 不是 make install ，make install 会覆盖原来已经安装好的内容。编译必须没有错误objs/nginx -V  //验证编译完成后，复制到sbin目录下/sbin/nginx -s reload#清理缓存配置location ~ /clear_cache(.*) {     #proxy_cache_purge imooc_cache $host$1$is_args$args;     #删除指定缓存区域cache_one的特定缓存文件$1$is_args$args     proxy_cache_purge cache_one $1$is_args$args;     #运行本机和10.0.16.0/24;网段的机器访问，拒绝其它所有     allow   127.0.0.1;     allow   10.0.16.0/24;     deny  all;}#这样清理某个缓存文件的时候地址前面加上 /clear_cache 即可，比如浏览器访问：http://10.0.16.12:5500/clear_cache//api/index.php

没有缓存返回结果如下：

#示例2：控制满足条件不缓存server{    ……    location /api/ {       set $a 0; #设置初始值       if ( $request_uri ~ /api/noapi/(.*) ){   set $a 1; #如果满足不缓存 设置为1       }       proxy_no_cache $a;     ……    }    location ~ /clear_cache(.*) { allow   all; proxy_cache_purge imooc_cache $host$1$is_args$args;    }}#示例3：add_header      Nginx-Cache     "$upstream_cache_status";proxy_ignore_headers Expires;proxy_ignore_headers Cache-Control;set $nocache 0;# 以 aaa,bbb,ccc 开头的不缓存if ($request_uri ~ ^/(aaa|bbb|ccc)) {    set $nocache 1;}proxy_cache_bypass $nocache;# cookie 里面设置了nocache，或者 参数传值里有aaa，bbb 的不缓存，满足一个即可proxy_no_cache $cookie_nocache $arg_aaa $arg_bbb;#client_body模块配置, nginx对客户端请求缓冲区大小有个默认限制，如果超过了该值（比如在上传大文件时），会报500错误。client_body_buffer_size SIZE // 指定客户端请求体缓冲区大小，如果请求大于该值，会报“500 Internal Server Error”错误。client_body_temp_path	 /var/tmp/nginx DIR  [l1][lve2][lve3] //指定请求体临时文件的存放目录,可有多级。client_max_body_size  SIZE //允许客户端请求的最大单文件字节数，如果请求体大于该值，会报“413 Request Entity Too Large”错误。

3）也可以借助 tmpwatch命令加入定时任务来清理，其实，系统/tmp目录，默认情况下每日会处理一次，原理就是使用了tmpwatch。该命令会在/etc/cron.daily/目录下生成一个tmpwatch文件

yum  install -y tmpwatchcat /etc/cron.daily/tmpwatch#! /bin/shflags=-umc/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \	-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \	-X "/tmp/hsperfdata_*" 10d /tmp   #tmp目录会删除240小时未访问过的文件，它可从指定的目录中递归地搜索并删除指定的目录中一段时间未访问的文件。/usr/sbin/tmpwatch "$flags" 30d /var/tmp  #删除30天前的文件for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do    if [ -d "$d" ]; then	/usr/sbin/tmpwatch "$flags" -f 30d "$d"    fidone#/usr/sbin/tmpwatch -afv 3 /tmp //清除/tmp下三小时以内没有使用的文件,并将结果输出。

四、附录

参考1：https://cloud.tencent.com/developer/article/2048035

参考2：https://www.cnblogs.com/backups/p/nginx4.html

参考3：http://t.zoukankan.com/ecalf-p-4887382.html

总结

到此这篇关于一次nginx崩溃事件的文章就介绍到这了,更多相关nginx崩溃事件内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！