core : free up mem_acct.rec in xlator_destroy
Problem: We've observed that glusterd was OOM killed after some minutes when volume set command was run in a loop. Analysis: Initially the suspection was in glusterd code, but a deep dive into the codebase revealed that while validating all the options as part of graph reconfiguration at the time of freeing up the xlator object its one of the member mem_acct is left over which causes memory leak. Solution: Free up xlator's mem_acct.rec in xlator_destroy () Change-Id: Ie9e7267e1ac4ab7b8af6e4d7c6660dfe99b4d641 BUG: 1201203 Signed-off-by: Atin Mukherjee <amukherj@redhat.com> Reviewed-on: http://review.gluster.org/9862 Reviewed-by: Niels de Vos <ndevos@redhat.com> Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com> Reviewed-by: Raghavendra Bhat <raghavendra@redhat.com> Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com>
This commit is contained in:
parent
d2629aef83
commit
4481b03ae2
@ -556,6 +556,25 @@ xlator_list_destroy (xlator_list_t *list)
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int
|
||||
xlator_memrec_free (xlator_t *xl)
|
||||
{
|
||||
uint32_t i = 0;
|
||||
|
||||
if (!xl)
|
||||
return 0;
|
||||
|
||||
if (xl->mem_acct.rec) {
|
||||
for (i = 0; i < xl->mem_acct.num_types; i++) {
|
||||
LOCK_DESTROY (&(xl->mem_acct.rec[i].lock));
|
||||
}
|
||||
FREE (xl->mem_acct.rec);
|
||||
xl->mem_acct.rec = NULL;
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int
|
||||
xlator_members_free (xlator_t *xl)
|
||||
{
|
||||
@ -912,6 +931,7 @@ xlator_destroy (xlator_t *xl)
|
||||
return 0;
|
||||
|
||||
xlator_members_free (xl);
|
||||
xlator_memrec_free (xl);
|
||||
GF_FREE (xl);
|
||||
|
||||
return 0;
|
||||
|
Loading…
x
Reference in New Issue
Block a user