無論如何，有沒有辦法防止進程被殺死？我知道，nice但我不確定為諸如長時間運行的內存密集型rake任務之類的任務賦予最高優先級是否會防止它被殺死：
nice -n -20 rake xyz
編輯：原始發布者很可能希望它具有高優先級，即使伺服器資源也很低，以至於其他進程首先被殺死。
答案1
您無法阻止 root 殺死進程。或者就此而言：您無法阻止伺服器殺死一個耗盡您所有資源的進程。
您可以做的是分叉該命令，以便它在被殺死時重新啟動。
使用程式碼範例：
答案2
現在，我知道這是一個老問題，但由於這兩個答案都忽略了顯而易見的問題——或者最多只是觸及表面——所以我覺得有必要寫下自己的答案。考慮到問題的措辭，我首先想到的是“OOM 殺手！”。其他答案之一甚至聲稱“某些東西不會自動被殺死”，從用戶的角度來看，這是荒謬的。如果 OOM 殺手不是自動現象，那又是什麼？
這OOM 殺手對於所描述的場景，是您最大的敵人，正如連結的文章將顯示的那樣。
現在這取決於確切的場景（建立機器，一些伺服器...），但總的來說我做希望我的作業系統盡可能地使用我的機器的資源。這就是我首先購買這些的原因。
你的問題，細分：
無論如何，有沒有辦法防止進程被殺死？
不，幸運的是不是。例如，核心將殺死行為不當的進程（例如透過發送訊號產生器）。如果您的任務因遇到資源限製而行為異常，這也適用（請參閱限制.conf,取得限制/設定限制）。也就是說，如果您的rake任務中的某些內容（很可能會使用其他進程來完成某些工作）取消引用空指針，那麼您仍然不走運，該部分將會失敗，這隨後可能會使任務失敗。
Root 也很可能能夠發送訊號到你的流程。即使你不知何故設法保護您的進程免受與用戶空間相關的任何內容的影響，root仍然能夠加載核心模組並破壞核心的這些工作（可能除了活動核心鎖定之外）。
我知道，
nice但我不確定為諸如長時間運行的內存密集型rake任務之類的任務賦予最高優先級是否會防止它被殺死：[...]
它不會阻止它，但它將要被用作一OOM 殺手的幾種啟發式方法。所以是的，實際上的nice價值將要幫助...一點。這綠網文章我上面已經連結的給了以下啟發：
- 如果任務有零以上的好價值，其得分翻倍
- 超級用戶或直接硬體訪問任務（CAP_SYS_ADMIN、CAP_SYS_RESOURCE 或 CAP_SYS_RAWIO）的分數除以 4。
- 如果 OOM 情況發生在一個中央處理器組如果檢查的任務不屬於該集合，則其分數除以 8。
- 所得分數乘以 2 的 oom_adj 次方（即，當分數為正時，分數 <<= oom_adj，否則分數 >>= -(oom_adj)）
除了該nice值之外，您還可以透過以 root 身分執行（或使用給定的功能）來更進一步，或者，如果您是 root，你可以確保你的進程不會被 OOM 殺手殺死（這篇文章有完整的細節）建立一個cgroup：
mount -t cgroup -o oom oom /mnt/oom-killermkdir /mnt/oom-killer/invinciblesecho 0 > /mnt/oom-killer/invincibles/oom.priorityecho <pid> > /mnt/oom-killer/invincibles/tasks，哪裡<pid>是你的 rake 任務的進程 ID ...
所以就這樣吧。您可以使某些進程組免受 OOM 殺手的攻擊。
但是，我不確定這種大錘方法是否有效第一的最好的事情就是做。我認為您應該先進行修改，oom_adj看看這是否有助於您的流程在與其他流程的競爭中生存。特別是如果這是一個伺服器，那麼整體服務可能比某項特定任務更重要，而後者甚至可能對服務並不重要。所以要謹慎使用。此外，您可能需要監視記憶體消耗（sysstat 和朋友應該提供協助）。如果您透過時間序列資料庫執行此操作並繪製圖表，您甚至可能會發現記憶體洩漏。
如果這些都不起作用，您應該前往布倫丹·格雷格的網站並開始測量不同的性能指標；也看看你是否可以拿他的一本書。例如，您的rake任務中的記憶體分配可能確實存在失控的情況。因為你強調長時間運行和記憶體密集型但這些並沒有必然的聯繫。 BPF 和朋友將讓您獲得透過其他方式無法獲得的見解。
答案3
為什麼會它會被殺死嗎？
因為某些東西不會自動被殺死。一旦你回答了這個問題，並解釋了為什麼選擇銷毀某些東西，你也許就能想出一個解決方案。
鑑於您正在談論 Rails 的rake命令，我猜測這是一個在伺服器上運行的進程。您擔心它被殺死表明它因使用太多資源而被伺服器主機殺死。在這種情況下，沒有（也不應該有）方法來阻止你的進程被殺死。
如果您有一項資源昂貴的任務，請購買更多資源。使用您自己的伺服器時間。或與主機達成協議，允許您用他們的錢運行它。