我對這個問題的看法是從開發者的角度來看的。我編寫的程式碼被放置在作為企業系統中的眾多虛擬機器之一運行的 RHEL 虛擬機器上。所使用的檔案系統是遠端網路連接儲存設備。
在批次過程中，我們的簡單指令存在很大的可變性。所以我們設置了一個測試來獲取更多信息，但現在我不知道我們發現了什麼。
我們每 30 分鐘執行一次以下命令並記錄輸出。這是 6 GB 檔案的副本。當系統忙於運行大量作業並且此測試命令的 CPU 時間較低時，我看到運行時間從 11 秒躍升至 190 秒。
我可以看到，當 CPU 較低時，「I」列（檔案系統輸入）會被填充，但當 CPU 較高時則不會。 「w」欄（非自願掉期）也高很多。
我的問題是，當 CPU 時間減少時，這個作業/命令發生了什麼，迫使它運行這麼長時間？換入/換出是否將所有資料儲存在速度慢得多的其他設備上？一般來說，換入/換出期間會發生什麼事？
正在運行的命令：
/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
| 日期 | 時間 | e | S | U | 磷 | C | w | 我 | 氧 |
|---|---|---|---|---|---|---|---|---|---|
| 2022 年 3 月 14 日 | 5:19:02 | 64.9 | 16.23 | 1.03 | 26% | 3005 | 29210 | 12000016 | 12000000 |
| 2022 年 3 月 14 日 | 5:49:02 | 12.7 | 11.63 | 0.79 | 97% | 2069 | 76 | 0 | 12000000 |
| 2022 年 3 月 14 日 | 6:19:02 | 100.39 | 14.74 | 0.78 | 15% | 1034 | 29925 | 12000136 | 12000000 |
| 2022 年 3 月 14 日 | 6:49:24 | 191.32 | 18.86 | 0.94 | 10% | 3374 | 36164 | 12001024 | 12000000 |
| 2022 年 3 月 14 日 | 7:19:02 | 71.61 | 15.61 | 0.88 | 23% | 1610 | 30316 | 12000296 | 12000000 |
| 2022 年 3 月 14 日 | 7:49:02 | 70.73 | 17.5 | 0.91 | 26% | 1408 | 29540 | 12000072 | 12000000 |
| 2022 年 3 月 14 日 | 8:19:02 | 10.95 | 9.89 | 0.7 | 96% | 第1709章 | 75 | 0 | 12000000 |
| 2022 年 3 月 14 日 | 8:49:02 | 11.01 | 10.22 | 0.73 | 99% | 239 | 85 | 0 | 12000000 |
/usr/bin/time 手冊頁中的列描述
e Elapsed real time (in seconds).
S Total number of CPU-seconds that the process spent in kernel mode.
U Total number of CPU-seconds that the process spent in user mode.
P Percentage of the CPU that this job got, computed as (%U + %S) / %E.
c Number of times the process was context-switched involuntarily (because the time slice expired).
w Number of waits: times that the program was context-switched voluntarily, for instance while waiting for an I/O operation to complete.
I Number of filesystem inputs by the process.
O Number of filesystem outputs by the process.
答案1
在這種情況下，P 表示該作業所獲得的 CPU 時間與已使用總時間的比率。接近 100% 意味著幾乎所有時間都在 CPU 上，因此這些運行的 CPU 受到限制。與其他運行相比，其他運行是其他因素的限制因素。系統（又稱核心）時間多於系統時間，這是典型的 I/O 繁重任務。
鑑於工作負載是複製 6 GB 文件，我們可以推斷 11 秒的運行平均每秒寫入次數超過 0.5 GB。 O列每次都確認相同的寫入次數，與簡單的複製一個檔案過程一致。
然而，輸入列有很大的波動。慢速運行的讀取與寫入大致相同。但快速運行不會進行任何讀取！我假設該檔案自上次讀取時起仍緩存在 RAM 中。 DRAM 甚至比固態儲存快得多。這是一個很大的速度提升，直到在記憶體壓力下作業系統刪除快取的數據，並且必須再次從慢速儲存中讀取。
所以這是一個 200 秒的任務，有時可能需要 12 秒。可能是由於 Linux 頁面快取。
尋找效能問題的根本原因通常需要對整個系統有更深入的了解，而不僅僅是任何特定的指標集。
所使用的檔案系統是遠端網路連接儲存設備。
請注意，您的複製內容是透過網路儲存進行的，因此它也可以是遠端系統或中間網路上的任何內容。遠端儲存效能。網路（可能是 IP）速度和利用率。或者它可能位於該虛擬機器的本地，其中來賓與基礎架構上運行的其他所有內容競爭資源。
總是可以更深入地了解事物的運作方式。網路儲存（NFS？）是否重要，或者您是否也看到本地磁碟的這一點？ 0.7 秒的使用者 CPU 時間其實是相當大的工作量，管理許多系統呼叫要花多少錢？當大部分都在等待慢速記憶體和非常慢的儲存時，CPU 繁忙實際上意味著什麼？這不是一個容易回答的問題，但是一旦事情表現良好，也許就不需要深入研究了。