Python 在處理大型 numpy 數組時，CPU 使用率隨機下降到 0%，導致代碼“掛斷”？

Question

我一直在運行一些代碼，其中一部分從二進制文件加載到一個大型的一維 numpy 數組中，然后使用numpy.where()方法更改數組。

以下是代碼中執行的操作的示例：

import numpy as np
num = 2048
threshold = 0.5

with open(file, 'rb') as f:
    arr = np.fromfile(f, dtype=np.float32, count=num**3)
    arr *= threshold

arr = np.where(arr >= 1.0, 1.0, arr)
vol_avg = np.sum(arr)/(num**3)

# both arr and vol_avg needed later

我已經運行了很多次（在免費機器上，即沒有其他抑制 CPU 或內存使用的情況），沒有問題。 但是最近我注意到有時代碼會掛起很長一段時間，使運行時間延長一個數量級。 在這些情況下，我一直在監視 %CPU 和內存使用率（使用 gnome 系統監視器），發現 python 的 CPU 使用率下降到 0%。

在上述操作之間使用基本打印進行調試，似乎是任意操作導致暫停（即 open()、np.fromfile()、np.where() 分別導致隨機運行掛起）。 就好像我被隨機節流了一樣，因為在其他運行中沒有掛起。

我已經考慮過垃圾收集或這個問題之類的事情，但我看不出與我的問題有任何明顯的關系（例如，擊鍵無效）。

進一步說明：二進制文件為 32GB，機器（運行 Linux）有 256GB 內存。 我通過 ssh 會話遠程運行此代碼。

編輯：這可能是偶然的，但我注意到如果我在機器剛剛重新啟動后運行代碼，則沒有掛斷。 似乎它們在幾次運行后開始發生，或者至少是系統的其他使用。

Answer 1

np.where正在那里創建一個副本並將其分配回arr 。 因此，我們可以通過避免復制步驟來優化內存，就像這樣 -

vol_avg = (np.sum(arr) - (arr[arr >=  1.0] - 1.0).sum())/(num**3)

我們使用boolean-indexing選擇大於1.0的元素並從1.0獲取它們的偏移量，然后將它們相加並從總和中減去。 希望這種超出元素的數量更少，因此不會再引起明顯的內存需求。 我假設大數組的這個掛起問題是基於內存的問題。

Answer 2

CPU 使用率的下降與 python 或 numpy 無關，但確實是從共享磁盤讀取的結果，而網絡 I/O 才是真正的罪魁禍首。 對於如此大的數組，讀入內存可能是一個主要瓶頸。

Answer 3

您是否單擊或選擇了控制台窗口？ 這種行為可以“掛起”進程。 控制台進入“QuickEditMode”。 按任意鍵可以恢復該過程。