linux 開啟檔案控制代碼數
#define NR_OPEN1024
只有root可以用ulimit修改這個值,象這樣:
su
ulimit -n 8096
su urname
runprog solaris
nfile則是表示所有程序開啟的最大檔案數的總數限制。
---------------------------------
----------結論-------------------- 前兩句是修改引數 最後一句是生效 // 檔案數 echo "fs.file-max = 65535" >> /etc/sysctl.conf // tcp 連線數 echo "* - nofile 65535" >> /etc/security/limits.conf sysctl -p當前設定最大開啟檔案數可以通過如下命令檢視。
ulimit -n
這個數字說明了一個普通使用者能夠在一個單獨會話中所能開啟最大的檔案數目。注意。如果是root,以下操作不能使ulimit -n的輸出增加。因為使用者root使用者不受這個ulimit限制。只有普通使用者才會受這個限制。
為了提高最大開啟檔案數到預設值1024以上, 需要在系統上修改2個地方。 在這個案例中, 我們將最大開啟檔案數增加到2048。 所有的步驟需要root使用者操作。 普通使用者需要重新登入才能使設定生效。
1. 按照最大開啟檔案數量的需求設定系統, 並且通過檢查/proc/sys/fs/file-max檔案來確認最大開啟檔案數已經被正確設定。
# cat /proc/sys/fs/file-max
如果設定值太小, 修改檔案/etc/sysctl.conf的變數到合適的值。 這樣會在每次重啟之後生效。 如果設定值夠大,跳過下步。
# echo 2048 > /proc/sys/fs/file-max 編輯檔案/etc/sysctl.conf,插入下行。 fs.file-max = 2048
2. 在/etc/security/limits.conf檔案中設定最大開啟檔案數, 下面是一行提示:
#<domain> <type> <item> <value> 新增如下這行。
* - nofile 2048
這行設定了每個使用者的預設開啟檔案數為2048。 注意"nofile"項有兩個可能的限制措施。就是<type>項下的hard和soft。 要使修改過得最大開啟檔案數生效,必須對這兩種限制進行設定。 如果使用"-"字元設定<type>, 則hard和soft設定會同時被設定。
硬限制表明soft限制中所能設定的最大值。 soft限制指的是當前系統生效的設定值。 hard限制值可以被普通使用者降低。但是不能增加。 soft限制不能設定的比hard限制更高。 只有root使用者才能夠增加hard限制值。
當增加檔案限制描述,可以簡單的把當前值雙倍。 例子如下, 如果你要提高預設值1024, 最好提高到2048, 如果還要繼續增加, 就需要設定成4096。
3.Add the following line to the /etc/pam.d/login and /etc/pam.d/xdm file, if it does not already exist:
session required /lib/security/pam_limits.so
4. logout and logon
或者在shell配置檔案裡面動態載入。如.bashrc里加:
ulimit -HSn 2048
相關推薦
linux 開啟檔案控制代碼數
首先可以通過ulimit –a 命令來檢視 如下: Redhat系統 [[email protected]_3 ut]# ulimit -a core file size (blocks, -c) 0 data seg size
運維繫統,發現報錯,開啟檔案控制代碼數太多解決方案
在Linux中檢視日誌時,發現有Can’t open so many files資訊。應該是虛擬機器開啟檔案數或者sockets數太多了。 在Linux下,我們使用ulimit -n命令可以看到單個程序能夠開啟的最大檔案控制代碼數量(socket連線也算在裡面)。系統預設值
Windows系統程序開啟檔案控制代碼數的限制
在linux系統中,程序開啟的檔案控制代碼數量的限制,可用ulimit命令來檢視和修改,或者修改/etc/security/limits.conf也可以修改。但在windows中,目前沒有找到方便的方法檢視這個值。 下面這段程式碼可以用來檢視該值,設定的辦法還沒有找到。 W
linux 檔案控制代碼數檢視命令
當你的伺服器在大併發達到極限時,就會報出“too many open files”。 檢視執行緒佔控制代碼數ulimit -a 輸出如下:core file size (blocks, -c) 0data seg size (kbytes, -d) unlimitedscheduling priority
Linux檔案控制代碼數調整
首先介紹下Linux系統中"一切都是檔案"。 1. Linux系統檔案控制代碼數概念 檔案控制代碼和檔案描述符 2. 查詢Linux系統檔案控制代碼數 # ulimit -a core file size (blocks, -c) 0 data seg size
mina通訊,對於高併發的產生:java.io.IOException: Too many open files(開啟檔案控制代碼過多問題)
起因:由於業務系統有多個定時任務定時訪問銀行端,銀行每天也有大量業務訪問業務系統,都是通過mina通訊,部署在測試環境的系統每過一兩天開啟控制代碼過萬,生產的也是一週左右不重啟業務系統就會爆掉。一開始並不清楚到底是哪方面原因導致控制代碼增長這麼快,因為這是一個老系統,經過多次升級,大量的併發、多執行緒,所以只
開啟檔案-控制代碼方式
;檔案控制代碼方式開啟檔案code segment assume cs:codemain proc far jmp startfilename db 'e:/1.txt',0success db 'ok...',0dh,0ah,24hfaile db '
linux的檔案控制代碼--fd
在Linux中,值為0、1、2的fd分別代表標準輸入、標準輸出和標準錯誤輸出。在程式中開啟檔案得到的fd從3開始增長。 fd具體是什麼呢?在核心中,每一個程序都有一個私有的“開啟檔案表”,這個表是一個指標陣列,每一個元素都指向一個核心的開啟檔案物件。而fd,就是這 個
linux中檔案控制代碼洩露
1.檔案控制代碼洩露 在linux中,如果一個檔案正在被某個程序佔用,使用者操作rm刪除該檔案後,我們ls後發現檔案已經不存在了,但實際上該檔案仍然在磁碟上。直到使用它的程序退出後,檔案佔用的磁碟空間才會被釋放。 其原理如下:
記大問題:因為linux系統的控制代碼數限制導致連不上mq的問題
在docker中模擬了數百臺客戶端連線執行在linux系統之上的mq,結果報連線不上的錯誤。 定位了好久,請教了一個前輩,在非常偶然的情況下發現了mq使用的控制代碼數為1021,而linux系統(沒有配置過)這個數值是1024,所以連線不上了 使用ulimit -n 655
linux檢視檔案控制代碼使用情況
Linux 3.2.0-23-generic (linux) 09/08/2014 _x86_64_ (8 CPU) 02:01:55 PM dentunusd file-nr inode-nr pty-nr 02:02:05 P
頻繁通過win32api的createfile函式開啟檔案控制代碼導致記憶體洩漏
1、通過win32的createfile、writefile函式開啟寫入檔案 void WriteLogThread(void* lpParameter) { LPLogData pData = (LPLogData)lpParameter; string logCon
Linux的開啟檔案表:開啟檔案表、檔案描述符、開啟的檔案控制代碼以及i-node之間的關係
在Linux系統中一切皆可以看成是檔案,檔案又可分為:普通檔案、目錄檔案、連結檔案和裝置檔案。檔案描述符(file descriptor)是核心為了高效管理已被開啟的檔案所建立的索引,其是一個非負整數(通常是小整數),用於指代被開啟的檔案,所有執行I/O操作的系統呼叫都通過檔案描述符。程式剛剛啟動的
關於ulimit -a 顯示的檔案開啟控制代碼數的含義
ulimit 我經常用了,還經常設定一些引數,尤其是open file,當時的理解是:openfile設定為多大,此使用者就只能最大開啟這麼多檔案。我還經常給客戶講課,尤其是郵政的客戶,講課我都是這麼講的。我納悶這到底是誰最先告訴我是這麼解釋的?
如何調整“作業系統的中開啟檔案的最大控制代碼數”?
使用/proc檔案系統來控制系統/proc/sys/fs/proc/sys/fs/file-max該檔案指定了可以分配的檔案控制代碼的最大數目。如果使用者得到的錯誤訊息宣告由於開啟檔案數已經達到了最大值,從而他們不能開啟更多檔案,則可能需要增加該值。可將這個值設定成有任意多個
Linux 檔案控制代碼的這些技術內幕,只有 1% 的人知道
1. 緣起 某個月朗風清的晚上,正在公司對面的深大操場跑步,突然接到同事發來的訊息,他發現某機器上的檔案控制代碼使用量有十一萬多個(下面輸出中的第一個欄位) 但是通過運維常用的lsof命令算了下,相差甚遠。 似乎很不科學,這裡看到的資料不到1萬個,剩下1
伺服器記憶體佔用不斷的增加 & 工作管理員(PF使用率)不斷的增加:關注控制代碼數(轉)
原文連結:http://www.cnblogs.com/personnel/p/4583038.html 最近一二個月以來,我發現伺服器的記憶體佔用正按著每天60M的速度增加。 一臺windows 2003的伺服器(2G記憶體),剛剛啟起時佔用記憶體:600M左右。 執行20天后,記憶體佔用(PF使用)
伺服器記憶體線性增長,根據控制代碼數查詢問題程序 伺服器記憶體佔用不斷的增加 & 工作管理員(PF使用率)不斷的增加:關注控制代碼數(轉)
伺服器修改成nignx+xxfm之後 訪問速度變快了很多。但是伺服器記憶體每天線性增長30M左右。 網上找了很多資料都不行。根據這篇文章伺服器記憶體佔用不斷的增加 & 工作管理員(PF使用率)不斷的增加:關注控制代碼數(轉) 檢視所有程序的控制代碼數,發現xxfm.exe程序的控制代碼數有3萬多,
檔案控制代碼的其他方法、游標操作與檔案內容的迴圈
.closed 檢視控制代碼是否關閉 f = open("a.txt", "w") print(f.closed) f.close() print(f.closed) .encoding 檢視檔案控制代碼的編碼方式,即顯示使用什麼編碼開啟的而不是原檔案是以什麼編碼儲存的 f =
什麼是檔案描述符和檔案控制代碼?兩者是什麼關係?
在python裡面有這樣一個函式: 網上解釋什麼是,檔案描述符: 核心(kernel)利用檔案描述符來訪問檔案。檔案描述符是非負整數。開啟現存檔案或新建檔案時,核心會返回一個檔案描述符。讀寫檔案也 需要 檔案描述符來指定待讀寫的檔案。 乍一看,怎麼和檔案控制代碼的描述很想,網上搜了一下: