내 목표:nscd가 사용 가능한 메모리가 있으므로 초과 메모리에 상당한 규모의 DNS 캐시를 유지하도록 합니다.
설명하다:
저는 광범위하게 분산되어 있지만 매우 반복적인 사용자 기반을 갖춘 웹 서버를 보유하고 있습니다. 메모리가 충분하므로 조회를 캐싱하여 응답 시간을 향상시킬 수 있다고 생각했지만, nscd -g캐시 적중률이 6%에 불과하다고 들었습니다. 즉, nscd캐시에 더 많은 대기 시간이 발생하거나 네트워크를 통해 차단하는 대신 결코 찾을 수 없는 항목을 찾습니다.
hosts cache:
yes cache is enabled
yes cache is persistent
yes cache is shared
211 suggested size
216064 total data pool size
2328 used data pool size
36000 seconds time to live for positive entries
20 seconds time to live for negative entries
4455 cache hits on positive entries
0 cache hits on negative entries
17357 cache misses on positive entries
42348 cache misses on negative entries
6% cache hit rate
17 current number of cached values
40 maximum number of cached values
3 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/hosts for changes
6% 적중률의 중요한 요소는 17개 항목만 캐시한다는 것입니다. 를 실행하면 strings /var/db/nscd/hosts생성된 호스트 캐시 항목이 주로 내부 네트워크의 컴퓨터에 대한 것임을 보여줍니다. 사이트를 매일 다시 게시하면 작업 속도가 빨라질 수 있으므로 이를 캐싱하는 것이 좋지만 실제 구성을 변경하지 않고도 최종 사용자 경험의 속도를 높이는 것이 목표입니다.
이는 다음과 관련된 부분입니다 nscd.conf.
threads 10
server-user nscd
debug-level 0
paranoia no
[.....snip......]
enable-cache hosts yes
positive-time-to-live hosts 36000
negative-time-to-live hosts 20
suggested-size hosts 10657
check-files hosts yes
persistent hosts yes
shared hosts yes
max-db-size hosts 33554432
기본적으로 호스트 캐시의 양수 TTL을 매우 높게 설정했음에도 불구하고 호스트 캐시가 왜 그렇게 작은지 이해하는 데 도움이 필요합니다. 실제 캐시 항목 수가 적기 때문에 적중률이 너무 낮아지는 것은 확실합니다.
적중률을 6%로 가정하고 있지만 양의 TTL이 상당히 크므로 현재 작업 부하를 의미합니다.예DNS 호스트 조회가 수행되지만 저장되지는 않습니다. 왜 저장되지 않는지, 다음에 무엇을 확인해야 할지 모르겠습니다. 지금 내가 기대하는 것은 상당히 큰 DNS 캐시일 것입니다.
적중률이 여전히 작더라도(예: 고객이 생각만큼 자주 반복하지 않음), 나는 여전히 기대합니다.그것들DNS 조회는 캐시되어 있지만 "현재 캐시된 값의 수"를 보면 역시 발생하지 않는 것 같습니다.
답변1
웹 서버의 어떤 부분이 DNS 조회를 수행하고 있습니까? 대부분의 웹 서버 구성은 속도를 높이기 위해 들어오는 각 사용자에 대한 역방향 DNS 조회를 명시적으로 비활성화합니다(DNS는 종종 느리기 때문입니다).
Patrick이 지적했듯이 nscd는 올바른 일을 하고 있으며 양의 TTL 값을 존중합니다. 예, 재정의할 수 있습니다( unbound이 작업을 쉽게 수행할 수 있습니다. 수정하기만 하면 됩니다 server.cache-min-ttl. 같은 이유로 1시간 이상으로 늘리면 경고가 표시됩니다). 그러나 귀하의 쿼리는 일반적으로 TTL이 더 긴 경향이 있는 rDNS일 가능성이 높습니다.
또한 maximum number of cached values트래픽이 너무 적기 때문에 트래픽이 거의 발생하지 않는다는 점을 지적하고 싶습니다.
사용자의 자주 반복되는 위치에 관심이 있다면 nscd 외부에 기록하고 다시 걱정할 필요가 없도록 권장합니다.
편집(2013/12/09):
nscd -g호스트 통계 dev.gentoo.org(댓글에 블록 없음):
nscd configuration:
4h 8m 43s server runtime
hosts cache:
yes cache is enabled
no cache is persistent
no cache is shared
422 suggested size
1108744 total data pool size
966632 used data pool size
600 seconds time to live for positive entries
20 seconds time to live for negative entries
67878 cache hits on positive entries
2479 cache hits on negative entries
9464 cache misses on positive entries
4276 cache misses on negative entries
83% cache hit rate
6951 current number of cached values
7641 maximum number of cached values
33 maximum chain length searched
1 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/hosts for changes
답변2
이 매개변수:
예, 캐시는 공유됩니다
애플리케이션이 nscd의 캐시에 뿌리를 내릴 수 있도록 허용하며 이러한 활동은 기록되지 않습니다. 이는 예상되고 가장 유효한 동작입니다.
"아니요"로 설정하면 적중률이 극적으로 증가하지만 속도는 느려집니다.
답변3
주제에서 약간 벗어난 것일 수도 있지만 대신 (내 생각에 후속 제품) nscd로 전환할 수 있습니다 .sssd
저는 SUSE Linux Enterprise Server 11.3(완전히 지원됨)에서 이 제품을 사용하고 있는데 전환하게 되어 기쁩니다. 더 많고 세분화된 구성 옵션이 있으며 nscd가능한 것보다 훨씬 뛰어난 nscd기능을 갖추고 있습니다.
적어도 나는 한 번 살펴볼 가치가 있다고 생각합니다.https://fedorahosted.org/sssd/
답변4
nscd는 업스트림 TTL 값을 존중합니다.
Agoogle.comgoogle.com의 DNS 서버가 레코드에 대해 TTL을 10초로 지정하고 TTL positive-time-to-live이 36000인 경우에도 레코드는 10초 후에 만료됩니다.