Обмеження розміру / etc / hosts (Linux)

11

Хтось знає, що таке теоретична межа розміру / etc / hosts в системі Linux, перш ніж ви зможете побачити погіршення продуктивності?

Крім того, чи може хтось вказати мені на якесь офіційне джерело, в якому зазначено, яка очікувана межа?

linux hosts

— MikeP90
джерело

8

Це змушує мене думати, що ти робиш щось божевільне або ШЛЯХОМ поза межами найкращих практик. Які деталі?

— ewwhite

3

Звичайно, здається, що розгортання легкого DNS-рішення може бути кращим рішенням.

— Зоредаче

1

У мене є клієнт, який просить цього. Я сподівався знайти якусь документацію, щоб я міг показати їм, чому це спричинить проблеми; замість того, щоб спробувати це на тестовій машині та продемонструвати.

— MikeP90

1

Файл хостів - це пережиток днів до DNS 1970-х та початку 1980-х років. Наявність сотень записів у файлі хостів було визнано поганою ідеєю ще далеко . Якщо у вас є більше 10 записів у вашому, ви, ймовірно, не так.

— Майкл Хемптон

9

Використовуй джерело , Майк.

Роздільник використовує лінійний пошук по текстовому файлу для пошуку записів. Це база даних без індексів. Отже, за відсутності можливості керування додатковим кешуванням витрати на пошук будуть O (n). Що стосується того, коли це призведе до погіршення продуктивності, на це неможливо відповісти - це стає повільніше з кожним записом.

Якщо ви розмовляєте з програмістом бази даних або адміністратором, ви отримаєте різні цифри для точки, в якій пошук індексу (O (log2 (n)) дешевший, ніж повне сканування таблиці, але загалом відповідь буде в районі 20 до 100 записів.

Будь-яка система Linux, яка потребує вирішення багатьох імен (не лише імен хостів). Повинно працювати з nscd або подібним. Більшість таких кеш-файлів самі індексуватимуть дані, що зведе нанівець питання про продуктивність, однак ...

Він не дає можливості керувати складними / великими наборами даних - якщо у вас хост з більш ніж однією IP-адресою, пошук за допомогою файлу hosts завжди поверне перший запис.

— симбічний
джерело

1

Щоб закрити цикл, ми додали 1,7 мільйона записів у файл хостів і підрахували, що він додав 5,5 секунди до кожного пошуку. У цьому середовищі .5 секунд незначно. Я думаю, що сервер DNS все ще є кращим рішенням, але клієнт хоче того, що хоче клієнт.

— MikeP90

5

Трохи історії Інтернету - до розгортання DNS у 1984 році файл хостів був єдиним, щоб вирішувати імена, а хостів у мережі не було багато - 325 в лютому 1983 (RFC 847) . Є копії HOSTS.TXT (хоча машинно не читаються) з 1982 року в архіві журналу інтернет-історії . Був навіть альтернативний HOSTS.TXT (Geoff Goodfellow's) .

— sendmoreinfo
джерело

3

Технічно немає верхньої межі. Однак кожен пошук DNS збирається потрапити в цей файл, тож навіщо залишати себе відкритим для цього?

Оскільки це варте, найбільший /etc/hostsфайл, який я розповсюдив у своїх середовищах, був 1200 рядків. І це добре працювало для програми, якою я керував. DNS не був варіантом у цьому конкретному середовищі.

— ewwhite
джерело

Давайте по-іншому. Якщо в ядрі немає індексації, кожне звернення здійснюватиме лінійний пошук, який залежатиме від розміру кешу, наскільки йде час.

— Мисливець на оленів

4

Я використовую популярний файл хостів, знайдений в Інтернеті, є 15,430 рядків, і я не помічаю реального погіршення продуктивності веб-серфінгу.

— Берт

@DeerHunter Я не думаю, що в ядрі Unix є щось, що виконує пошук імені хоста.

— Вармар

+1 до записки Берта. Я просто використав користувальницький файл з 22 000 рядків, і це не вплинуло на продуктивність. Це корисно для тестування!

— Джош Коніг