1. 程式人生 > >nginx報錯accept4() failed (23: Too many open files in system)

nginx報錯accept4() failed (23: Too many open files in system)

今天系統進不去了,用ssh連線伺服器也非常慢,負載均衡顯示後端連線異常,但是通過telnet命令檢視後端埠是正常的,用其他的伺服器telnet這臺伺服器的埠,不通,感覺很奇怪。

首先自己先寫了一個測試的頁面,開啟80埠,但是還是訪問出現問題,於是就查看了一下nginx的error.log日誌檔案,發現有很多像下面這樣的報錯:

這裡寫圖片描述

一看就知道系統對開啟檔案數目做了限制,用下面命令

ulimit -n       #檢視當前使用者的檔案描述符的數目

命令查看了一下,結果顯示檔案開啟數目限制為1024,我們需要讓這個數字更大一些,好讓我們的網站訪問併發更高一些。
  
下面是修改 ulimit 限制數的方法:
1.首先你得修改nginx.conf配置檔案,在定義error.log日誌路徑的位置新增一行

worker_rlimit_nofile 65535;

2.在/etc/bashrc檔案最後面新增下面內容

ulimit -n 65535

3.在/etc/security/limits.conf檔案最後面新增下面內容

* soft nofile 65535
* hard nofile 65535

4.要使 limits.conf 檔案配置生效,必須要確保 pam_limits.so 檔案被加入到啟動檔案中

在/etc/pam.d/login 檔案最後面新增下面內容
session required /lib/security/pam_limits.so

或者也可以在/etc/bashrc後面加上ulimit -n 65535

備註:

* 代表所有使用者,如果想代表某個使用者的話,則 user soft/hard nofile 65535
soft代表軟連線 hard代表硬限制

檢視軟限制數量  ulimit -Sn
檢視硬限制數量  ulimit -Hn

相關推薦

nginxaccept4() failed (23: Too many open files in system)

今天系統進不去了,用ssh連線伺服器也非常慢,負載均衡顯示後端連線異常,但是通過telnet命令檢視後端埠是正常的,用其他的伺服器telnet這臺伺服器的埠,不通,感覺很奇怪。 首先自己先寫了一個測試的頁面,開啟80埠,但是還是訪問出現問題,於是就查看了一下n

Linux下tomcat“java.net.SocketException: Too many open files”--MINA2 錯誤解決

轉載: 因為這個問題,我也是經過三次修改後,才徹底解決該問題。我是遇到了錯誤資訊:“Too many open files”和“No buffer space availabel”,從我的專案上看,兩個問題都是因為使用MINA2時,有些資源沒有關閉造成的。但是出現“To

nginx:accept() failed (24: Too many open files)解決方法

有一臺伺服器訪問量非常高,使用的是nginx ,錯誤日誌不停報以下錯誤: 2010/05/26 08:53:49 [alert] 13576#0: accept() failed (24: Too many open files) 2010/05/26 08:53:49 [alert] 13576#0: a

HTTP FAILED: java.net.SocketException: socket failed: EMFILE (Too many open files

場景: 在使用Retrofit進行大量請求時,出現異常 異常: HTTP FAILED: java.net.SocketException: socket failed: EMFILE (Too many open files)  解決方案: 在建立連結時,不要頻繁

遇到問題----mongodb-----mongorestoretoo many open files甚至mongo服務崩潰

之前執行mongorestore還原mongodb資料庫一直都沒問題,今天還原的時候 報錯too many open files。而且mongo服務經常崩潰需要重啟。問題有兩方面:原因一一個原因是lin

nginx connect() failed (111: Connection refused) while connecting to upstream

連接不上 安裝 tst 端口 修改 rip 網站頁面 導致 file 公司網站搬遷到新服務器後,發現站點訪問不了,network裏面提示502,查看相關的server配置,感覺沒有什麽問題,經過測試發現txt、html、等非php文件能夠直接訪問,也就是php訪問不了,初步

xtrabackup備份MySQL:InnoDB: Error number 24 means 'Too many open files'

locked ulimit virt set mys error linu innodb size xtrabackup備份MySQL報錯:InnoDB: Error number 24 means ‘Too many open files‘ 1.使用xtrabac

Nginx: Too Many Open Files解決方案彙總

在做Nginx高壓力測試時,偶爾某臺WEB的logs丟擲Too Many Open Files,一般從以下3方面調優: 第一:nginx.conf引數規劃與設定 worker_rlimit_nofile :限制單個工作程序開啟的最大檔案數: 首先檢視這個值設定,推薦設定:越

MongoDBToo many open files解決方法

lock 需要 byte pts ssi listen 是不是 sshd line 切記更改完成後要重啟服務才能生效。 最近用戶使用量不斷擴大,突然手機app提示網絡錯誤,經過排查發現是MongoDB數據掛了,先啟動服務,然後查看日誌發現了 2019-05-06T09:51

測並發 Too many open files 問題的解決

ref get http sign pro light 程序 sched pen ulimit -a 查看限制顯示: core file size (blocks, -c) 0 data seg size (kbytes, -d) u

too many open files錯誤

一個 google pid .json 斷開連接 ret 服務 spi end 雖然一直在Linux下開發服務,但是說實話,Linux的東西我基本不懂。這次這個問題的解決,讓我稍微知道一些東西了。 大家都知道,最近我模仿binux大嬸的pyspider的害羞組在線上跑了一

Linux server上too many open files問題

server bsp one 當前 java程序 clas gre work -h 之前測試遇到了"too many open files"的問題。ulimit -Hn 查了下發現server上最大open file數是4096。寫了個簡單的腳本檢測發現進程創建的fd個數在

解決tomcat too many open files問題

限制 spa 8.0 .com nofile tom files 環境 內容 運行環境為 centos7.2 tomcat 為 tomcat 8.0.39.0 ulimit -a ulimit -n 解決的都是 系統的問題 tomcat 報too many

too many open files linux服務器 golang java

add -m 使用 san awk margin 1.0 占用 sim 1. 現象服務的cpu跑滿(golang實現), 並大量報too many open files錯誤.服務使用systemd來運行,部署在阿裏ecs上.2.分析從日誌來看,cpu的上升主要為到達文件數限

Linux允許打開最大文件句柄數的參數調優-"too many open files"問題

方式 描述 pip lsof 允許 出現 有效 stack awk 都知道Linux系統的特性,一切皆文件,所有在運行zabbix這樣的服務時,其中重要的一個調優就是調整linux系統的最大文件句柄數,解決“too many open files”的問題,增大程序運行允許打

linux下tomcat之too many open files

設置 inux roc spa ava linux 執行 java 使用命令 一、問題表象:   程序日誌報錯:java.io.IOException: Too many open files at 二、解決方案:   1、查看系統允許打開的最大文件數:     ca

Linux 檔案開啟過多 (Too many open files)

    如圖是程式運行了一段時間後丟擲來的一個bug, 剛開始看這個bug的時候各種網上找答案, 無外乎教你怎麼改ulimit(就是linux最大開啟檔案數), 當然不是說改這個沒有用, 作為程式開發者來說, 如果程式執行出現了bug則必然是程式的問題

IO異常 Too many open files linux處理

這是因為linux限制了開啟檔案的最大控制代碼數量。 linux預設的開啟檔案數量是1024,我們可以用ulimit -a 來檢視系統資源,例如: 也可以通過ulimit -n 檢視 通過ulimit -n 65535 可以臨時設定。 永久的設定的話需要修改配置檔案: 通過

mina通訊,對於高併發的產生:java.io.IOException: Too many open files(開啟檔案控制代碼過多問題)

起因:由於業務系統有多個定時任務定時訪問銀行端,銀行每天也有大量業務訪問業務系統,都是通過mina通訊,部署在測試環境的系統每過一兩天開啟控制代碼過萬,生產的也是一週左右不重啟業務系統就會爆掉。一開始並不清楚到底是哪方面原因導致控制代碼增長這麼快,因為這是一個老系統,經過多次升級,大量的併發、多執行緒,所以只

kudu tablet server出現異常退出(Too many open files)

某臺tablet server 在停機一斷時間後,再次啟動,某些tablet server出現異常退出,檢視日誌報錯: 開啟資料檔案 報”Too many open files ” 錯誤。 該錯誤明顯開啟的檔案控制代碼數,超過系統設定的ulimit數。 ulim