<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Apr 15, 2019 at 9:18 PM Jacek Tomaka <<a href="mailto:jacekt@dug.com">jacekt@dug.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"></div><div dir="ltr"><br></div><div>>signal_cache should have one entry for each process (or thread-group).</div><div><br></div><div>That is what i thought as well, looking at the kernel source, allocations from</div><div>signal_cache happen only during fork. <br></div><div><br></div></div></div></div></div></blockquote><div><br></div><div>I was recently chasing an issue with clients suffering from low memory and saw that "signal_cache" was a major player.  But the workload on those clients was not doing a lot of forking.  (and I don't *think* threading either)  Rather it was a LOT of metadata read operations.</div><div><br></div><div>You can see the symptoms by a simple "du" on a Lustre file system:</div><div><div><br></div><div># grep signal_cache /proc/slabinfo</div><div>signal_cache         967   1092   1152   28    8 : tunables    0    0    0 : slabdata     39     39      0</div></div><div><br></div><div># du -s /mnt/lfs1/projects/foo<br></div><div><div>339744908<span style="white-space:pre"> </span>/mnt/lfs1/projects/foo</div></div><div><br></div><div># grep signal_cache /proc/slabinfo<br></div><div><div>signal_cache      164724 164724   1152   28    8 : tunables    0    0    0 : slabdata   5883   5883      0</div><div><br></div><div># slabtop -s c -o | head -n 20</div><div> Active / Total Objects (% used)    : 3660791 / 3662863 (99.9%)</div><div> Active / Total Slabs (% used)      : 93019 / 93019 (100.0%)</div><div> Active / Total Caches (% used)     : 72 / 107 (67.3%)</div><div> Active / Total Size (% used)       : 836474.91K / 837502.16K (99.9%)</div><div> Minimum / Average / Maximum Object : 0.01K / 0.23K / 12.75K</div><div><br></div><div>  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   </div><div>164724 164724 100%    1.12K   5883       28    188256K signal_cache           </div><div>331712 331712 100%    0.50K  10366       32    165856K ldlm_locks             </div><div>656896 656896 100%    0.12K  20528       32     82112K kmalloc-128            </div><div>340200 339971  99%    0.19K   8100       42     64800K kmalloc-192            </div><div>162838 162838 100%    0.30K   6263       26     50104K osc_object_kmem        </div><div>744192 744192 100%    0.06K  11628       64     46512K kmalloc-64             </div><div>205128 205128 100%    0.19K   4884       42     39072K dentry                 </div><div>  4268   4256  99%    8.00K   1067        4     34144K kmalloc-8192           </div><div>162978 162978 100%    0.17K   3543       46     28344K vvp_object_kmem        </div><div>162792 162792 100%    0.16K   6783       24     27132K kvm_mmu_page_header    </div><div>162825 162825 100%    0.16K   6513       25     26052K sigqueue               </div><div> 16368  16368 100%    1.02K    528       31     16896K nfs_inode_cache        </div><div> 20385  20385 100%    0.58K    755       27     12080K inode_cache            </div></div><div><br></div><div>Repeat that for more (and bigger) directories and slab cache added up to more than half the memory on this 24GB node.</div><div><br></div><div>This is with CentOS-7.6 and lustre-2.10.5_ddn6.</div><div><br></div><div>I worked around the problem by tackling the "ldlm_locks" memory usage with:</div><div># lctl set_param ldlm.namespaces.lfs*.lru_max_age=10000<br></div><div><br></div><div>...but I did not find a way to reduce the "signal_cache".</div><div><br></div><div>Regards,</div><div>Nathan</div><div><br></div></div></div></div></div></div></div></div></div>