FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 05-23-2012, 07:19 PM
Russell Beall
 
Default 389 vs Sun DS ldapmodify performance

On May 23, 2012, at 9:36 AM, Rich Megginson wrote:But based on what you say later in the post, it's not unbounded, it's just not bounded by what you set as the cache size?

Yes. *I guess unbounded was the wrong word now that the ratio of the boundary seems to be shown. *The boundary of the memory growth seems to be (6 * cachememsize).
It doesn't grow unless it gets hit with ldapmodify operations. *It seems to correctly use the cachememsize and the dbcachesize when reading in all entries and doesn't grow if just hit with ldapsearch.


Yes, please.

Ok.
Russ.


Thanks,Russ.
==============================
Russell Beall
Programmer Analyst IVEnterprise Identity ManagementUniversity*of*Southern Californiabeall@usc.edu=========================== ===

On Apr 24, 2012, at 6:53 AM, Rich Megginson wrote:The thing in common is this - when the cache usage hits the cache max size, you see unbounded memory growth.


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-23-2012, 07:34 PM
Rich Megginson
 
Default 389 vs Sun DS ldapmodify performance

On 05/23/2012 01:19 PM, Russell Beall wrote:



On May 23, 2012, at 9:36 AM, Rich Megginson wrote:

But based on what you say later in
the post, it's not unbounded, it's just not bounded by what
you set as the cache size?





Yes. *I guess unbounded was the wrong word now that the ratio of
the boundary seems to be shown. *The boundary of the memory
growth seems to be (6 * cachememsize).



It doesn't grow unless it gets hit with ldapmodify
operations.



Have you tried modrdn?* delete?* I was just wondering if the problem
is specific to ldapmodify.




It seems to correctly use the cachememsize and the
dbcachesize when reading in all entries and doesn't grow if just
hit with ldapsearch.





Ok, good to know.










Yes, please.





Ok.



Russ.








Thanks,
Russ.






==============================

Russell Beall

Programmer Analyst IV
Enterprise
Identity Management
University*of*Southern
California
beall@usc.edu



==============================











On Apr 24, 2012, at 6:53 AM, Rich Megginson
wrote:

The thing in common is this - when the cache
usage hits the cache max size, you see unbounded
memory growth.









--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users










--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-23-2012, 08:11 PM
Russell Beall
 
Default 389 vs Sun DS ldapmodify performance

I have not tried modrdn.
Very early in my testing I thought I was seeing unbounded growth by performing endless deletes (and re-adds). *That, I found out through your much-appreciated responses to this list, was causing an explosion in tombstone entries and thus the server was exploding in actual data requirements.
We don't actually place much importance on that use case because we hardly ever delete an entry, so the housekeeping process for tombstones is more than ample for that cleanup.
The ldapmodify use case is critical to us however, because we perform large quantities of ldapmodify operations every day.
This memory growth situation I have described here applies specifically and only to endless ldapmodify operations.
Regards,Russ.
On May 23, 2012, at 12:34 PM, Rich Megginson wrote:Have you tried modrdn?* delete?* I was just wondering if the problem is specific to ldapmodify.

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-23-2012, 08:32 PM
Rich Megginson
 
Default 389 vs Sun DS ldapmodify performance

On 05/23/2012 02:11 PM, Russell Beall wrote:
I have not tried modrdn.



Very early in my testing I thought I was seeing unbounded
growth by performing endless deletes (and re-adds). *That, I
found out through your much-appreciated responses to this list,
was causing an explosion in tombstone entries and thus the
server was exploding in actual data requirements.



We don't actually place much importance on that use case
because we hardly ever delete an entry, so the housekeeping
process for tombstones is more than ample for that cleanup.



The ldapmodify use case is critical to us however, because we
perform large quantities of ldapmodify operations every day.



This memory growth situation I have described here applies
specifically and only to endless ldapmodify operations.



ok - please file a ticket at* https://fedorahosted.org/389







Regards,
Russ.



On May 23, 2012, at 12:34 PM, Rich Megginson wrote:

Have you tried modrdn?* delete?*
I was just wondering if the problem is specific to
ldapmodify.











--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 03:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org