Как я могу улучшить уровень удачного обращения в кэш nscd?

Моя Цель: Позвольте 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 записей. Выполнение a 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 будут кэшироваться, но рассмотрение "текущего количества кэшируемых значений", которого, кажется, не происходит также.

4
06.12.2013, 18:18
4 ответа

Какая часть Вашего веб-сервера даже делает поиски DNS? Большинство конфигураций веб-сервера явно отключает обратный поиск DNS каждого входящего пользователя для скорости (потому что DNS является медленным в целом).

Как Patrick отмечает, nscd делает правильную вещь и уважает положительные значения TTL. Да, Вы могли переопределить его (unbound позволил бы Вам сделать это легко, просто изменить server.cache-min-ttl, имеет предупреждения об увеличении его вне 1 часа по тем же причинам). ОДНАКО Ваши запросы, вероятно, главным образом rDNS, который будет иметь тенденцию иметь дольше TTLs в целом.

Кроме того, начиная с Вашего 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
3
27.01.2020, 20:50
  • 1
    Поиски DNS делаются так, чтобы верхнее управление видело имена DNS в их отчетах (сгенерированный от файлов журнала). Я предполагаю, что мог настроить BIND, чтобы сделать это, но мой вопрос состоит в том, как справиться nscd так как это в более общем плане полезно специально для материала как идентификатор пользователя и группы. –  Bratchley 09.12.2013, 16:49
  • 2
    Кроме того, я понимаю maximum number of cached values является низким, но я все еще думаю, что с частотой успешных обращений 6%, когда я установил TTL на 10 часов, приведет к большему кэшу, чем 17 кэшируемых значений хоста. Если бы существует способ заставить nscd содержать на записи дольше, это предпочтительно и минимизировало бы влияние обратного DNS. –  Bratchley 09.12.2013, 16:52
  • 3
    @JoelDavis просто с помощью BIND / несвязанный не собирается увеличивать частоту успешных обращений непосредственно. Я действительно вижу связанную проблему для Вас, если Вы делаете rDNS поиск позже от файлов журнала: нет никакого gaurentee, на который rDNS указывает на ту же запись теперь, когда это сделало, когда случай произошел. –  robbat2 09.12.2013, 20:03
  • 4
    Отмечание этого как ответ, так как я думаю, что это как близко к ответу, который вопрос делает возможным. спасибо –  Bratchley 10.12.2013, 21:17

Это может быть немного вне темы, но вместо использования nscd можно переключиться на sssd (который я рассматриваю его преемником).

Я использую его на SUSE Linux Enterprise Server 11.3 (полностью поддерживаемый), и я рад, что сделал переключатель. Это имеет намного больше и более прекрасные гранулярные параметры конфигурации, чем nscd и также имеет возможности, которые идут далеко вне какой nscd может достигнуть.

По крайней мере, я предполагаю, что это достойное внимания: https://fedorahosted.org/sssd/

2
27.01.2020, 20:50
  • 1
    Это находится на RHEL5, но когда мы обновляем сервер (вероятно, к RHEL7), я могу изучить его. Это интересно по большому количеству причин. Действительно ли SSSD может кэшировать UID в целом, или он просто делает кэширование DNS и аутентификация? –  Bratchley 10.12.2013, 21:14
  • 2
    Зарегистрированный #sssd на FreeNode и одном из devs сказал, что они все еще рекомендуют использовать что-то еще для кэширования DNS и упомянули unbound и nscd опции. Они действительно говорили, тем не менее, что это разработано для кэширования информации о группе и пользователя. –  Bratchley 10.12.2013, 22:43
  • 3
    Существует unscd также там; но сталкивается с той же корневой проблемой –  robbat2 10.12.2013, 22:46

nscd уважает восходящие значения TTL.

Если сервер DNS для google.com говорит что TTL для A запись google.com 10 секунд, и у Вас есть a positive-time-to-live из 36 000, запись все еще истечет через 10 секунд.

1
27.01.2020, 20:50
  • 1
    Существует ли способ переопределить это поведение? –  Bratchley 06.12.2013, 18:09
  • 2
    Вот ужасный путь: Вы могли отфильтровать входящий пакет ответа DNS с iptables, отправьте его в программу пространства пользователя (NFQUEUE цель), который затем подделает его для изменения TTL. –  Totor 06.12.2013, 23:34
  • 3
    , который я не рекомендовал бы этому, даже если бы это было возможно. Один сценарий: Когда серверы снижаются для обслуживания, они удалены из DNS. Администраторы будут затем ожидать записей DNS для истечения прежде, чем закрыть сам сервер вниз. Путем переопределения TTL Вы будете отправлять трафик на сервер, который мог быть закрыт. –  Patrick 07.12.2013, 02:56

Этот параметр:
да кэшируются, совместно используется

позволяет приложениям базироваться вокруг в кэше nscd, и такое действие не зарегистрировано. Это - ожидаемое и самое эффективное поведение.

Набор, что к НЕ и Вы будете видеть, что Ваша частота успешных обращений повышается существенно, но это несколько медленнее.

См.: http://alpacapowered.wordpress.com/2013/03/08/nscd-dns-caching-and-postfix/comment-page-1/#comment-1374

2
27.01.2020, 20:50

Теги

Похожие вопросы