核心引數限制-總限制
/etc/sysctl.conflimit限制-每個使用者的最大值限制file-max 是設定系統所有程序一共可以開啟的檔案數量,預設系統使用檔案開啟數為系統記憶體的10% 。
nr_open 是單個程序可分配的最大檔案數，這個值通常預設是 1024*1024 (1048576)。
/etc/security/limits.d/90-nproc.confsoft 軟限制值就是程式的最大開啟檔案數限值
hard 硬限制值就是限制使用者的軟限制值所能調整的最大上限
* soft nofile 2048000
* hard nofile 2048000
核心配置與limit需要注意各個限制維度
** 檔案開啟數可以設定200w左右，一般情況是沒有到限制資料，就會把系統的記憶體和cpu資源吃完了**
內容摘自會，乙個listening或established狀態的網路連線會占用乙個開啟檔案數。所以，在web應用的訪問量稍大時，如果是單程序程式的話，即便不算應用本身開啟的常規檔案，由於網路連線數多，也會導致開啟檔案數輕輕鬆鬆就超過1024個。所以，對於centos/redhat 6這種老系統來說，由於預設值比較小，所以是很有必要調整的。
根據main文件中的說法，乙個開啟檔案可能是乙個常規檔案、乙個目錄、乙個塊裝置檔案、乙個字元裝置檔案、乙個正在執行的檔案引用、乙個庫、乙個流或乙個網路檔案(網路socket，nfs檔案或unix socket)。所以，網路連線也算。我估計，這可能是因為在程式中，要訪問這些物件時，都有點類似於訪問檔案那樣，需要開啟。
是。因為ulimit限值是跟你當前的shell繫結的，你在哪個shell裡面啟動了程式，如果程式本身沒有修改ulimit限值的話，程式就會繼承那個shell環境的ulimit限值。所以，通常修改limits.conf檔案中的限值後，要退出當前shell並重新登入，讓新的限值生效，再重啟你的程式。
當然，正如我前面所說，要檢視乙個程序執行後實際生效的ulimit限值，使用cat /proc/pid/limits命令。如果程式自身有修改ulimit限值的話，你就會看到它的實際限值與你當前shell環境的限值是不一樣的。
這是錯誤的。事實上來說，limits.conf檔案中的限值對通過啟動指令碼來啟動的程式並不生效。比如，nginx程式有乙個啟動指令碼/etc/init.d/nginx並設定了開機啟動。那麼，即便你修改了limits.conf檔案中的限值，當伺服器重啟後，nginx程式自動啟動了，它的ulimit限值將還會是預設值，而不會是你設定的值。當然，如果你此時登入進系統，並通過nginx開機啟動指令碼重啟了nginx程式，nginx程序的ulimit限值自然會變為你在limits.conf檔案中設定的限值。
關於這個問題的原因，我也沒有找到什麼權威的資料說明，但我估計可能是這樣的。以centos 6系統為例，因為系統啟動時，系統中的所有程序都是由第一支程式/sbin/init帶起的。而limits.conf檔案中的限值對/sbin/init程式並不生效，所以/sbin/init程序的ulimit限值仍然是預設值。這就導致它所啟動的所有子程序，即系統中的所有其它程式，都繼承它的ulimit限值，即預設值。
對於這個問題，我想到的有兩種解決辦法。
第一種，是在程式的啟動指令碼裡面最前面加上ulimit修改命令：
[root@gw ~]# vim /etc/init.d/mysql
#!/bin/sh
ulimit -n 65535
linux下檢視檔案開啟數
一 檢視資源限定 ulimit a 檢視系統目前資源限制的設定。二 修改資源限定 linux 開啟檔案控制代碼時可能出現 too many open files 的提示，可以修改linux的最大檔案控制代碼數限制 1 ulimit n 65535 在當前session有效，使用者退出或者系統重新後恢...
Linux最大檔案開啟數
在linux下有時會遇到socket file can t open so many files的問題。其實linux是有檔案控制代碼限制的，而且linux預設一般都是1024 阿里雲主機預設是65535 在生產環境中很容易到達這個值，因此這裡就會成為系統的瓶頸。使用ulimit a 或者 ulim...
Linux最大檔案開啟數
linux作業系統對乙個程序開啟的檔案控制代碼數量的限制 也包含開啟的套接字數量 臨時生效 ulimit shn 10000 其實ulimit 命令身是分軟限制和硬限制，加 h就是硬限制，加 s就是軟限制。預設顯示的是軟限制，如果執行ulimit 命令修改時沒有加上 h或 s，就是兩個引數一起改變。...