/ etc / hosts의 크기 제한 (Linux)

11

성능 저하를 시작하기 전에 Linux 시스템에서 / etc / hosts의 이론적 크기 제한이 무엇인지 아는 사람이 있습니까?

또한 누구나 예상 한도를 나타내는 공식 소스를 알려 줄 수 있습니까?

linux hosts

— MikeP90
소스

8

이것은 당신이 모범 사례 이외의 미친 짓이나 길을 가고 있다고 생각하게합니다. 세부 사항은 무엇입니까?

— ewwhite

3

가벼운 DNS 리졸버를 배포하는 것이 더 나은 솔루션 인 것 같습니다.

— Zoredache

1

요청한 고객이 있습니다. 나는 이것이 왜 문제를 일으키는 지 보여줄 수있는 문서를 찾고자했다. 테스트 머신에서 시도해 보지 말고 시연하십시오.

— MikeP90

1

hosts 파일은 1970 년대와 1980 년대 초의 DNS 이전 시대의 유물입니다. 호스트 파일에 수백 개의 항목이있는 것은 그다지 나쁜 생각으로 인식되지 않았습니다 . 10 개가 넘는 항목이 있다면 잘못된 경로 일 수 있습니다.

— Michael Hampton

9

소스를 사용하십시오 . Mike.

리졸버는 텍스트 파일을 통한 선형 검색을 사용하여 항목을 찾습니다. 인덱스가없는 데이터베이스입니다. 따라서 추가 캐싱 기능이없는 경우 조회 비용은 O (n)입니다. 그것이 성능 저하를 초래할 때, 대답하기 어려운 질문입니다-모든 기록마다 느려집니다.

데이터베이스 프로그래머 나 관리자에게 문의하면 인덱스 조회 (O (log2 (n))가 전체 테이블 스캔보다 저렴하다는 점에 대해 다른 수치를 얻을 수 있지만 일반적으로 대답은 20의 영역에 있습니다. 100 레코드까지.

모든 리눅스 시스템은 (호스트 이름뿐만 아니라) 많은 이름을 분석해야합니다. nscd 또는 이와 유사한 것을 실행해야합니다. 이러한 캐시는 대부분 데이터 자체를 인덱싱하여 성능 문제를 무효화합니다.

복잡한 / 대규모 데이터 세트를 관리 할 수단이 없습니다. 둘 이상의 IP 주소를 가진 호스트가있는 경우 호스트 파일을 통한 조회는 항상 첫 번째 항목을 반환합니다.

— Symcbean
소스

1

루프를 닫기 위해 hosts 파일에 170 만 레코드를 추가하고 각 조회에 0.5 초가 추가 된 것으로 추정했습니다. 이 환경에서는 0.5 초를 무시할 수 있습니다. DNS 서버가 여전히 더 나은 솔루션이라고 생각하지만 고객은 고객이 원하는 것을 원합니다.

— MikeP90

5

1984 년 DNS가 배포되기 전에 약간의 인터넷 기록이 호스트 파일만으로 이름을 확인할 수 있었으며 네트워크에 호스트가 많지 않았습니다 ( 1983 년 2 월 325 번 ) (RFC 847) . internet-history maillist 의 아카이브에는 1982 년부터 HOSTS.TXT (머신을 읽을 수는 없지만) 사본이 있습니다 . 대체 HOSTS.TXT (Geoff Goodfellow 's)도 있었습니다.

— 보내다
소스

3

기술적으로 상한은 없습니다. 그러나 모든 DNS 조회가이 파일에 도달 할 것이므로 왜 그 파일을 열어 두어야합니까?

그 가치에 대해, /etc/hosts내가 환경에서 배포 한 가장 큰 파일은 1,200 줄이었습니다. 그리고 그것은 내가 관리하고있는 응용 프로그램에서 잘 작동했습니다. 특정 환경에서는 DNS가 옵션이 아니 었습니다.

— ewwhite
소스

다른 방법으로 봅시다. 커널에 인덱싱이 없으면 각 적중은 타이밍이 진행되는 한 캐시 크기에 따라 선형 검색을 수행합니다.

— 사슴 사냥꾼

4

인터넷에서 발견되는 인기있는 호스트 파일을 사용하는데 15,430 줄이 있으며 웹 서핑 성능이 실제로 저하되지 않습니다.

— Bert

@ DeerHunter 유닉스 커널에는 호스트 이름 조회를 수행하는 것이 없다고 생각합니다.

— Barmar

버트 쪽지 +1 방금 22,000 줄의 사용자 정의 파일을 사용했는데 성능에 영향을 미치지 않았습니다. 테스트 목적으로 유용합니다!

— Josh koenig