LINUX.ORG.RU
решено ФорумAdmin

Тормозит winbind


0

2

Доброго времени суток. Помогите разобраться с проблемой. Есть RHEL 6.0, Squid 3.1.20+AD, winbind из пакета samba3.6.8. Около 1500 пользователей. Последнее время пошли жалобы, что инет стал медленным. Смотрю squidclient mgr:ntlmauthenticator: Почти все ntlmauthenticator (их 700) заняты, avg service time достигает 8000msec, winbindd_cache.tdb достигает ~50-60Mb. Делаю service winbind restart, попускает. Количество ntlmauthenticator уменьшается до десятков, avg service time в районе нуля, winbindd_cache.tdb уменьшается до нескольких килобайт. Через время все повторяется и начинаются тормоза. Пробовал ставить winbind offline logon в true, результат такой же.

      
        display charset = utf8
        unix charset = utf8
        dos charset = cp866
        workgroup = USB
        realm = USB.ROOT.LC
        server string = Corporate Proxy Server
        security = ADS
        obey pam restrictions = yes
        password server = 192.168.8.171
        passdb backend = tdbsam
        log level = 0
        syslog = 0
        log file = /var/log/samba/samba.log
        winbind max clients = 2000
        paranoid server security = No
        load printers = No

        local master = no
        os level = 0
        domain master = no
        preferred master = no
        domain logons = no
        idmap config * : range = 10000-20000
        idmap config * : backend = tdb
        winbind enum users = Yes
        winbind enum groups = Yes
        winbind use default domain = Yes
        winbind refresh tickets = Yes
        winbind separator = +
       winbind offline logon = false
        winbind cache time = 600
        case sensitive = No


Около 1500 пользователей
все ntlmauthenticator (их 700) заняты

Неудивительно. 1 пользователь может занять 10-20 аутентификаторов запросом, например, карт yandex.

Попробуйте для начала увеличить количество ntlmauthenticator раза в 3 и сообщите результат.

zgen ★★★★★
()
Ответ на: комментарий от zgen

Я хоть и написал, что

Почти все ntlmauthenticator (их 700) заняты

но записи в cache.log о нехватке оных нет. Увеличивал до 1500. Результат: как только занимается процентов 50 и больше ntlmauthenticator`ов начинаются тормоза.

dixit
() автор топика
Ответ на: комментарий от dixit

Результат: как только занимается процентов 50 и больше ntlmauthenticator`ов начинаются тормоза.

Значит кеширование не работает и все затыкается в производительность AD контроллера, который выдает ответ.

Я не спец в samba+AD, но

Во-первых - все-таки включите
winbind offline logon = false в true

Во-вторых - копайте в подобную сторону
http://forum.ubuntu.ru/index.php?topic=163264.0

Учитывая

winbind refresh tickets = Yes, а значит, как минимум

«Winbind should refresh Kerberos Tickets retrieved using the pam_winbind module»
стоит очень серьезно отнестись к совету, данному в ссылке на счет конфигурации pam_winbind

zgen ★★★★★
()
Ответ на: комментарий от zgen

Позвольте порассуждать... Сразу признаюсь, что в сторону pam_winbind сильно не копал. Хочу понять вот что. Есть еще один резервный проксик, настроенный на тот же контроллер домена. Работает человек 30 - проблем нет. Значит, можно откинуть версию, что

все затыкается в производительность AD контроллера

Далее на этом резервном проксике делал следующее.

cache_peer 192.168.4.128 parent 8080 0 no-query no-digest login=login:pass 
Т.е. указал ему парентом промышленный проксик. Резервный проксик аутентифицирует юзеров все на том же контроллере, но паренту ж передает связку логин:пароль, который уже сам аутентифицирует этого юзера. Результат - все работает быстро.

Не правильно мыслю? Хотелось бы порассуждать на эту тему.

dixit
() автор топика
Ответ на: комментарий от dixit

Работает человек 30 - проблем нет

Одновременно (!) с

Около 1500 пользователей.

OK, если так, то

Значит, можно откинуть версию

все затыкается в производительность AD контроллера

Резервный проксик аутентифицирует юзеров все на том же контроллере,
но паренту ж передает связку логин:пароль, который уже сам аутентифицирует этого юзера.

Не силен в связках сквидов - Т.е. аутентификация для пользователя происходит дважды, сначала на резервном, потом на основном? Точно ли все работает именно так? (т.е. в дополнение к 1500 пользователям, которые не могут аутентифицироваться приходит с резервного прокси еще 30, которые могут?)

Не правильно мыслю? Хотелось бы порассуждать на эту тему.

Производительность основного прокси сервера проседает? LA какой? Что с диском/памятью/cpu?

zgen ★★★★★
()
Ответ на: комментарий от zgen
top - 11:41:56 up 13:15,  3 users,  load average: 0.13, 0.12, 0.09
Tasks: 1779 total,   2 running, 1777 sleeping,   0 stopped,   0 zombie
Cpu(s):  6.7%us,  5.6%sy,  0.0%ni, 84.5%id,  0.2%wa,  0.3%hi,  2.7%si,  0.0%st
Mem:   8062044k total,  7739520k used,   322524k free,   912852k buffers
Swap:  1691640k total,        0k used,  1691640k free,  3534944k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2082 squid     20   0  976m 907m 3832 R 67.0 11.5 115:50.64 squid
 2121 root      20   0  202m  29m  21m S 31.7  0.4  14:38.92 winbindd
 2123 root      20   0  197m  21m  20m S  9.2  0.3   5:56.00 winbindd

Не силен в связках сквидов - Т.е. аутентификация для пользователя происходит дважды, сначала на резервном, потом на основном? Точно ли все работает именно так? (т.е. в дополнение к 1500 пользователям, которые не могут аутентифицироваться приходит с резервного прокси еще 30, которые могут?)

Попробую объяснить. Есть основной проксик,который обслуживает 1500 клиентов. Есть резервный проксик. Для эксперемента я настроил резервный проксик, что бы все запросы от юзеров отправлялись к братскому кешу, т.е. к основному проксику. Получается юзер открывает страничку через резервный проксик, тот перенаправляет запрос на основной проксик, который уже лезет в Инет.

Каждый из проксиков за аутентификацией отправляет юзеров на один и тот же контроллер домена, т.е. аутентифицируют юзеров, которые открывают страницы в браузере, каждый сам за себя.

А вот резервный проксик передает основному логин-пароль, который указан для соединения с кешем основного проксика:

cache_peer 192.168.4.128 parent 8080 0 no-query no-digest login=login:pass

И именно этот логин-пароль основной проксик аутентифицирует на контроллере домена. Т.о. получается что для основного проксика резервный выступает как обычный юзер который открывает странички в браузере через основной проксик. Но для обычного юзера с основного проксика есть тормоза, ввиде задержек аутентификации, а у резервного такого нет.

P.S. Все это взято не с потолка-делал отслеживание через tcpdump.

dixit
() автор топика
Ответ на: комментарий от dixit

Вот за день такая статистика:

NTLM Authenticator Statistics:
program: /usr/bin/ntlm_auth
number active: 1500 of 1500 (0 shutting down)
requests sent: 8610407
replies received: 8610407
dixit
() автор топика
23 июля 2013 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.