[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