Nscd linux что это
📑 Nscd — служба, которая кэширует запросы службы имён
Nscd — это демон (сервис), который предоставляет кэш для наиболее общих запросов службы имен. По умолчанию, поведение демона кэша определяет файл с настройками /etc/nscd.conf.
Установка сервиса (демона) nscd в Linux Ubuntu:
Можно посмотреть, что вообще происходит с кешем:
и список закешированных доменов
Nscd предоставляет кэширование для баз данных passwd, group, и hosts через стандартные интерфейсы libc, такие как getpwnam, getpwuid, getgrnam, getgrgid, gethostbyname, и другие.
Каждый кэш имеет для своих данных отдельное TLL (time-to-live — время жизни); изменения в локальной базе данных (/etc/passwd, и других) приводит к тому что кэш становится неправльным в течении пятнадцати секунд.
Файл /etc/nscd.conf читается демоном nscd при его запуске. Каждая строка задаёт или атрибут и значение, или атрибут, службу и значение. Поля разделяются или пробелами или символами табуляции. Символ # (решётка) говорит от начале комментария; следующие за ним до конца строки символы, не интерпретируются nscd.
Задаёт имя файла, в который будет записываться отладочная информация.
Устанавливает необходимый уровень отладки.
Здесь указывается число тредов (нитей) которые запускаются для ожидания запросов. Всегда создаются как минимум пять тредов.
positive-time-to-live service value
negative-time-to-live service value
suggested-size service value
Задаёт размер внутренней хэш-таблицы, значение value для оптимальной эффективности должно бы быть простым числом.
Stable IT
FastNetMon
Thursday, 22 April 2010
Использование nscd на CentOS / Debian
real 0m16.113s
user 0m0.003s
sys 0m0.002s
real 0m16.215s
user 0m0.001s
sys 0m0.002s
Ставим nscd, который суперски умеет кэшировать запросы к DNS
Активируем запуск при загрузке:
Статистику работы nscd можно узнать командой:
Через несколько суток работы nscd на одном из наших хостинг-серверов было получены следующие значения:
0 server debug level
4d 17h 21m 20s server runtime
8 current number of threads
32 maximum number of threads
0 number of times clients had to wait
no paranoia mode enabled
3600 restart internal
yes cache is enabled
yes cache is persistent
yes cache is shared
211 suggested size
216064 total data pool size
18296 used data pool size
600 seconds time to live for positive entries
20 seconds time to live for negative entries
26303 cache hits on positive entries
0 cache hits on negative entries
18186 cache misses on positive entries
36 cache misses on negative entries
59% cache hit rate
190 current number of cached values
542 maximum number of cached values
7 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/passwd for changes
yes cache is enabled
yes cache is persistent
yes cache is shared
211 suggested size
216064 total data pool size
17648 used data pool size
3600 seconds time to live for positive entries
60 seconds time to live for negative entries
3283 cache hits on positive entries
0 cache hits on negative entries
4439 cache misses on positive entries
67 cache misses on negative entries
42% cache hit rate
245 current number of cached values
268 maximum number of cached values
8 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/group for changes
no cache is enabled
yes cache is persistent
yes cache is shared
0 suggested size
0 total data pool size
0 used data pool size
3600 seconds time to live for positive entries
20 seconds time to live for negative entries
0 cache hits on positive entries
0 cache hits on negative entries
0 cache misses on positive entries
0 cache misses on negative entries
0% cache hit rate
0 current number of cached values
0 maximum number of cached values
0 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
yes cache is enabled
yes cache is persistent
yes cache is shared
211 suggested size
216064 total data pool size
1432 used data pool size
28800 seconds time to live for positive entries
20 seconds time to live for negative entries
32 cache hits on positive entries
0 cache hits on negative entries
15 cache misses on positive entries
1876 cache misses on negative entries
1% cache hit rate
9 current number of cached values
26 maximum number of cached values
2 maximum chain length searched
0 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/services for changes
А вот потребление памяти:
Теперь тестируем скорость работы DNS:
real 0m27.112s
user 0m0.003s
sys 0m0.001s
real 0m0.107s
user 0m0.001s
sys 0m0.001s
real 0m0.106s
user 0m0.001s
sys 0m0.001s
real 0m0.105s
user 0m0.000s
sys 0m0.002s
Теперь если отключить nscd, проблема вернется:
real 0m22.109s
user 0m0.000s
sys 0m0.003s
nscd умеет кэшировать не только DNS запросы, но и кучу всяких других тяжелых операций, выполняемых из libc, например: getpwnam, getpwuid, getgrnam, getgrgid, gethostbyname (как раз DNS).
Nscd provides caching for accesses of the passwd(5), group(5), and hosts(5)
databases through standard libc interfaces, such as getpwnam(3), getpwuid(3),
getgrnam(3), getgrgid(3), gethostbyname(3), and others.
Причем, не стоит бояться ошибок кэширования, так как он очень умный:
Bog BOS: Сервер кеширования имен (nscd)
Результаты разрешения имен хостов, пользователей и групп пользователей стандартными функциями libc (glibc) сервисами имен (про переключение сервисов имен см. NSS) в операционных системах Solaris и Linux могут кэшироваться с помощью сервера nscd. nscd кеширует результаты, полученные NSS.
Прикладная программа, которой необходимо, например, получить адрес хоста по его имени, вызывает подпрограмму gethostbyname(3) или аналогичную. При сборке программы к ней прилинковываются подпрограммы из библиотеки libc (glibc), которые проверяют наличие требуемой информации в кеше nscd (если, конечно, запущен сервер nscd). Если информацию из кеша извлечь не удалось, то используется NSS для определения сервиса имен, который (которые) будет использован для поиска адреса по имени. В общем случае, таким сервисом служит DNS клиент (resolver).
Кеширование имен пользователей и групп пользователей имеет смысл, если для их разрешения используется некий сетевой сервис (NIS или NIS+). Кеширование имен хостов очень полезно, если на хосте не запущен локальный сервер DNS (уровень кеширования имен хостов на почтовом сервере достигает 92%).
В Solaris сервер /usr/sbin/nscd и скрипты запуска устанавливаются по умолчанию. Скрипт запуска /etc/init.d/nscd имеет опции start и stop. Для запуска и остановки создаются соответствующие ссылки:
В Red Hat Linux и совместимых с ним (ядро не ниже 2.2!) сервер /usr/sbin/nscd и скрипт запуска /etc/rc.d/init.d/nscd входят в состав пакета ncsd-*.rpm (кстати, исходные тексты пакета берутся из glibc-*.srpm). nscd реализован в виде многопоточного процесса, общающегося с включаемой в glibc клиентской частью с использованием unix-сокета /var/run/.nscd_socket (права 0666, кто-нибудь пробовал записать туда мусор?). Для предотвращения повторного запуска используется файл /var/run/nscd.pid. Опции скрипта: start, stop, status, restart, reload. Для запуска и остановки создаются соответствующие ссылки (управление через chkconfig):
Посмотреть статистику (в Linux возможность доступна только root и не показывается уровень заполнения таблиц):
При изменении настройки NSS или DNS-клиента сервер nscd требуется перезапустить.
В некоторых версиях имена хостов, имеющих несколько адресов, не кешируются, чтобы не мешать балансировке нагрузки удалекнного сервера.
Каждая строка файла конфигурации задант значение некоторого атрибута. Действие оператора может быть ограничено пределами одной таблицы (hosts, passwd, groups). Комментарии начинаются символом # и завершаются концом строки.
Конфигурация по умолчанию расчитана на работу в составе рабочей станции, а не на сервера. Имена пользователей и групп пользователей у меня почти не используются, да и NIS не запущен), а вот кеширование имен хостов используется на сервере интенсивно, так что настройку таблицы хостов я сделал такую (кстати, она максимальная для Solaris по количеству позиций в таблице и количеству горячих позиций):
win-linux
В операционной системе linux, так же как и в Windows, кроме обычных программ, которые могут взаимодействовать с пользователем есть еще один вид программ. Это работающие в фоне службы. Важность служб тяжело переоценить, они следят за состоянием системы, обеспечивают автоматическое подключение внешних устройств и сети
, позволяют процессам взаимодействовать с оборудованием (dbus), а также в виде служб реализованы различные веб-серверы и серверы баз данных.
В отличие от пользовательских программ, службы выполняются в фоне, и пользователь не имеет к ним прямого доступа. Пользователь еще не вошел в систему, только началась загрузка а основные службы уже запущенны и работают.
Скрипты запускаемых служб в линукс располагаются в /etc/rc.d/init.d или /etc/init.d в зависимости от дистрибутива.
Всего в линукс существует 7 уровней запуска:
0 — остановка системы
1 — однопользовательский режим
2 — многопользовательский режим без поддержки сети
3 — многопользовательский режим с поддержкой сети
4 — не используется
5 — графический режим
6 — перезагрузка системы
Каждому из этих уровней соответствует своя папка (rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d) их вы можете найти вот по этому пути /etc/. В каждой из них находятся ссылки на определенные скрипты из папки /etc/rc.d/init.d или /etc/init.d в зависимости от дистрибутива.
Теперь разберемся с названиями скриптов и что именно они обозначают:
Например: S20hddtemp
S — обозначает что этот скрипт будет запускаться
20 — обозначает что он будет запускаться между другими скриптами с большим и меньшим значением этого параметра. т.е. если у нас есть 3 скрипта S05preload, S20hddtemp, S35vbox
сначала запуститься скрипт со значанием (05), потом (20) и только после этого (35).
hddtemp — это название скрипта
Чтобы отключить скрипт нужно вместо буквы S поставить букву K.
Например: если у нас было S20hddtemp, нужно чтобы получилось K20hddtemp. Чтобы это сделать можно использовать либо графические программы(bum, rcconf и тд..) либо сделать это через консоль написав команду:
Разделяемая память, семафоры и очереди сообщений в ОС Linux
Разделяемая память
Каналы и сокеты являются удобными средствами обмена информацией между процессами, но их использование при интенсивном обмене или обмене объемными данными приводит к значительным накладными расходам. Разделяемая память является специализированным средством взаимодействия, имеющим минимальные издержки использования.
В листинге ниже при помощи команды ipcs показаны созданные в системе сегменты разделяемой памяти, массивы семафоров и очереди сообщений — средства межпроцессного взаимодействия svipc, «унаследованные» Linux от W:[UNIX System V].
Экземпляры средств System VIPC идентифицируются при помощи глобально уникальных ключей, или локальных идентификаторов shmid (shared memory identifier), semid (semaphore identifier) и msqid (message queue identifier), и сродни файлам имеют владельцев и права доступа.
Идентификаторы IPC (сродни индексным и файловым дескрипторам файлов) изменяются при пересоздаиии/переоткрытии экземпляра, а ключи IPC (подобно именам файлов) — нет.
Разделяемая память, очереди сообщений и семафоры (System V IPC)
$ ipcs
—— Сегменты совм. исп. памяти ——
ключ shmid владелец права байты nattch состояние
0x00000000 11567165 fitz 600 393216 2 назначение
0X06000000 10944514 fitz 700 1694060 2 назначение
6×06000606 11206666 fitz 600 393216 2 назначение
—— Массивы семафоров ——
ключ semid владелец права nsems
—— Очереди сообщений ——
ключ msqid владелец права исп. байты сообщения
Разделяемая память System VIPC реализуется ядром на основе механизма страничного отображения при помощи совместного использования страничных кадров страницами разных процессов.
При помощи системного вызова shmget один из взаимодействующих процессов создает сегмент памяти, состоящий из страничных кадров без отображения на какой-либо файл. Впоследствии кадры этого сегмента при помощи системного вызова shmat (shared memory attach) отображаются на страницы всех взаимодействующих процессов, за счет чего эти процессы и используют выделенную память совместно.
Иллюстрация применения разделяемой памяти приведена в листинге ниже, где сегмент разделяемой памяти с идентификатором 842138010 был создан (cpid, creator pid) процессом PID=8636 программы Х-клиента skype, а последнее обращение к нему (lpid, last operation pid) осуществлялось процессом PID=1461 программы X-сервера Xorg.
В данном конкретном случае X-клиент и X-сервер для эффективного обмена значительными объемами растровых изображений используют расширение X-протокола W: [MIT-SHM], основанное на использовании разделяемой памяти.
Разделяемая память (System V IPC)
—— Shared Memory Creator/Last-op PIDs ——
shmid владелец cpid ipid
11567105 fitz 16738 31382
10944514 fitz 4207 1461
8421380 fitz 8636 1461
99e23000 2176K rw-s- [ shmld=0x838005 ]
9a043000 3828K rw-s- [ shmld=0x830006 ]
9cc2f000 484K rw-s- [ shnld=0x828007 ]
9f541000 384K rw-s- [ shnlct=0x808004 ]
bf905000 132K rw— [ stack ]
total 632708K
b5a5a000 384K rw-s- [ shmid=0xb28003 ]
b5abaeoe 384K rw-s- [ shmid=0x808004 ]
b5b3e000 384K rw-s- [ shmid=0xab000a ]
bfcd9000 144K rw— [ stack ]
total 107220K
Анализ карт памяти взаимодействующих процессов при помощи команды pmap подтверждает, что Страничные кадры сегмента разделяемой s памяти 842138016 (80800416) были отображены на страницы обоих взаимодействующих процессов по разным виртуальным адресам.
Еще один вариант реализации разделяемой памяти, пришедший в Linux из W:[BSD], основывается на «разделяемом» (shared) отображении одного файла в память разных процессов при помощи «штатного» механизма mmap. В листинге ниже показан типичный пример использования совместного отображения файла /var/cache/nscd/hosts в память процесса PID = 14566, nscd (name service cache daemon) и многих других процессов, пользующихся его услугами.
Служба имен (name service) предназначена для извлечения свойств различных каталогизируемых сущностей по их имени. Например, по имени интернет-узла из каталога системы доменных имен DNS служба имен извлекает IP-адрес этого узла, и наоборот, по IP-адресу — имя.
При большом количестве повторяющихся запросов к службе имен в течение промежутка времени, в который изменения запрашиваемой информации в соответствующем каталоге объектов не происходит, «бесполезные» повторные запросы к каталогу могут быть сокращены при помощи сохранения и использования предыдущих ответов (кэширования), чем и занимается демон nscd.
В частности, ответы из DNS сохраняются, процессом nscd в страничных кадрах памяти отображенного файла /var/cache/nscd/hosts, а остальные процессы совместно их используют, отображая тот же файл в страницы своей памяти.
Разделяемая память (BSD)
ПОЛЬЗ-ЛЬ PID ДОСТУП КОМАНДА
/var/cache/nscd/hosts:
root 14566 F…m nscd
fitz 16724 ….m ubuntu-geoip-pr
fitz 16738 ….m chromium-browse
fitz 15895 …m unity-scope-vid
$ sudo pmap 14566
14566: /usr/sbin/nscd
b1240000 32768K rw-s- /var/cache/nscd/hosts
bf8c5000 132K rw— [stack ]
total 153556K
$ pmap 8636
8636: skype
ab21e000 212K r—s- /var/cache/nscd/hosts
bf905000 132K rw— [ stack ]
total 632708K
Организация межпроцессного взаимодействия при помощи разделяемой памяти на основе «штатного» механизма отображения файлов в память процессов имеет один значительный недостаток. Так как изменяемые страничные кадры такого общего сегмента памяти требуют сохранения в дисковый файл, то производительность взаимодействия ограничивается операциями дискового ввода-вывода, а не скоростью работы оперативной памяти.
В примере с демоном nscd этого вполне достаточно, тем более что создаваемый им кэш все равно должен сохраняться при перезагрузках.
В случаях, когда взаимодействие процессов требует максимальной производительности, разделяемая память на основе отображения дисковых файлов в память является не лучшим механизмом. Элегантное решение данной проблемы используется в Linux-реализации разделяемой памяти стандарта POSIX, что проиллюстрировано в листинге ниже.
Псевдофайловая система tmpfs специально придумана для «временного» размещения файлов непосредственно в оперативной памяти, что в совокупности со «штатным» механизмом их отображения в память взаимодействующих процессов и дает желаемые характеристики производительности.
Разделяемая память (POSIX)
$ find mnt /dev/shn
TARGET SOURCE FSTYPE OPTIONS
/rw/shm tmpfs rw, nosuid, nodev, relatime
/run/shm/pulse-shm-2024923292:
fitz 2907 ….m pulseaudio
fitz 8636 ….m skype
$ pmap 8636
8636: skype
93cee000 65540K rw-s- /run/shm/pulse-shm-2024923292
bf905000 132K rw— [ stack ]
total 632708K
$ pmap 2907
2907: /usr/bin/pulseaudio — start — log-target=syslog
ad4ff000 65540K r—s- /run/shm/pulse-shm-2024923292
ad5a5000 64K rw-s- /dev/snd/pcmC0D0c
b15ес000 64K rw-s- /dev/snd/pcnC0O0p
bfel5000 132K rw— [ stack ]
total 167156K
В примере из листинга выше показано, как разделяемую память POSIX использует звуковая служба pulseaudio, позволяющая осуществлять совместный (мультиплексированный) доступ приложений к устройствам аудиоввода и аудиовывода /dev/snd/*.
Семафоры и очереди сообщений
Разделяемая память требует синхронизации действий процессов из-за эффекта гонки (race), возникающего между конкурентными, выполняющимися параллельно процессами. Для синхронизации процессов при совместном доступе к разделяемой памяти и прочим разделяемым ресурсам предназначено еще одно специализированное средство их взаимодействия — семафоры.
В большинстве случаев семафорами System V или POSIX пользуются многопроцессные сервисы, такие как, например, SQL-сервер postgres, который синхронизует доступ своих параллельных процессов к сегментам их общей памяти.
Семафоры (System V IPC)
——- Сегменты совм. исп. памяти ——
ключ shmid владелец права байты nattch состояние
0х0052е2с1 378241026 postgres 600 30482432 4
—— Массивы семафоров ——
ключ shmid владелец права nsems
0х0052е2с1 1081344 postgres 600 17
0х0052е2с2 1114113 postgres 600 17
0х0052е2сЗ 1146882 postgres 600 17
0х0052е2с4 1179651 postgres 600 17
0х0052е2с5 1212420 postgres 600 17
0х0052е2с6 1245189 postgres 600 17
0х0052е2с7 1277958 postgres 600 17
Очереди сообщений являются средствами взаимодействия между процессами, реализующими еще один интерфейс передачи сообщений (message passing inerface), подобно каналам и сокетам. По своей природе они похожи на дейтаграммный SOCK_DGRAM режим передачи поверх именованных локальных сокетов unix.
Основное отличие очередей сообщений от сокетов заключается в том, что время их жизни не ограничивается временем существования процессов, которые их создали. На практике очереди сообщений являются настолько малораспространенными, что их иллюстрация на среднестатистической инсталляции Linux практически невозможна.