不同方法的功能性能分析Linux

我知道這個問題更多的是編譯器&操作系統相關的東西，但如果任何人都可以拋出一些光，它可以幫助我做一些優化。不同方法的功能性能分析Linux

我的目標是在文件夾中創建一個文件X Y

（這可能是數以百萬計的數量，也x和y是變異和變化的每一個電話。）上午在Linux上工作。

要做到這一點，我有兩個途徑：

首先做一個CHDIR所需目錄「Y」，然後創建文件「X」。

C代碼：

char *dir = "/root/"; 
FILE *fd; 
chdir(dir); 
fd = fopen("geneliatestingN","a+"); 
fprintf(fd,"ansh"); 
fclose(fd);

strace的：

1329039557.874631 chdir("/root/")  = 0 
1329039557.874704 brk(0)    = 0x9ad6000 
1329039557.874726 brk(0x9af7000)  = 0x9af7000 
1329039557.874757 open("geneliatestingN", O_RDWR|O_CREAT|O_APPEND, 0666) = 3 
1329039557.874817 fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 
1329039557.874869 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fcb000 
1329039557.874899 write(3, "ansh", 4) = 4 
1329039557.874940 close(3)    = 0

第二種方式是只需提供該文件的絕對路徑，並創建它。

C代碼：

sprintf(filepath, "%s/geneliatestingS",dir); 
fd = fopen(filepath,"a+"); 
fprintf(fd,"ansh Testing again"); 
fclose(fd);

strace的：

1329039557.875000 open("/root//geneliatestingS", O_RDWR|O_CREAT|O_APPEND, 0666) = 3 
1329039557.875046 fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 
1329039557.875096 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fcb000 
1329039557.875123 write(3, "ansh Testing again", 18) = 18 
1329039557.875160 close(3)    = 0

那麼，什麼可能是更好的方法來基本實現此功能這兩個將消耗更少的指令週期，無論是在CPU更高效和執行時間。

來源

2012-02-12 Genelia D' souza

什麼文件系統？也許一些背景會讓答案更有趣。您是否打算在不同目錄中創建大量文件？ – 2012-02-12 10:00:31

嗨Johan，這是一個CentOS版本5.4（最終版）。 Linux 2.6.18-164.el5PAE 2009 i686 i686 i386 GNU/Linux。 Yess Johan，我有一套約1000萬個根目錄的目錄，這些文件被隨機地寫入這些目錄中的任何一個，或者可能是它的子目錄。 – 2012-02-12 10:16:38

請遵循以下建議。如果您確實需要堅持您的方法，請嘗試各種文件系統和文件系統選項（例如man tune2fs）。看看ReiserFS（或Reiser4） – 2012-02-12 12:04:44

獲得正確答案的唯一方法是嘗試使用特定的系統和度量。

但是，我相信最小化系統調用的次數應該會更好。

其實，你可能正在考慮在同一個目錄下寫很多文件。最近的文件系統有索引目錄，但是一些較舊的文件系統沒有它們（所以對於這樣的舊文件系統，文件創建或尋找操作在每個目錄中的條目數是線性的）。

一個老把戲，考慮到某些目錄/foo寫了成千上萬的文件的時候是創造了幾十個子目錄像/foo/1//foo/2/和填充每個這樣的子目錄，只有幾百項。

這樣做的另一個原因是因爲交互式shell（包含文件完成）在包含成千上萬條目錄的目錄中不是很滿意。

一如往常，您的里程可能會有所不同。

如果你想有成千上萬的小文件，你可以考慮其他的解決方案，如數據庫（與MySQL或PostgreSQL客戶端庫和服務器.eg）或GDBM索引文件

來源

2012-02-12 10:06:23

你會I/O綁定，而不是CPU綁定。

您可能會在錯誤的級別進行優化 - 無論您如何使用此設計，當您的驅動器將被磨削時，您的CPU將等待。

關閉我的頭頂，我肯定會考慮：

您的硬盤驅動器磁頭多久尋求採取。我敢打賭，通過在寫入磁盤之前排序儘可能多的這些目錄，試圖最大限度地減少頭部尋找，你可以優化比減少CPU週期更好。
完全從頂部重新設計您的系統：考慮除編寫1000萬個目錄之外的其他模型。你能寫出更少的文件，也許使用mmap（）來代替？請注意，問題不僅在於將此數據寫入磁盤 - 您的設計選擇可能會極大地影響您在用戶需要訪問時將此數據讀回內存的速度。例如，如果您有十個用戶希望從文件系統的所有不同部分獲取文件，您的硬盤將成爲您的瓶頸。
根據您的應用程序，Nosql數據庫可能對您更好。

來源

2012-02-12 10:41:09 kfmfe04

感謝評論傢伙..但文件夾實際上是散列路徑，所以不需要擔心它，讀寫是O（1）操作。 – 2012-02-12 11:35:27

不同方法的功能性能分析Linux

回答

相關問題