Gluster users - Nov 2016 - strange memory consumption with libgfapi

Hello,

I was experimenting with libgfapi a bit and found something which I 
cannot explain.

I wanted to simulate a behavior of long running system, so I created a 
simple program which reads a file from Gluster volume, saves it under a 
new name, deletes the original file and prints out the memory 
statistics. And again, reads the file saved in the last round, saves a 
new one, ? But it seems that such a program just consumes memory 
indefinitely.

The full source code of the program is attached, or available on 
http://pastebin.com/9emyDH5N. It is not a production ready code, just an 
experiment, but Gluster usage should be correct there.

My volume consists of 2 bricks, no replication, default options, Gluster 
server and client have both the same version 3.8.4-1.fc24. The file I am 
using for experiments is ~70 bytes. Program started on 70MB RSS and the 
last time I checked it was 250MB. Unfortunately it is not possible to 
use valgrind properly, because libgfapi seems to leak just by 
initializing and deinitializing (tested with different code).

Is there some call in the library to free the memory that I am not 
using? Some settings of the volume?

Thanks for your suggestions, kind regards,
Pavel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: glfs_new_files.cpp
Type: text/x-c++src
Size: 5152 bytes
Desc: not available
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20161025/79aa33c2/attachment.bin>

Hello.

25.10.2016 09:11, Pavel Cernohorsky wrote:
> Unfortunately it is not
> possible to use valgrind properly, because libgfapi seems to leak just
> by initializing and deinitializing (tested with different code).
Use Valgrind with Massif tool. That would definitely help.

For those who are interested, colleague of mine found out the problem is 
this line:

itable = inode_table_new (131072, new_subvol);

in glfs-master.c (graph_setup function). That hard-coded number is huge! 
And looking at the history of Gluster sources, it seems that this number 
used to be a number of bytes, but it became number of inodes, but 
someone forgot to change this hard-coded value!

Anybody from RedHat here interested in fixing it?

Kind regards,

Pavel


On 10/25/2016 09:28 AM, Oleksandr Natalenko wrote:
> Hello.
>
> 25.10.2016 09:11, Pavel Cernohorsky wrote:
>> Unfortunately it is not
>> possible to use valgrind properly, because libgfapi seems to leak just
>> by initializing and deinitializing (tested with different code).
>
> Use Valgrind with Massif tool. That would definitely help.