Выполняя тестирование производительности на AD-LDS (Server 2008 R2 64 бит), мы создали миллион пользователей в одной OU. Мы тоже создал единый объект группы и сделал миллион пользователей членами этой группы.
Когда мы пытаемся составить список миллионов пользователей, время ожидания ADSIEdit истекает с сообщением об ошибке, в котором говорится, что он не может отобразить такое количество пользователей. Хорошо.
Но если мы откроем свойства для группы, ADSIEdit зависнет, съедая всю доступную память и процессор. мусор (около 60 миллионов страниц с ошибками менее чем за час).
AD-LDS (запущенный на другом компьютере) едва достигает отметки 1% ЦП, обслуживая другие запросы ldap, как будто ничего не было.
Мы можем выделить больше памяти для решения проблемы, но однажды придется управлять большим количеством пользователей, и мы вернемся к исходной точке.
Есть ли способ установить ограничение в ADSIEdit, чтобы он не зависал при извлечении очень большого многозначного объекта?
Есть ли способ установить ограничение в ADSIEdit, чтобы он не зависал при извлечении очень большого многозначного объекта?
Не то, чтобы я в курсе. LDAP прекрасно подходит для предоставления небольшого набора значений для многозначного атрибута, но, насколько мне известно, ADSIEDIT не использует этого преимущества. Для управления такими объектами лучше подойдет другой инструмент.
Для структуры каталогов, такой как вы описываете, управление вещами с помощью сценариев, вероятно, лучший способ, чем доверять инструментам графического интерфейса. Инструменты командной строки, поставляемые с RSAT, очень хорошо справляются с манипуляциями с объектами даже с очень большими объектами.