什麼是“inode”以及它如何影響我的 WordPress 網站？

網站和網絡託管最常見（和誤解）的元素之一是 inode。 如果您運行自己的網站或處理任何級別的維護，您將在某個時候處理 inode。 無論是通過日常維護還是嘗試修復錯誤，了解 inode 是什麼以及它如何影響您的 WordPress 安裝對於您的長期成功至關重要。

什麼是索引節點？

一般而言，inode 是文件系統中的單個文件。 對於大多數用戶來說，這些信息足以處理他們將遇到的幾乎所有事情。

然而，從技術上講，inode 是在 UNIX 系統（Linux 服務器和 Apple 計算機基於 UNIX）上存儲文件元數據的地方。 inodes 是由目錄和文件鏈接到的表條目 inodes 包含各種信息：

此元數據包括 (1) 文件的大小（以字節為單位）及其物理位置（即，硬盤上包含文件數據的存儲塊的地址），(2) 文件的所有者和組，(3)文件的訪問權限（即，允許哪些用戶讀取、寫入和/或執行該文件），(4) 時間戳，說明 inode 的創建時間、上次修改時間和上次訪問時間以及 (5) 引用計數，說明有多少困難鏈接指向 inode。

因為大多數 Web 服務器都是基於 Linux 的，所以 inode 管理將變得很重要。 您可以將它們視為指向您網站的鏈接。 您可以有多個鏈接指向您網站的同一頁面，但這並不意味著該頁面有多個副本。 文件和 inode 也是如此。

雖然從技術上講，不存在 1:1 的關係，但您會發現許多實例中只有 1 個文件鏈接到 1 個 inode。 大多數用戶可以在他們的想法下工作。

索引節點的問題

他們用完了。 它們是有限的。 而且您可能沒有跟踪您的 inode 使用情況。

不久前，我突然收到了來自 Siteground 的“警告：帳戶 YourSite.com 達到了允許的 Inode 配額的 80%”電子郵件。 我沒有做任何不尋常的事情，但不知何故，我像塔一樣堆疊了我的 inode。 我猜想，如果您在託管帳戶上運行多個 WordPress 安裝，您已經（或將要）收到類似的電子郵件。

現在，在電子郵件中，它們非常簡單：要減少 inode 的數量，您需要通過 cPanel – 文件管理器或您首選的 FTP 客戶端減少您帳戶中的文件和文件夾的數量。 從本質上講，這就是您所要做的。 但它比這要復雜一些，因為如果您擁有主機任何時間，您可能已經在那裡獲得了相當不錯的文件和文件夾存檔。

要檢查您的 inode 使用情況，您需要登錄您的 cPanel 並查找Stats框。 在大多數版本的 cPanel 中，它將位於頁面左側的某個位置。 您將主要看到以 MB 和 GB 為單位的磁盤使用空間，以及您被允許使用的 inode 數量和您當時正在使用的 inode 數量。

幸運的是，就像大多數關於 WordPress 的東西一樣，CMS 以一種使您的 inode 管理相對簡單的方式組合在一起。

為什麼索引節點對 WordPress 用戶很重要

你們中的許多人可能永遠不必使用 inode。 在日常業務中，您根本不會真正注意到它們。 只要您的網站一切順利，就沒有什麼能讓您看到這個詞。 當出現問題時，您將開始在 WordPress 儀表板或其他地方看到錯誤。

通常，每個使用 cPanel 的託管服務提供商（其中大多數，除非您要託管託管）都會根據您的包為您分配一定數量的 inode。 規則通常是您支付的越多，您獲得的 inode 就越多。

請記住，這與您擁有的存儲空間完全不同。 兩者的體積可能是 1:1 左右，但通常會在耗盡存儲空間之前耗盡 inode，因為 inode 在位和字節方面比大多數文件小得多（因為它們只是文件本身的一部分）。

也就是說，WordPress 用戶經常發現自己在與一些以 inode 為中心的問題作鬥爭。

WordPress 用戶如何建立索引節點

雖然那裡的每個 CMS 都有自己獨特的使用 inode 的方式，但 WordPress 有一些特定於其生態系統的方式。 主要是圖像、插件和主題。 讓我們深入研究，找出原因以及我們可以做些什麼。

圖片

媒體庫中的圖像可能會佔用大量的 inode。 即使你沒有成千上萬的人。 我敢打賭，你們中的大多數人都會將圖片上傳到您的網站。 理論上，1 張圖像等於 1 個 inode。 但實際情況並非如此。 根據您的主題和圖像壓縮插件，該 1 個圖像可能需要近十個 inode。 如何？ 通過在存儲中保存多種尺寸的渲染。

如果您檢查庫中任何圖像的詳細信息並看到文件大小，那麼它就是一個 inode。 為您的媒體庫中的每一個圖像考慮一下。 對於這個特定站點，我在媒體庫中有 562 個項目。 假設（可能不正確）它們每個都有 11 個版本，即 6,000 多個 inode。 從字面上看，它應該是它的 11 倍。

這是針對一個站點的。 如果您將任何一般託管計劃中的站點數量考慮在內，那麼該數量確實可以加起來。 在我自己的帳戶中，我有十幾個 WordPress 正在運行。 在每次安裝的核心文件之上，來自所有用戶的媒體庫增加了 inode 的使用。

插件和主題

插件和主題佔用如此多的 inode 有幾個原因。 首先是很多人安裝了大量它們，即使它們被停用。

在這些插件文件夾中的每一個中，都有數十個文件佔用了 inode。 一些插件顯然比其他插件輕，但它們都增加了安裝量。 所以請記住，刪除您當前未使用的任何插件通常是最佳做法。

主題的工作方式完全相同。 如果您已經使用了相當長的時間，則無法知道您在 WordPress 網站上安裝了多少主題。 即使這些主題只是默認的 WordPress 主題，您也有很多 inode 正在使用。 如果您不使用主題，請將其刪除。 但是，如果您通過子主題進行了自定義，通常可以將其保留（或進行備份），因為您不能像父主題一樣輕鬆地重新安裝它。

緩存插件和備份實用程序

彗星緩存。 WPRocket。 上升氣流。 i主題。 文字圍欄。 WP 超級緩存。 W3 總緩存。 蘇庫裡。

所有這些（以及更多）都佔用了寶貴的 inode。 大多數情況下，沒關係。 它們是令人驚嘆的插件，可以讓您的生活更輕鬆，讓您的用戶在您的網站上獲得更好的體驗。 但是，如果不加以檢查，緩存文件和備份文件以及安全報告可能會增加。

因此，每隔一段時間，請確保清除站點上的緩存並讓它重新填充。 大多數情況下，您可以在管理工具欄中找到清除緩存或刪除緩存按鈕。

此外，來自 UpdraftPlus 等插件的額外備份會佔用寶貴的空間。 因此，請檢查您在本地服務器上存儲的內容。 對於大多數備份實用程序，您可以在 WP 管理面板中執行此操作。 或者您可以通過 FTP 進行檢查。

除了這些備份佔用您服務器上的 inode 和存儲空間之外，它們還容易受到可能進入您的安裝的黑客的攻擊。 因此，將它們保存在遠程目的地（例如 Dropbox 或 Google Drive）將是最好的主意。

如何修復常見的 inode 錯誤

即使 WordPress 有特定於平台的 inode 問題，也有一些在網絡上很常見。 無論您使用的是 Drupal、Joomla、WordPress 還是 Ghost，您都可能需要在某個時候修復這些問題。

• 電子郵件不會通過傳統客戶端、自動回复器或網站本身的表單發送
• 收不到郵件
• 上傳始終失敗
• 帖子和頁面不會更新，甚至不會創建
• 用戶無法訪問該站點
• 在某些情況下，可能會阻止從一台主機遷移到另一台主機

在所有這些情況下，罪魁禍首可能是服務器接近其 inode 配額的上限。 或者它完全沒有inode。 請記住，即使您只使用了一部分存儲容量，您仍然可以用完 inode。

每次發送或接收電子郵件時，都會生成一個文件。 如果沒有 inode，則無法創建文件。 如果您的 inode 已滿，則上傳將失敗，因為根本無處可存儲數據。 WordPress 或其他 CMS 平台中的帖子和頁面也是如此，無法在沒有位置的情況下生成必要的文件。 即使當用戶訪問頁面時，也會生成文件——cookie、令牌、緩存文件。 如果沒有 inode，這些用戶將得不到任何服務。

從一台主機遷移到另一台主機時，您的 inode 分配可能會有所不同。 我的個人是最後一次交換。 因此，您甚至可能還沒有接近當前的配額，而是已經超過了即將到來的配額。 這聽起來可能很痛苦，但實際上很容易解決。

以下是刪除文件並釋放一些空間以修復這些常見 inode 錯誤的最佳方法。

刪除舊電子郵件

您會看到，每次發送或接收電子郵件時，它都會在您的服務器上創建一個文件（假設您沒有使用外部郵件服務）。 這意味著您的所有郵件都佔用了 inode。 如果您存檔或只是將電子郵件保存在收件箱中，那麼這些電子郵件就會停滯在您的服務器上。 所以是時候刪除它們了。 您可以在普通客戶端中執行此操作，也可以通過 FTP 或通過 cPanel 的文件管理器執行此操作。

只需進入您站點的根目錄並找到Mail文件夾。 在它下面將是您擁有電子郵件地址的每個域的目錄，在每個域下將是您設置的任何別名。 這些文件夾中的每一個都很重要，並且可能充滿了 inode 竊取文件。 不過，您將主要關注cur和new目錄。 有時是垃圾。

在刪除這個地址中的新電子郵件後，我從218316 inode used 到218218 。 你應該有更大的收穫，因為這個電子郵件地址一開始很少被使用。 請記住在刪除之前備份所有電子郵件。 否則你不能讓他們回來。

清除臨時文件夾

臨時文件是神奇的野獸。 如果您知道在哪裡可以找到它們，您就可以確保它們在做他們的工作，但不會佔用太多資源。 每當您看到tmp目錄時，這就是存儲這些臨時文件的位置。 會話令牌、緩存文件、流量日誌，以及當時很棒的各種東西，但以後就沒有用處了。

除非您設置了自動化或 CRON 作業來清除臨時文件，否則您可能需要每隔一段時間進入並執行一些內務處理。 主要這些將位於tmp下的根目錄中。

作為一般經驗法則，您可以刪除任何日誌文件、緩存文件或會話文件。 在大多數情況下，您會非常清楚地看到它們。 通常文件名將包含sess或cache或log ，使您的工作非常容易。

您刪除的大多數文件將是服務器日誌和流量日誌。 只要您有這些文件的備份，請瀏覽您的tmp文件夾並刪除您需要的內容。 在這個特定示例中，我正在清除webalizer、webalizerftp、horde、awstats和模擬目錄。 請記住，刪除這些文件將刪除服務器統計信息和日誌，因此如有必要，請先備份它們。

您也可以查看它們上的日期。 根據您的站點，您可能不需要一直追溯到 2011 年的日誌。

此外，您還會在主tmp文件夾中找到一些文件。 它們可能是會話文件、日誌文件和您不確定的其他文件的混合。 就像計算機和 Web 開發的所有內容一樣，如果您不知道它是什麼，請不要管它。 但不要刪除任何擴展名為.sock 的文件，這一點非常重要。 在較小程度上， .lock 。

清除您的日誌文件

與tmp文件夾類似， logs文件夾是一個根目錄，其中包含服務器日誌存檔後的存檔。 您的服務器開始為您在主機上激活它的每個月保留每個域的日誌。 那可能是很多日誌。 備份它們，因為它們很重要並刪除。

刪除不必要的網站安裝

您不想讓多餘的安裝佔用您的 inode 有兩個原因。 第一個是，嗯，你在不使用的東西上浪費了 inode。 第二個是被遺忘的網站容易受到重大安全威脅，並且是黑客通過蠻力攻擊進入共享服務器的最常見方式。

還記得我之前說過在我的個人託管計劃中安裝了 12 次 WP 嗎？ 嗯，這 12 個中的 8 個完全（或至少大部分）沒用。 其中，6 個可以放心刪除，2 個是佔位符。

每個 WordPress 安裝中有超過 5,000 個文件——至少有 5,000 個 inode——如果你做了任何事情來定制它或添加插件或主題......服務器。

包起來

用完主機上的 inode 令人討厭且具有破壞性。 即使您在達到容量之前很久就收到警告，您仍然需要花費大量時間從服務器中清除數據。 但是，如果您快速瀏覽上述所有提示，您應該能夠輕鬆地一次性將 inode 使用率降低至少 20%。

無論您使用的是 WordPress 還是其他一些 CMS，inode 使用情況可能不會經常出現，但是當它出現時，您會很高興自己已經準備好了。

您發現降低站點 inode 使用率的最佳方法是什麼？

文章特色圖片來自陌生鳥/shutterstock.com