/tmp 的 Linux/UNIX 伺服器設置實踐
根據大家所看到的，在伺服器系統上推薦的 /tmp 配置是什麼以及為什麼。多年來，我曾就這些問題進行過討論，有時存在基本分歧。
以下基本上是我看到的問題。有些人可能會建議用幾個問題來詢問這些問題，但是，我認為如果將這些資訊放在一個標題下，管理員可能會更容易。我相信這將是有益的。
專門針對 /tmp：
- 應該 ln -s /var/tmp /tmp 嗎？
- /tmp 是否應該在重新啟動之間保留？
- /tmp 應該在真正的磁碟區域上還是允許基本上在 SWAP 區域（或 tmpfs）上實現？
- /tmp 是否應該與 /（根）磁碟位於不同的磁碟上？
- 您會將 /tmp 放在與 /（根）磁碟不同的磁碟控制器上嗎？
- /tmp 大小的任何經驗法則？
- 系統啟動時如何管理 /tmp 空間？刪除所有文件>特定年齡？不理會區域，直到它達到最大值的百分比？
- 是否應該實施任何程序性項目來管理這一領域？
專門針對 /tmp：
- 應該 ln -s /var/tmp /tmp 嗎？
對於完整的記憶體磁碟映像（想想“實時啟動 CD”），這可能是可以接受的，因為需要壓縮 RAM 的每個字節。否則，除非您迫切需要磁碟空間，否則不會。/var 有其自身的特點，在執行系統維護時，將 /tmp 與 /var/tmp 混合可能會產生意想不到的後果。它還添加了一個額外的依賴項，即必須安裝 /tmp 才能使 /var/tmp 正常執行；不是所有的東西都需要/tmp，你可能會想把它遷移到不同的分區或驅動器，但不能，因為你不想解除安裝/var。
- /tmp 是否應該在重新啟動之間保留？
不會。如果您將此作為一致的行為，那麼您遲早會遇到問題。
- /tmp 應該在真正的磁碟區域上還是允許基本上在 SWAP 區域（或 tmpfs）上實現？
當它被大量使用時，這是一種誘惑——“我們將 /tmp 放入 RAM 磁碟，它會加快訪問速度，並且當系統重新啟動/關閉時，沒有什麼可清理的”。但是，如果您正在考慮將臨時空間實現為將被交換的 RAM 磁碟，那麼我會考慮其他程序對系統交換空間使用的影響。如果交換作為“緊急溢出”的一種形式存在，當系統處於緊急狀態並需要它時，您最不需要的就是讓一個失控的程序佔用交換空間，填充 /tmp，消耗記憶體，從而對要交換到磁碟的 VM 子系統。在交換活動和流入 RAM 磁碟的額外 I/O 之間（這反過來可能導致額外的頁面輸入來滿足 seek() ）您的系統將很快成為 I/O 綁定。
- /tmp 是否應該與 /（根）磁碟位於不同的磁碟上？
最好是，是的，儘管這不是必需的。如果您大量使用它，或者需要它的持續工作量，那麼肯定是的。假設範例：將臨時文件轉儲到 /tmp 的數據庫將通過將 /tmp 引入單獨的主軸（即驅動器）而獲得輕微的加速。
- 您會將 /tmp 放在與 /（根）磁碟不同的磁碟控制器上嗎？
如果您對可恢復性或速度有要求，則應予以考慮。
- /tmp 大小的任何經驗法則？
它應該可以容納 2 倍的預期工作量。我的意思是，如果你有本地使用者經常使用這個空間，遲早會有人做一些愚蠢的事情並試圖填滿它。稍微超額將允許您避免程序停止的奇怪“問題”，因為它們的臨時文件已填滿剩餘空間。
如果這是一個“公共服務”安裝，伺服器提供一個或多個網路服務，但不託管使用者，那麼這可能會偏低。如果這是一個多使用者安裝，這將是偏高的（是的，仍然有託管實際使用者的地方，而不僅僅是他們的網路服務）。
- 系統啟動時如何管理 /tmp 空間？刪除所有文件>特定年齡？不理會區域，直到它達到最大值的百分比？
查看tmpwatch命令，我想您會發現它非常適合您問題的這一部分。該命令僅以小時為單位刪除超過特定年齡的任何文件。根據填滿的速度，你可以做 30 天、45 天、90 天等。
- 是否應該實施任何程序性項目來管理這一領域？
我會推薦以下內容：
- 所有文件都是暫時的，並且不能保證在重新啟動後仍然存在。
- 超過 %age 的陳舊文件將在當地時間每晚午夜通過執行 tmpwatch 命令的 cron 作業刪除。
其餘的取決於您的具體需求。