/ etc / hostsのサイズ制限（Linux）

11

パフォーマンスの低下が見られる前に、Linuxシステムでの/ etc / hostsの理論上のサイズ制限が誰かに気付いたことがありますか？

さらに、予想される制限が何であるかを述べている公式ソースに誰かを向けることができますか？

linux hosts

— マイクP90
ソース

8

これは、あなたが何かおかしなことをしている、またはベストプラクティス以外の方法をしていると思わせます。詳細は何ですか？

— ewwhite

3

確かに、ここでは軽量のDNSリゾルバを展開する方がより良いソリューションのようです。

— ゾレダチェ

1

これを要求している顧客がいます。私は、なぜこれが問題を引き起こすのかを示すことができるドキュメントを見つけたいと思っていました。テストマシンで試して実証する代わりに。

— MikeP90

1

hostsファイルは、1970年代から1980年代初期のDNS以前の時代の遺物です。ホストファイルに数百のエントリを持つことは、ずっと前の悪い考えとして認識されました。エントリが10個を超えている場合は、おそらく間違った方向に進んでいます。

— マイケルハンプトン

9

ソース、マイクを使用してください。

リゾルバは、テキストファイル全体の線形検索を使用してエントリを見つけます。インデックスのないデータベースです。したがって、追加のキャッシング機能がない場合、ルックアップのコストはO（n）になります。いつパフォーマンスが低下するかについては、答えるのは不可能な質問です。レコードごとに遅くなります。

データベースプログラマーまたは管理者と話をすると、インデックスルックアップ（O（log2（n））がフルテーブルスキャンよりも安くなるポイントについて異なる数字が得られますが、一般的には20の領域に答えがあります100レコードまで。

多くの名前（ホスト名だけでなく）を解決する必要があるLinuxシステム。nscdなどを実行している必要があります。そのようなキャッシュのほとんどは、パフォーマンスの問題を無効にするデータ自体にインデックスを付けます...

複雑/大規模なデータセットを管理する手段を提供しません-複数のIPアドレスを持つホストがある場合、hostsファイルを介したルックアップは常に最初のエントリを返します。

— シンビアン
ソース

1

ループを閉じるために、170万件のレコードをhostsファイルに追加し、各ルックアップに0.5秒を追加すると推定しました。この環境では、0.5秒は無視できます。DNSサーバーは依然として優れたソリューションだと思いますが、顧客は顧客が望むものを望んでいます。

— MikeP90

5

少しのインターネットの歴史-1984年にDNSが展開される前は、ホストファイルのみが名前を解決し、ネットワーク上にホストはあまりありませんでした-1983年2月に325 （RFC 847）。インターネット履歴メールリストのアーカイブには、1982年のHOSTS.TXTのコピー（ただし、機械可読ではありません）があります。代替のHOSTS.TXT （Geoff Goodfellow's）もありました。

— sendmoreinfo
ソース

3

技術的には、上限はありません。ただし、すべてのDNSルックアップがこのファイルにヒットするので、なぜそれを受け入れないのでしょうか？

価値のある/etc/hostsことですが、私の環境で配布した最大のファイルは1,200行でした。そして、それは私が管理していたアプリケーションにとってはうまくいきました。DNSは、その特定の環境ではオプションではありませんでした。

— ewwhite
ソース

別の言い方をしましょう。カーネルにインデックス付けがない場合、各ヒットは、タイミングが進む限りキャッシュサイズに依存する線形検索を実行します。

— 鹿ハンター

4

私はインターネット上で見られる人気のあるhostsファイルを使用しますが、15,430行あり、ウェブサーフィンのパフォーマンスに実際の低下はありません。

— バート

@DeerHunter Unixカーネルにはホスト名検索を実行するものはないと思います。

— バーマー

バートのメモに+1。22,000行のカスタムファイルを使用しましたが、パフォーマンスには影響しません。これはテスト目的に役立ちます！

— ジョシュケーニッヒ