目錄

• 一、事件描述
• 二、檢查分析
• 三、處理
• 四、附錄
• 總結

一、事件描述

2023年春節(jié)復工第一天，項目組同事反饋說業(yè)務系統(tǒng)中圖像處理代理Nginx服務于1月23日發(fā)生崩潰，完成了重啟操作，檢查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）檢查當前文件系統(tǒng)使用情況，未出現分區(qū)使用超限情況，應該是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’

配置項說明：執(zhí)行對應模塊時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靜態(tài)文件緩存

##代理cache##proxy_connect_timeout 500;#跟后端服務器連接的超時時間_發(fā)起握手等候響應超時時間proxy_read_timeout 600;#連接成功后_等候后端服務器響應的時間_即已經進入后端的排隊之中等候處理的過程時間proxy_send_timeout 500;#后端服務器數據回傳時間_即在規(guī)定時間內后端服務器必須傳完所有數據的時長proxy_buffer_size 128k;#代理請求緩存區(qū)_這個緩存區(qū)間會保存用戶的頭信息以供Nginx進行規(guī)則處理_一般只要能保存下頭信息即可proxy_buffers 4 128k;#同上 告訴Nginx保存單個用戶的幾個Buffer最大用多大空間proxy_busy_buffers_size 256k;#如果系統(tǒng)很忙的時候可以申請更大的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緩存區(qū)名為cache_proxy,內存緩存空間大小為200M，自動清除超過1天沒有被訪問過的緩存數據，硬盤緩存空間大小30g;levels=1:2定義目錄深度，并且第一層目錄為1個字符，第二層目錄為2個字符#這里配置的需要緩存的靜態(tài)資源后綴名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狀態(tài)緩存24小時proxy_cache_valid 302 10m; #302狀態(tài)緩存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;     #刪除指定緩存區(qū)域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對客戶端請求緩沖區(qū)大小有個默認限制，如果超過了該值（比如在上傳大文件時），會報500錯誤。client_body_buffer_size SIZE // 指定客戶端請求體緩沖區(qū)大小，如果請求大于該值，會報“500 Internal Server Error”錯誤。client_body_temp_path	 /var/tmp/nginx DIR  [l1][lve2][lve3] //指定請求體臨時文件的存放目錄,可有多級。client_max_body_size  SIZE //允許客戶端請求的最大單文件字節(jié)數，如果請求體大于該值，會報“413 Request Entity Too Large”錯誤。

3）也可以借助 tmpwatch命令加入定時任務來清理，其實，系統(tǒng)/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崩潰事件內容請搜索以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持！