「iノード」とは何ですか？それは私のWordPress Webサイトにどのように影響しますか？
公開: 2018-11-19WebサイトおよびWebホスティングの最も一般的な（そして誤解されている）要素の1つは、iノードです。 独自のWebサイトを運営している場合、または任意のレベルでメンテナンスを処理している場合は、ある時点でiノードを処理します。 それが定期的なメンテナンスによるものであれ、エラーの修正の試みによるものであれ、iノードとは何か、そしてそれがWordPressのインストールにどのように影響するかを知ることは、長期的な成功に不可欠です。
iノードとは何ですか？
非常に一般的な意味で、iノードはファイルシステム内の単一のファイルです。 ほとんどのユーザーにとって、これは、遭遇するほとんどすべての情報を処理するのに十分な情報です。
ただし、より技術的には、iノードはファイルのメタデータがUNIXシステムに保存される場所です（LinuxサーバーとAppleコンピューターはUNIXベースです）。 iノードは、ディレクトリおよびファイルによってリンクされるテーブルエントリです。iノードには、あらゆる種類の情報が含まれています。
このメタデータには、（1）ファイルのサイズ（バイト単位）とその物理的な場所（つまり、HDD上のファイルのデータを含むストレージブロックのアドレス）、（2）ファイルの所有者とグループ、（3）が含まれます。ファイルのアクセス許可（つまり、ユーザーがファイルの読み取り、書き込み、および/または実行を許可されている）、（4）iノードがいつ作成され、最後に変更され、最後にアクセスされたかを示すタイムスタンプ、および（5）ハードリンクの数を示す参照カウントリンクはiノードを指します。
ほとんどのWebサーバーはLinuxベースであるため、iノード管理が重要になります。 あなたはそれらがあなたのウェブサイトへのリンクであるかのようにそれらを考えることができます。 サイトの同じページを指す複数のリンクを持つことができますが、それはそのページの複数のコピーがあることを意味するものではありません。 同じことがファイルとiノードにも当てはまります。
技術的には1：1の関係はありませんが、1つのiノードにリンクされているファイルが1つしかない場合が多くあります。 ほとんどのユーザーは、自分の考えの下で作業できます。
iノードの問題
彼らは尽きます。 それらは有限です。 また、iノードの使用状況を追跡していない可能性があります。
少し前に、 Sitegroundから「警告：アカウントYourSite.comが許可されたiノードクォータの80％に達しました」という電子メールを突然受け取りました。 異常なことは何もしていませんでしたが、どういうわけか、iノードを塔のように積み上げていました。 ホスティングアカウントでWordPressの複数のインストールを実行している場合は、同様の電子メールを受け取っている（または受け取る予定です）と思います。
さて、電子メールでは、それらは非常に簡単です。iノードの数を減らすには、cPanel –ファイルマネージャーまたはお好みのFTPクライアントを介してアカウント上のファイルとフォルダーの数を減らす必要があります。 そして本質的に、それはあなたがしなければならないすべてです。 しかし、それよりも少し複雑です。ホストを長期間使用している場合は、ファイルとフォルダーのかなり適切なアーカイブがそこにある可能性があるためです。
iノードの使用状況を確認するには、cPanelにログインして、[統計]ボックスを探します。 cPanelのほとんどのバージョンでは、ページの左側のどこかにあります。 主にMBおよびGB単位のディスク使用スペース、許可されているiノードの数およびその時点で使用しているiノードの数が表示されます。
幸い、WordPressのほとんどの場合と同様に、CMSは、iノードの管理が比較的簡単になるようにまとめられています。
WordPressユーザーにとってiノードが重要な理由
多くの人は、iノードを操作する必要がない場合があります。 日常業務では、実際にはまったく気付かないでしょう。 すべてがあなたのサイトでうまくいっている限り、あなたがその言葉を見ることさえできるものは何もないはずです。 何かがうまくいかないとき、WordPressダッシュボードまたは他の場所にエラーが表示され始めます。
一般に、cPanelを使用するすべてのホスティングプロバイダー（マネージドホスティングを使用する場合を除いて、ほとんどのプロバイダー）は、パッケージに基づいて特定の数のiノードを割り当てています。 ルールは、一般的に、支払うほど、より多くのiノードを取得することです。
これは、使用しているストレージ容量とはまったく別のものであることに注意してください。 2つはボリュームが1：1程度の場合がありますが、iノードはほとんどのファイルよりもビットとバイトの点ではるかに小さいため、ストレージスペースが不足する前に、通常はiノードが不足します（ファイル自体の一部）。
そうは言っても、WordPressユーザーは、多くの場合、iノード中心の問題と戦っています。
WordPressユーザーがiノードを構築する方法
そこにあるすべてのCMSには、iノードを取り込む独自の方法がありますが、WordPressにはそのエコシステムに固有の方法がいくつかあります。 主に画像、プラグイン、テーマ。 掘り下げて、その理由とそれに対して何ができるかを調べてみましょう。
画像
メディアライブラリ内の画像は、おそらく大量のiノードを占有します。 あなたがそれらを何千も持っていなくても。 私はあなたのほとんどがあなたのサイトに画像をアップロードすることを賭けます。 そして理論的には、1つの画像は1つのiノードに相当します。 しかし、それは物事が実際にどのように機能するかではありません。 テーマと画像圧縮プラグインによっては、その1つの画像に12個近くのiノードが必要になる場合があります。 どのように？ 複数のサイズのレンダリングをストレージに保持する。
ライブラリ内の画像の詳細を確認してファイルサイズを確認すると、iノードです。 メディアライブラリ内のすべての画像について考えてみてください。 この特定のサイトでは、メディアライブラリに562個のアイテムがあります。 それぞれに11のバージョンがあると（おそらく間違って）仮定すると、6,000以上のiノードになります。 文字通りそれがどうあるべきか11倍。
そしてそれは1つのサイトのためです。 一般的なホスティングプランのサイトの数を考慮に入れると、その数は実際に合計される可能性があります。 私自身のアカウントでは、WordPressのインストールが12回実行されています。 各インストールのコアファイルに加えて、すべてのユーザーのメディアライブラリがiノードの使用量を増やします。
プラグインとテーマ
プラグインとテーマが非常に多くのiノードを使用する理由はいくつかあります。 1つ目は、非アクティブ化されていても、多くの人が大量にインストールしているということです。
そして、これらの各プラグインフォルダー内で、数十から数十のファイルがiノードを使用しています。 一部のプラグインは明らかに他のプラグインよりも軽量ですが、それらはすべてインストールにかさばりを追加します。 したがって、現在使用していないプラグインは削除するのが一般的にベストプラクティスであることを忘れないでください。
テーマはまったく同じように機能します。 あなたがかなりの時間それを持っていたならば、あなたがあなたのWordPressサイトにいくつのテーマをインストールしたかはわかりません。 これらのテーマが単にデフォルトのWordPressテーマである場合でも、多くのiノードが使用されています。 テーマを使用していない場合は、削除してください。 ただし、子テーマを使用してカスタマイズを行った場合は、親テーマほど簡単に再インストールすることはできないため、通常はそのままにしておく（またはバックアップを作成する）ことができます。
プラグインとバックアップユーティリティのキャッシュ
コメットキャッシュ。 WPRocket。 上昇気流。 iThemes。 WordFence。 WPスーパーキャッシュ。 W3トータルキャッシュ。 スクリ。
これらすべて（およびそれ以上）は、貴重なiノードを使用します。 ほとんどの場合、それは問題ありません。 それらはあなたの生活を楽にし、あなたのサイトでのユーザーの体験をより良くする素晴らしいプラグインです。 ただし、チェックを外したままにすると、キャッシュファイルとバックアップファイルおよびセキュリティレポートが蓄積される可能性があります。
そのため、時々、サイトのキャッシュをクリアして、それ自体を再作成するようにしてください。 時間のほとんどは、あなたがパージキャッシュまたはadminツールバーの[削除Cacheボタンを見つけることができます。
さらに、UpdraftPlusなどのプラグインからの追加のバックアップは貴重なスペースを占める可能性があります。 したがって、ローカルサーバーに何が保存されているかを確認してください。 これは、ほとんどのバックアップユーティリティのWP管理パネル内から実行できます。 または、FTP経由で確認できます。
これらのバックアップは、サーバー上のiノードとストレージスペースを占有するだけでなく、インストールに侵入する可能性のあるハッカーに対しても脆弱です。 したがって、それらをリモートの宛先（DropboxやGoogleドライブなど）に保持することが最善のアイデアになります。
一般的なiノードエラーを修正する方法
また、WordPressにはプラットフォーム固有のiノードの問題がありますが、Web全体で共通している問題がいくつかあります。 Drupal、Joomla、WordPress、さらにはGhostを使用している場合でも、ある時点でこれらを修正する必要がある場合があります。
- 電子メールは、従来のクライアント、オートレスポンダー、またはサイト自体のフォームから送信されません。
- メールを受信できません
- アップロードは常に失敗します
- 投稿とページは更新されず、作成もされません
- ユーザーはサイトにアクセスできません
- 場合によっては、あるホストから別のホストへの移行がブロックされることがあります
これらすべての場合において、原因は、サーバーがiノードクォータの上限に近づいていることです。 または、完全にiノードが不足していること。 ストレージ容量の一部しか使用していない場合でも、iノードを使い果たす可能性があることを忘れないでください。
電子メールが送受信されるたびに、ファイルが生成されます。 iノードがない場合、ファイルを作成できません。 iノードがいっぱいの場合、データを保存する場所がないため、アップロードは失敗します。 WordPressや他のCMSプラットフォームの投稿やページについても同じことが言え、スポットがないと必要なファイルを生成できません。 ユーザーがページにアクセスした場合でも、Cookie、トークン、キャッシュファイルなどのファイルが生成されます。 iノードがない場合、それらのユーザーは何も提供されません。
あるホストから別のホストに移行する場合、iノードの割り当てが異なる場合があります。 個人的に交換したのは私の最後でした。 したがって、現在の割り当てに近づいていない可能性があります。すでに次の割り当てを超えています。 苦痛のように聞こえるかもしれませんが、実際には簡単に修正できました。
これらの一般的なiノードエラーを修正するためにファイルを削除し、スペースを解放するための最良の方法は次のとおりです。
古いメールを削除する
ご覧のとおり、電子メールが送受信されるたびに、サーバー上にファイルが作成されます（外部メールサービスを使用していない場合）。 つまり、すべてのメールがiノードを使用しているということです。 メールをアーカイブするか、単に受信トレイに保持すると、メールはサーバー上に留まり、停滞します。 それで、それらを削除する時が来ました。 これは通常のクライアントで行うことも、FTPまたはcPanelのファイルマネージャーを介して行うこともできます。
サイトのルートディレクトリに移動して、メールフォルダを見つけるだけです。 その下には、メールアドレスを持っている各ドメインのディレクトリがあり、それぞれの下には、設定したエイリアスがあります。 これらのフォルダはそれぞれ重要であり、iノードを盗むファイルでいっぱいになる可能性があります。 ただし、主にcurと新しいディレクトリに関心があります。 時々ジャンク。
この1つのアドレスの新しい電子メールを削除した後、以前の218316iノードから218218に移行しました。 この電子メールアドレスはそもそもほとんど使用されなかったので、さらに大きな利益が得られるはずです。 削除する前に、すべてのメールをバックアップすることを忘れないでください。 そうでなければ、それらを取り戻すことはできません。
一時フォルダをクリアする
一時ファイルは素晴らしい獣です。 それらを見つける場所がわかっている場合は、それらが仕事をしていることを確認できますが、あまり多くのリソースを消費することはありません。 tmpディレクトリが表示される場合は常に、ここにそれらの一時ファイルが保存されます。 セッショントークン、キャッシュファイル、トラフィックログ、その時点では優れているが、後で目的を果たさないあらゆる種類のもの。
一時ファイルをクリアするために自動化またはCRONジョブを設定していない限り、たまに行って少しハウスキーピングを実行する必要があるかもしれません。 主に、これらはtmpの下のルートディレクトリにあります。
一般的な経験則として、ログファイル、キャッシュファイル、またはセッションファイルを削除できます。 ほとんどの場合、それらが非常に明確に記録されているのがわかります。 通常、ファイル名にはsess 、 cache、またはlogが含まれているため、作業が非常に簡単になります。
削除するファイルのほとんどは、サーバーログとトラフィックログになります。 これらのファイルのバックアップがある限り、 tmpフォルダーを調べて、必要なものを削除してください。 この特定の例では、 webalizer、webalizerftp、horde 、 awstats 、およびアナログディレクトリをクリアしています。 これらのファイルを削除するとサーバーの統計とログが削除されるため、必要に応じて最初にバックアップしてください。
日付も確認できます。 サイトによっては、2011年までログが必要ない場合があります。
さらに、プライマリtmpフォルダーにもいくつかのファイルがあります。 それらは、セッションファイル、ログファイル、およびその他の不明なファイルが混在している可能性があります。 コンピューターやWeb開発のすべてと同じように、それが何であるかわからない場合は、そのままにしておきます。 ただし、拡張子が.sockのファイルは削除しないことが非常に重要です。 そして、それほどではありませんが、 .lock 。
ログファイルをクリアする
tmpフォルダーと同様に、 logsフォルダーは、サーバーのログのアーカイブ時にアーカイブを含むルートディレクトリです。 サーバーは、ホスト上でアクティブにした月ごとに、各ドメインのログの保持を開始します。 それはたくさんのログになる可能性があります。 それらは重要であるため、それらのバックアップを作成し、削除します。
不要なWebサイトのインストールを削除する
iノードを占有する余分なインストールを望まない理由は2つあります。 1つ目は、使用していないものにiノードを浪費していることです。 2つ目は、忘れられたWebサイトは主要なセキュリティ脅威に対して脆弱であり、ハッカーがブルートフォース攻撃を介して共有サーバーに侵入する最も一般的な方法であるということです。
私の個人的なホスティングプランに12のWPのインストールがあったと以前に言ったことを覚えていますか？ ええと、それらの12のうち8つは完全に（または少なくともほとんど）役に立たないです。 そのうち6つは問題なく削除でき、2つはプレースホルダーです。
各WordPressインストールには5,000を超えるファイル（少なくとも5,000 iノード）があります。カスタマイズしたり、プラグインやテーマを追加したりした場合は、おそらく、私たちが何をしているのかを確認する必要があります。サーバ。
まとめ
ホストでiノードが不足すると、煩わしくて混乱を招きます。 容量に達するずっと前に警告が表示された場合でも、サーバーからデータを消去するにはかなりの時間をかける必要があります。 ただし、上記のすべてのヒントをすばやく実行すると、1回のパスでiノードの使用量を少なくとも20％簡単に減らすことができるはずです。
WordPressを使用している場合でも他のCMSを使用している場合でも、iノードの使用法はあまり頻繁に発生しない可能性がありますが、発生した場合は、準備ができていることを非常に嬉しく思います。
サイトでiノードの使用量を減らすための最良の方法は何だと思いますか？
記事特集画像strangebirdy / shutterstock.com