[lustre-discuss] Lustre client memory and MemoryAvailable
Jacek Tomaka
jacekt at dug.com
Sun Apr 14 00:27:18 PDT 2019
Hello,
TL;DR;
Is there a way to figure out how much memory Lustre will make available
under memory pressure?
Details:
We are running lustre client on a machine with 128GB of memory (Centos 7)
Intel Phi KNL machines and at certain situations we see that there can be
~10GB+ of memory allocated on the kernel side i.e. :
vvp_object_kmem 3535336 3536986 176 46 2 : tunables 0 0
0 : slabdata 76891 76891 0
ll_thread_kmem 33511 33511 344 47 4 : tunables 0 0 0
: slabdata 713 713 0
lov_session_kmem 34760 34760 592 55 8 : tunables 0 0 0
: slabdata 632 632 0
osc_extent_kmem 3549831 3551232 168 48 2 : tunables 0 0
0 : slabdata 73984 73984 0
osc_thread_kmem 14012 14116 2832 11 8 : tunables 0 0 0
: slabdata 1286 1286 0
osc_object_kmem 3546640 3548350 304 53 4 : tunables 0 0
0 : slabdata 66950 66950 0
signal_cache 3702537 3707144 1152 28 8 : tunables 0 0
0 : slabdata 132398 132398 0
/proc/meminfo:
MemAvailable: 114196044 kB
Slab: 11641808 kB
SReclaimable: 1410732 kB
SUnreclaim: 10231076 kB
After executing
echo 1 >/proc/sys/vm/drop_caches
the slabinfo values don't change but when i actually generate memory
pressure by:
java -Xmx117G -Xms117G -XX:+AlwaysPreTouch -version
lots of memory gets freed:
vvp_object_kmem 127650 127880 176 46 2 : tunables 0 0 0
: slabdata 2780 2780 0
ll_thread_kmem 33558 33558 344 47 4 : tunables 0 0 0
: slabdata 714 714 0
lov_session_kmem 34815 34815 592 55 8 : tunables 0 0 0
: slabdata 633 633 0
osc_extent_kmem 128640 128880 168 48 2 : tunables 0 0 0
: slabdata 2685 2685 0
osc_thread_kmem 14038 14116 2832 11 8 : tunables 0 0 0
: slabdata 1286 1286 0
osc_object_kmem 82998 83263 304 53 4 : tunables 0 0 0
: slabdata 1571 1571 0
signal_cache 38734 44268 1152 28 8 : tunables 0 0 0
: slabdata 1581 1581 0
/proc/meminfo:
MemAvailable: 123146076 kB
Slab: 1959160 kB
SReclaimable: 334276 kB
SUnreclaim: 1624884 kB
The similar effect to generating memory pressure we see when executing:
echo 3 >/proc/sys/vm/drop_caches
But this can take very long time (10 minutes).
So essentially on a machine using Lustre client, MemAvailable is no longer
a good predictor of the amount of memory that can be allocated.
Is there a way to query Lustre and compensate for lustre cache memory that
will be made available on memory pressure?
Regards.
--
*Jacek Tomaka*
Geophysical Software Developer
*DownUnder GeoSolutions*
76 Kings Park Road
West Perth 6005 WA, Australia
*tel *+61 8 9287 4143 <+61%208%209287%204143>
jacekt at dug.com
*www.dug.com <http://www.dug.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20190414/9c489d2e/attachment.html>
More information about the lustre-discuss
mailing list