Oleksandr Natalenko
2016-Feb-11 08:12 UTC
[Gluster-users] [Gluster-devel] GlusterFS v3.7.8 client leaks summary — part II
And here goes "rsync" test results (v3.7.8 + two patches by Soumya). 2 volumes involved: source and target. === Common indicators == slabtop before drop_caches: [1] slabtop after drop_caches: [2] === Source volume (less interesting part) == RAM usage before drop_caches: [3] statedump before drop_caches: [4] RAM usage after drop_caches: [5] statedump after drop_caches: [6] === Target volume (most interesting part) == RAM usage before drop_caches: [7] statedump before drop_caches: [8] RAM usage after drop_caches: [9] statedump after drop_caches: [10] Valgrind output: [11] === Conclusion == Again, see no obvious leaks. [1] https://gist.github.com/e72fd30a4198dd630299 [2] https://gist.github.com/78ef9eae3dc16fd79c1b [3] https://gist.github.com/4ed75e8d6cb40a1369d8 [4] https://gist.github.com/20a75d32db76795b90d4 [5] https://gist.github.com/0772959834610dfdaf2d [6] https://gist.github.com/a71684bd3745c77c41eb [7] https://gist.github.com/2c9be083cfe3bffe6cec [8] https://gist.github.com/0102a16c94d3d8eb82e3 [9] https://gist.github.com/23f057dc8e4b2902bba1 [10] https://gist.github.com/385bbb95ca910ec9766f [11] https://gist.github.com/685c4d3e13d31f597722 10.02.2016 15:37, Oleksandr Natalenko ???????:> Hi, folks. > > Here go new test results regarding client memory leak. > > I use v3.7.8 with the following patches: > > ==> Soumya Koduri (2): > inode: Retire the inodes from the lru list in inode_table_destroy > gfapi: Use inode_forget in case of handle objects > ==> > Those are the only 2 not merged yet. > > So far, I've performed only "find" test, and here are the results: > > RAM usage before drop_caches: [1] > statedump before drop_caches: [2] > slabtop before drop_caches: [3] > RAM usage after drop_caches: [4] > statedump after drop_caches: [5] > slabtop after drop_caches: [6] > Valgrind output: [7] > > No leaks either via statedump or via valgrind. However, statedump > stats still suffer from integer overflow. > > Next steps I'm going to take: > > 1) "rsync" test; > 2) API test. > > [1] https://gist.github.com/88d2fa95c28baeb2543f > [2] https://gist.github.com/4f3e93ff2db6e3cf4081 > [3] https://gist.github.com/62791a2c4258041ba821 > [4] https://gist.github.com/1d3ce95a493d054bbac2 > [5] https://gist.github.com/fa855a2752d3691365a7 > [6] https://gist.github.com/84e9e27d2a2e5ff5dc33 > [7] https://gist.github.com/f35bd32a5159d3571d3a > _______________________________________________ > Gluster-devel mailing list > Gluster-devel at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel
Oleksandr Natalenko
2016-Feb-11 15:03 UTC
[Gluster-users] [Gluster-devel] GlusterFS v3.7.8 client leaks summary — part II
And "API" test. I used custom API app [1] and did brief file manipulations through it (create/remove/stat). Then I performed drop_caches, finished API [2] and got the following Valgrind log [3]. I believe there are still some leaks occurring in glfs_lresolve() call chain. Soumya? [1] https://github.com/pfactum/xglfs [2] https://github.com/pfactum/xglfs/blob/master/xglfs_destroy.c#L30 [3] https://gist.github.com/aec72b6164a695cf2d44 11.02.2016 10:12, Oleksandr Natalenko ???????:> And here goes "rsync" test results (v3.7.8 + two patches by Soumya). > > 2 volumes involved: source and target. > > === Common indicators ==> > slabtop before drop_caches: [1] > slabtop after drop_caches: [2] > > === Source volume (less interesting part) ==> > RAM usage before drop_caches: [3] > statedump before drop_caches: [4] > RAM usage after drop_caches: [5] > statedump after drop_caches: [6] > > === Target volume (most interesting part) ==> > RAM usage before drop_caches: [7] > statedump before drop_caches: [8] > RAM usage after drop_caches: [9] > statedump after drop_caches: [10] > Valgrind output: [11] > > === Conclusion ==> > Again, see no obvious leaks. > > [1] https://gist.github.com/e72fd30a4198dd630299 > [2] https://gist.github.com/78ef9eae3dc16fd79c1b > [3] https://gist.github.com/4ed75e8d6cb40a1369d8 > [4] https://gist.github.com/20a75d32db76795b90d4 > [5] https://gist.github.com/0772959834610dfdaf2d > [6] https://gist.github.com/a71684bd3745c77c41eb > [7] https://gist.github.com/2c9be083cfe3bffe6cec > [8] https://gist.github.com/0102a16c94d3d8eb82e3 > [9] https://gist.github.com/23f057dc8e4b2902bba1 > [10] https://gist.github.com/385bbb95ca910ec9766f > [11] https://gist.github.com/685c4d3e13d31f597722 > > 10.02.2016 15:37, Oleksandr Natalenko ???????: >> Hi, folks. >> >> Here go new test results regarding client memory leak. >> >> I use v3.7.8 with the following patches: >> >> ==>> Soumya Koduri (2): >> inode: Retire the inodes from the lru list in >> inode_table_destroy >> gfapi: Use inode_forget in case of handle objects >> ==>> >> Those are the only 2 not merged yet. >> >> So far, I've performed only "find" test, and here are the results: >> >> RAM usage before drop_caches: [1] >> statedump before drop_caches: [2] >> slabtop before drop_caches: [3] >> RAM usage after drop_caches: [4] >> statedump after drop_caches: [5] >> slabtop after drop_caches: [6] >> Valgrind output: [7] >> >> No leaks either via statedump or via valgrind. However, statedump >> stats still suffer from integer overflow. >> >> Next steps I'm going to take: >> >> 1) "rsync" test; >> 2) API test. >> >> [1] https://gist.github.com/88d2fa95c28baeb2543f >> [2] https://gist.github.com/4f3e93ff2db6e3cf4081 >> [3] https://gist.github.com/62791a2c4258041ba821 >> [4] https://gist.github.com/1d3ce95a493d054bbac2 >> [5] https://gist.github.com/fa855a2752d3691365a7 >> [6] https://gist.github.com/84e9e27d2a2e5ff5dc33 >> [7] https://gist.github.com/f35bd32a5159d3571d3a >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel at gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users