日韩黑丝制服一区视频播放|日韩欧美人妻丝袜视频在线观看|九九影院一级蜜桃|亚洲中文在线导航|青草草视频在线观看|婷婷五月色伊人网站|日本一区二区在线|国产AV一二三四区毛片|正在播放久草视频|亚洲色图精品一区

分享

LINUX ulimit命令

 青蛙一號 2012-03-30

概述

系統(tǒng)性能一直是一個受關(guān)注的話題,如何通過最簡單的設(shè)置來實現(xiàn)最有效的性能調(diào)優(yōu),如何在有限資源的條件下保證程序的運作,ulimit 是我們在處理這些問題時,經(jīng)常使用的一種簡單手段。ulimit 是一種 linux 系統(tǒng)的內(nèi)鍵功能,它具有一套參數(shù)集,用于為由它生成的 shell 進程及其子進程的資源使用設(shè)置限制。本文將在后面的章節(jié)中詳細說明 ulimit 的功能,使用以及它的影響,并以具體的例子來詳細地闡述它在限制資源使用方面的影響。


ulimit 的功能和用法

ulimit 功能簡述

假設(shè)有這樣一種情況,當(dāng)一臺 Linux 主機上同時登陸了 10 個人,在系統(tǒng)資源無限制的情況下,這 10 個用戶同時打開了 500 個文檔,而假設(shè)每個文檔的大小有 10M,這時系統(tǒng)的內(nèi)存資源就會受到巨大的挑戰(zhàn)。

而實際應(yīng)用的環(huán)境要比這種假設(shè)復(fù)雜的多,例如在一個嵌入式開發(fā)環(huán)境中,各方面的資源都是非常緊缺的,對于開啟文件描述符的數(shù)量,分配堆棧的大 小,CPU 時間,虛擬內(nèi)存大小,等等,都有非常嚴(yán)格的要求。資源的合理限制和分配,不僅僅是保證系統(tǒng)可用性的必要條件,也與系統(tǒng)上軟件運行的性能有著密不可分的聯(lián) 系。這時,ulimit 可以起到很大的作用,它是一種簡單并且有效的實現(xiàn)資源限制的方式。

ulimit 用于限制 shell 啟動進程所占用的資源,支持以下各種類型的限制:所創(chuàng)建的內(nèi)核文件的大小、進程數(shù)據(jù)塊的大小、Shell 進程創(chuàng)建文件的大小、內(nèi)存鎖住的大小、常駐內(nèi)存集的大小、打開文件描述符的數(shù)量、分配堆棧的最大大小、CPU 時間、單個用戶的最大線程數(shù)、Shell 進程所能使用的最大虛擬內(nèi)存。同時,它支持硬資源和軟資源的限制。

作為臨時限制,ulimit 可以作用于通過使用其命令登錄的 shell 會話,在會話終止時便結(jié)束限制,并不影響于其他 shell 會話。而對于長期的固定限制,ulimit 命令語句又可以被添加到由登錄 shell 讀取的文件中,作用于特定的 shell 用戶。


圖 1. ulimit 的使用

在下面的章節(jié)中,將詳細介紹如何使用 ulimit 做相應(yīng)的資源限制。

如何使用 ulimit

ulimit 通過一些參數(shù)選項來管理不同種類的系統(tǒng)資源。在本節(jié),我們將講解這些參數(shù)的使用。

ulimit 命令的格式為:ulimit [options] [limit]

具體的 options 含義以及簡單示例可以參考以下表格。


表 1. ulimit 參數(shù)說明

選項 [options] 含義 例子
-H 設(shè)置硬資源限制,一旦設(shè)置不能增加。 ulimit – Hs 64;限制硬資源,線程棧大小為 64K。
-S 設(shè)置軟資源限制,設(shè)置后可以增加,但是不能超過硬資源設(shè)置。 ulimit – Sn 32;限制軟資源,32 個文件描述符。
-a 顯示當(dāng)前所有的 limit 信息。 ulimit – a;顯示當(dāng)前所有的 limit 信息。
-c 最大的 core 文件的大小, 以 blocks 為單位。 ulimit – c unlimited; 對生成的 core 文件的大小不進行限制。
-d 進程最大的數(shù)據(jù)段的大小,以 Kbytes 為單位。 ulimit -d unlimited;對進程的數(shù)據(jù)段大小不進行限制。
-f 進程可以創(chuàng)建文件的最大值,以 blocks 為單位。 ulimit – f 2048;限制進程可以創(chuàng)建的最大文件大小為 2048 blocks。
-l 最大可加鎖內(nèi)存大小,以 Kbytes 為單位。 ulimit – l 32;限制最大可加鎖內(nèi)存大小為 32 Kbytes。
-m 最大內(nèi)存大小,以 Kbytes 為單位。 ulimit – m unlimited;對最大內(nèi)存不進行限制。
-n 可以打開最大文件描述符的數(shù)量。 ulimit – n 128;限制最大可以使用 128 個文件描述符。
-p 管道緩沖區(qū)的大小,以 Kbytes 為單位。 ulimit – p 512;限制管道緩沖區(qū)的大小為 512 Kbytes。
-s 線程棧大小,以 Kbytes 為單位。 ulimit – s 512;限制線程棧的大小為 512 Kbytes。
-t 最大的 CPU 占用時間,以秒為單位。 ulimit – t unlimited;對最大的 CPU 占用時間不進行限制。
-u 用戶最大可用的進程數(shù)。 ulimit – u 64;限制用戶最多可以使用 64 個進程。
-v 進程最大可用的虛擬內(nèi)存,以 Kbytes 為單位。 ulimit – v 200000;限制最大可用的虛擬內(nèi)存為 200000 Kbytes。

 

我們可以通過以下幾種方式來使用 ulimit:

  • 在用戶的啟動腳本中

    如果用戶使用的是 bash,就可以在用戶的目錄下的 .bashrc 文件中,加入 ulimit – u 64,來限制用戶最多可以使用 64 個進程。此外,可以在與 .bashrc 功能相當(dāng)?shù)膯幽_本中加入 ulimt。

  • 在應(yīng)用程序的啟動腳本中

    如果用戶要對某個應(yīng)用程序 myapp 進行限制,可以寫一個簡單的腳本 startmyapp。

     ulimit – s 512 
    myapp

    以后只要通過腳本 startmyapp 來啟動應(yīng)用程序,就可以限制應(yīng)用程序 myapp 的線程棧大小為 512K。

  • 直接在控制臺輸入
     user@tc511-ui:~>ulimit – p 256 

    限制管道的緩沖區(qū)為 256K。


用戶進程的有效范圍

ulimit 作為對資源使用限制的一種工作,是有其作用范圍的。那么,它限制的對象是單個用戶,單個進程,還是整個系統(tǒng)呢?事實上,ulimit 限制的是當(dāng)前 shell 進程以及其派生的子進程。舉例來說,如果用戶同時運行了兩個 shell 終端進程,只在其中一個環(huán)境中執(zhí)行了 ulimit – s 100,則該 shell 進程里創(chuàng)建文件的大小收到相應(yīng)的限制,而同時另一個 shell 終端包括其上運行的子程序都不會受其影響:


Shell 進程 1

 ulimit – s 100 
cat testFile > newFile
File size limit exceeded



Shell 進程 2

 cat testFile > newFile 
ls – s newFile
323669 newFile

 

那么,是否有針對某個具體用戶的資源加以限制的方法呢?答案是有的,方法是通過修改系統(tǒng)的 /etc/security/limits 配置文件。該文件不僅能限制指定用戶的資源使用,還能限制指定組的資源使用。該文件的每一行都是對限定的一個描述,格式如下:

 <domain> <type> <item> <value> 

 

domain 表示用戶或者組的名字,還可以使用 * 作為通配符。Type 可以有兩個值,soft 和 hard。Item 則表示需要限定的資源,可以有很多候選值,如 stack,cpu,nofile 等等,分別表示最大的堆棧大小,占用的 cpu 時間,以及打開的文件數(shù)。通過添加對應(yīng)的一行描述,則可以產(chǎn)生相應(yīng)的限制。例如:

 * hard noflle 100 

 

該行配置語句限定了任意用戶所能創(chuàng)建的最大文件數(shù)是 100。

現(xiàn)在已經(jīng)可以對進程和用戶分別做資源限制了,看似已經(jīng)足夠了,其實不然。很多應(yīng)用需要對整個系統(tǒng)的資源使用做一個總的限制,這時候我們需要修改 /proc 下的配置文件。/proc 目錄下包含了很多系統(tǒng)當(dāng)前狀態(tài)的參數(shù),例如 /proc/sys/kernel/pid_max,/proc/sys/net/ipv4/ip_local_port_range 等等,從文件的名字大致可以猜出所限制的資源種類。由于該目錄下涉及的文件眾多,在此不一一介紹。有興趣的讀者可打開其中的相關(guān)文件查閱說明。


ulimit 管理系統(tǒng)資源的例子

ulimit 提供了在 shell 進程中限制系統(tǒng)資源的功能。本章列舉了一些使用 ulimit 對用戶進程進行限制的例子,詳述了這些限制行為以及對應(yīng)的影響,以此來說明 ulimit 如何對系統(tǒng)資源進行限制,從而達到調(diào)節(jié)系統(tǒng)性能的功能。

使用 ulimit 限制 shell 的內(nèi)存使用

在這一小節(jié)里向讀者展示如何使用 – d,– m 和 – v 選項來對 shell 所使用的內(nèi)存進行限制。

首先我們來看一下不設(shè)置 ulimit 限制時調(diào)用 ls 命令的情況:


圖 2. 未設(shè)置 ulimit 時 ls 命令使用情況

大家可以看到此時的 ls 命令運行正常。下面設(shè)置 ulimit:

 >
ulimit -d 1000 -m 1000 -v 1000

 

這里再溫習(xí)一下前面章節(jié)里介紹過的這三個選項的含義:

-d:設(shè)置數(shù)據(jù)段的最大值。單位:KB。

-m:設(shè)置可以使用的常駐內(nèi)存的最大值。單位:KB。

-v:設(shè)置虛擬內(nèi)存的最大值。單位:KB。

通過上面的 ulimit 設(shè)置我們已經(jīng)把當(dāng)前 shell 所能使用的最大內(nèi)存限制在 1000KB 以下。接下來我們看看這時運行 ls 命令會得到什么樣的結(jié)果:

 haohe@sles10-hehao:~/code/ulimit> ls test -l 
/bin/ls: error while loading shared libraries: libc.so.6: failed to map segment
from shared object: Cannot allocate memory

 

從上面的結(jié)果可以看到,此時 ls 運行失敗。根據(jù)系統(tǒng)給出的錯誤信息我們可以看出是由于調(diào)用 libc 庫時內(nèi)存分配失敗而導(dǎo)致的 ls 出錯。那么我們來看一下這個 libc 庫文件到底有多大:


圖 3. 查看 libc 文件大小

從上面的信息可以看出,這個 libc 庫文件的大小是 1.5MB。而我們用 ulimit 所設(shè)置的內(nèi)存使用上限是 1000KB,小于 1.5MB,這也就充分證明了 ulimit 所起到的限制 shell 內(nèi)存使用的功能。

使用 ulimit 限制 shell 創(chuàng)建的文件的大小

接下來向讀者展示如何使用 -f 選項來對 shell 所能創(chuàng)建的文件大小進行限制。

首先我們來看一下,沒有設(shè)置 ulimit -f 時的情況:


圖 4. 查看文件

現(xiàn)有一個文件 testFile 大小為 323669 bytes,現(xiàn)在使用 cat 命令來創(chuàng)建一個 testFile 的 copy:


圖 5. 未設(shè)置 ulimit 時創(chuàng)建復(fù)本

從上面的輸出可以看出,我們成功的創(chuàng)建了 testFile 的拷貝 newFile。

下面我們設(shè)置 ulimt – f 100:

 > ulimit -f 100

-f 選項的含義是:用來設(shè)置 shell 可以創(chuàng)建的文件的最大值。單位是 blocks。

現(xiàn)在我們再來執(zhí)行一次相同的拷貝命令看看會是什么結(jié)果:


圖 6. 設(shè)置 ulimit 時創(chuàng)建復(fù)本

這次創(chuàng)建 testFile 的拷貝失敗了,系統(tǒng)給出的出錯信息時文件大小超出了限制。在 Linux 系統(tǒng)下一個 block 的默認(rèn)大小是 512 bytes。所以上面的 ulimit 的含義就是限制 shell 所能創(chuàng)建的文件最大值為 512 x 100 = 51200 bytes,小于 323669 bytes,所以創(chuàng)建文件失敗,符合我們的期望。這個例子說明了如何使用 ulimit 來控制 shell 所能創(chuàng)建的最大文件。

使用 ulimit 限制程序所能創(chuàng)建的 socket 數(shù)量

考慮一個現(xiàn)實中的實際需求。對于一個 C/S 模型中的 server 程序來說,它會為多個 client 程序請求創(chuàng)建多個 socket 端口給與響應(yīng)。如果恰好有大量的 client 同時向 server 發(fā)出請求,那么此時 server 就會需要創(chuàng)建大量的 socket 連接。但在一個系統(tǒng)當(dāng)中,往往需要限制單個 server 程序所能使用的最大 socket 數(shù),以供其他的 server 程序所使用。那么我們?nèi)绾蝸碜龅竭@一點呢?答案是我們可以通過 ulimit 來實現(xiàn)!細心的讀者可能會發(fā)現(xiàn),通過前面章節(jié)的介紹似乎沒有限制 socket 使用的 ulimit 選項。是的,ulimit 并沒有哪個選項直接說是用來限制 socket 的數(shù)量的。但是,我們有 -n 這個選項,它是用于限制一個進程所能打開的文件描述符的最大值。在 Linux 下一切資源皆文件,普通文件是文件,磁盤打印機是文件,socket 當(dāng)然也是文件。在 Linux 下創(chuàng)建一個新的 socket 連接,實際上就是創(chuàng)建一個新的文件描述符。如下圖所示(查看某個進程當(dāng)前打開的文件描述符信息):


圖 7. 查看進程打開文件描述符

因此,我們可以通過使用 ulimit – n 來限制程序所能打開的最大文件描述符數(shù)量,從而達到限制 socket 創(chuàng)建的數(shù)量。

使用 ulimit 限制 shell 多線程程序堆棧的大?。ㄔ黾涌捎镁€程數(shù)量)

在最后一個例子中,向大家介紹如何使用 -s(單位 KB)來對線程的堆棧大小進行限制,從而減少整個多線程程序的內(nèi)存使用,增加可用線程的數(shù)量。這個例子取自于一個真實的案例。我們所遇到的問題是系統(tǒng)對我們的多線程程序有如下的限制:

ulimit -v 200000

根據(jù)本文前面的介紹,這意味著我們的程序最多只能使用不到 200MB 的虛擬內(nèi)存。由于我們的程序是一個多線程程序,程序在運行時會根據(jù)需要創(chuàng)建新的線程,這勢必會增加總的內(nèi)存需求量。一開始我們對堆棧大小的限制是 1024 (本例子中使用 1232 來說明):

 # ulimit – s 1232

 

當(dāng)我們的程序啟動后,通過 pmap 來查看其內(nèi)存使用情況,可以看到多個占用 1232KB 的數(shù)據(jù)段,這些就是程序所創(chuàng)建的線程所使用的堆棧:


圖 8. 程序線程所使用的堆棧

每當(dāng)一個新的線程被創(chuàng)建時都需要新分配一段大小為 1232KB 的內(nèi)存空間,而我們總的虛擬內(nèi)存限制是 200MB,所以如果我們需要創(chuàng)建更多的線程,那么一個可以改進的方法就是減少每個線程的固定堆棧大小,這可以通過 ulimit – s 來實現(xiàn):

 # ulimit -s 512 

 

我們將堆棧大小設(shè)置為 512KB,這時再通過 pmap 查看一下我們的設(shè)置是否起作用:


圖 9. 設(shè)置 ulimit 后堆棧大小

從上面的信息可以看出,我們已經(jīng)成功的將線程的堆棧大小改為 512KB 了,這樣在總內(nèi)存使用限制不變的情況下,我們可以通過本小節(jié)介紹的方法來增加可以創(chuàng)建的線程數(shù),從而達到改善程序的多線程性能。


總結(jié)

綜上所述,linux 系統(tǒng)中的 ulimit 指令,對資源限制和系統(tǒng)性能優(yōu)化提供了一條便捷的途徑。從用戶的 shell 啟動腳本,應(yīng)用程序啟動腳本,以及直接在控制臺,都可以通過該指令限制系統(tǒng)資源的使用,包括所創(chuàng)建的內(nèi)核文件的大小、進程數(shù)據(jù)塊的大小、Shell 進程創(chuàng)建文件的大小、內(nèi)存鎖住的大小、常駐內(nèi)存集的大小、打開文件描述符的數(shù)量、分配堆棧的最大大小、CPU 時間、單個用戶的最大線程數(shù)、Shell 進程所能使用的最大虛擬內(nèi)存,等等方面。本文中的示例非常直觀的說明了 ulimit 的使用及其產(chǎn)生的效果,顯而易見,ulimit 對我們在 Linux 平臺的應(yīng)用和開發(fā)工作是非常實用的。

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多