well, i guess this was not a simple a question as i thought. i need to do some testing.
On Feb 14, 2014, at 4:55 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
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
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, right?
I am not sure. That is, paged results doesn't necessarily help with the memory
> 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 getting at.
>> 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
389 users mailing list