[gpfsug-discuss] Memory accounting for processes writing to GPFS

[Tomer Perry]

It might be the case that AsynchronousFileChannel is actually doing mmap 
access to the files. Thus, the memory management will be completely 
different with GPFS in compare to local fs.

Regards,

Tomer Perry
Scalable I/O Development (Spectrum Scale)
email: tomp at il.ibm.com
1 Azrieli Center, Tel Aviv 67021, Israel
Global Tel:    +1 720 3422758
Israel Tel:      +972 3 9188625
Mobile:         +972 52 2554625




From:   Jim Doherty <jjdoherty at yahoo.com>
To:     gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date:   06/03/2019 06:59
Subject:        Re: [gpfsug-discuss] Memory accounting for processes 
writing to GPFS
Sent by:        gpfsug-discuss-bounces at spectrumscale.org



For any process with a large number of threads the VMM size has become an 
imaginary number ever since the glibc change to allocate a heap per 
thread. 
I look to /proc/$pid/status to find the memory used by a proc  RSS + Swap 
+ kernel page tables. 

Jim

On Wednesday, March 6, 2019, 4:25:48 AM EST, Dorigo Alvise (PSI) 
<alvise.dorigo at psi.ch> wrote: 


Hello to everyone,
Here a PSI we're observing something that in principle seems strange (at 
least to me).
We run a Java application writing into disk by mean of a standard 
AsynchronousFileChannel, whose I do not the details.
There are two instances of this application: one runs on a node writing on 
a local drive, the other one runs writing on a GPFS mounted filesystem 
(this node is part of the cluster, no remote-mounting).

What we do see is that in the former the application has a lower sum 
VIRT+RES memory and the OS shows a really big cache usage; in the latter, 
OS's cache is negligible while VIRT+RES is very (even too) high (with VIRT 
very high).

So I wonder what is the difference... Writing into a GPFS mounted 
filesystem, as far as I understand, implies "talking" to the local mmfsd 
daemon which fills up its own pagepool... and then the system will 
asynchronously handle these pages to be written on real pdisk. But why the 
Linux kernel accounts so much memory to the process itself ? And why this 
large amount of memory is much more VIRT than RES ?

thanks in advance,

   Alvise
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=mLPyKeOa1gNDrORvEXBgMw&m=cm3DTOcac__Y20DdtIZcwEXYG9GqlDxlHFTLeSAUOdE&s=hxak8mqRwAQuN7BaF-B9gvTQu1PGnCFF8am1GvMu3bI&e=





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20190306/708b2144/attachment.htm>