2009-11-26 72 views
4

我類似hypotetical程序應用:我可以在Linux上用完虛擬內存嗎?

for(;;) { 
    for (i=0; i<1000; i++) { 
    p[i] = malloc(random_number_between_1000_and_100000()); 
    p[i][0]=0; // update 
    } 
    for (i=0; i<1000; i++) { 
    free(p[i]); 
    } 
} 

沒有內存泄漏,但我的系統中,內存的消耗(頂部,列VSS)增長無極限(如可用物理內存的300%)。這是正常的嗎?

更新 - 使用內存一段時間,然後釋放它。這是一個區別嗎?

+0

試着真正地訪問塊,否則不能保證它們已被分配。 – 2009-11-26 14:41:01

回答

1

嘗試添加

sbrk(-1); 

在每個循環的結束,看看它使不同。

free()只釋放內存,但不會將其返回給操作系統。

9

這種行爲是正常的。引用man 3 malloc

BUGS

默認情況下,Linux遵循一個樂觀的內存分配策略。這意味着當malloc()返回非NULL時,不能保證內存真的可用。這是一個非常糟糕的錯誤。如果事實證明系統內存不足,一個或多個進程將被臭名昭着的OOM殺手殺死。

 # echo 2 > /proc/sys/vm/overcommit_memory 

:在情況下,採用Linux的情況下這將是不太理想一下子失去了一些隨機 挑選過程,而且內核版本是足夠近,可以使用如下命令關閉此造成過度行爲另請參閱內核文檔目錄,文件vm/overcommit-accounting和sysctl/vm.txt。

您需要觸摸(讀取/寫入)Linux內核的內存才能真正保留它。

+3

當然,技術上vm overcommit是一個功能,而不是一個錯誤。它可以被禁用,或者不那麼樂觀。 – MarkR 2009-11-26 16:23:41

+0

我第一次遇到這個問題是8年前,當我的朋友在配備128MB RAM的機器上分配1GB的時候。一切都完美無瑕,直到有人決定查看他的源代碼。我們都很困惑,但最終找到了overcommit_memory功能。 – Alexandru 2009-11-26 16:31:00

0

只要你不觸摸那些分配的塊,系統就不會真的爲你分配它們。
但是,您可以耗盡可尋址空間,這是操作系統對進程施加的限制,並不一定是您可以用系統指針類型解決的最大值。

1

操作系統通常將所有頁面分配爲「0」 頁面的寫時複製克隆,即填充零的固定頁面。按照預期從 頁面讀取將返回0。只要你只讀,所有的引用去 相同的物理內存。一旦你寫了一個值,「COW」就是 損壞,併爲你分配一個真實的物理頁面框架。這 意味着只要你不寫入內存,你可以保留 分配內存,直到虛擬內存地址空間用完或 你的頁表填滿所有可用內存。