The operations we use to deleted members in the memberof plugin are quite inefficient, but on top of that we were also "leaking" a lot of search results on the operations contexts, causing the runtime memory footprint to grow immensely (as in gigabytes for a singe ldb_modify).
It was technically not a leak beacuase eventually all memory would be reclaimed, but it was enough to make the OOM killer kill our processes.
After a deletion operation is finished, make sure to explicitly free all the search results we do not need anymore, so that the footprint remains low.
Simo.
On Wed, 13 Apr 2011 17:34:50 -0400 Simo Sorce ssorce@redhat.com wrote:
The operations we use to deleted members in the memberof plugin are quite inefficient, but on top of that we were also "leaking" a lot of search results on the operations contexts, causing the runtime memory footprint to grow immensely (as in gigabytes for a singe ldb_modify).
It was technically not a leak beacuase eventually all memory would be reclaimed, but it was enough to make the OOM killer kill our processes.
After a deletion operation is finished, make sure to explicitly free all the search results we do not need anymore, so that the footprint remains low.
Attached an improved version of the patch that also properly clears the structure so that in case of future modification of the module we do not incur in potentially trying to use dangling pointers.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/13/2011 05:40 PM, Simo Sorce wrote:
On Wed, 13 Apr 2011 17:34:50 -0400 Simo Sorce ssorce@redhat.com wrote:
The operations we use to deleted members in the memberof plugin are quite inefficient, but on top of that we were also "leaking" a lot of search results on the operations contexts, causing the runtime memory footprint to grow immensely (as in gigabytes for a singe ldb_modify).
It was technically not a leak beacuase eventually all memory would be reclaimed, but it was enough to make the OOM killer kill our processes.
After a deletion operation is finished, make sure to explicitly free all the search results we do not need anymore, so that the footprint remains low.
Attached an improved version of the patch that also properly clears the structure so that in case of future modification of the module we do not incur in potentially trying to use dangling pointers.
After fairly rigorous testing: Ack!
Great work on this one, Simo.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/14/2011 11:21 AM, Stephen Gallagher wrote:
On 04/13/2011 05:40 PM, Simo Sorce wrote:
On Wed, 13 Apr 2011 17:34:50 -0400 Simo Sorce ssorce@redhat.com wrote:
The operations we use to deleted members in the memberof plugin are quite inefficient, but on top of that we were also "leaking" a lot of search results on the operations contexts, causing the runtime memory footprint to grow immensely (as in gigabytes for a singe ldb_modify).
It was technically not a leak beacuase eventually all memory would be reclaimed, but it was enough to make the OOM killer kill our processes.
After a deletion operation is finished, make sure to explicitly free all the search results we do not need anymore, so that the footprint remains low.
Attached an improved version of the patch that also properly clears the structure so that in case of future modification of the module we do not incur in potentially trying to use dangling pointers.
After fairly rigorous testing: Ack!
Great work on this one, Simo.
Pushed to master and sssd-1-5.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
sssd-devel@lists.fedorahosted.org
-
Simo Sorce -
Stephen Gallagher