On 02/14/2014 02:52 PM, Michael Gettes wrote:
i guess i wasn’t clear in my question - i am not seeing a problem
with paged results.
Sorry - I meant - are you seeing a problem currently with uid=*
searches, without paged results? If you are seeing high memory usage -
does the memory usage go down when the search is complete? Is this
memory that is not in a db or entry cache?
and i think you answered my question. with paged results one should
be able to perform a query with large result sets and not have large memory concerns,
I am not sure. That is, paged results doesn't necessarily help with the
this would be the answer i am looking for.
On Feb 14, 2014, at 4:13 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
> On 02/14/2014 02:04 PM, Michael Gettes wrote:
>> I did some searching to try and answer the following question and the answer is
not apparent to me.
>> I have a directory with hundreds of thousands of entries. I have an app which,
due to its behavior, needs to
>> be able to search for very large sets of users but I don’t want it to be able to
get ALL users and therefore exhaust
>> all memory on the ldap server.
>> If the app performs a search on uid=* and the it’s a paged search, does this have
a positive impact on how
>> memory is used to handle the results so it doesn’t exhaust all memory?
>> I’m trying to keep the scenario simple so I hope you appreciate the question I am
> The primary reason for using paged results on the server side is to allow you to
perform searches which otherwise would have hit the lookthrough limit, and caused high CPU
spikes. It should also reduce memory usage, although I'm not sure why it should
exhaust memory in the first place. Are you seeing the directory server run out of memory
with these types of searches?
>> 389 users mailing list
> 389 users mailing list
389 users mailing list