Bug 420104

Summary: plasmashell allocates excessive memory on system with 128gb RAM
Product: [Plasma] plasmashell Reporter: Steve Phelps <phelps.sg>
Component: generalAssignee: David Edmundson <kde>
Status: CLOSED NOT A BUG    
Severity: normal CC: plasma-bugs
Priority: NOR    
Version: 5.17.0   
Target Milestone: 1.0   
Platform: Kubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Steve Phelps 2020-04-15 08:25:11 UTC 
SUMMARY

The plasmashell process allocates between 10g and 12g of memory when there is a large amount of RAM available.


STEPS TO REPRODUCE
1. Ensure machine has 128gb RAM
2. Install KUbuntu 19.10
3. Start plasma session
4. Start top, and sort on %MEM
5. Go into system settings (this is one of the triggers for the large memory allocation)
6. Check plasmashell VIRT - will be at least 10g

OBSERVED RESULT

plasmashell should not hog this amount of memory, even when there is lots of memory available.

EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Kubuntu 19.10, 
(available in About System)
KDE Plasma Version: plasma 5.18.1 via backports or earlier stock plasma
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 David Edmundson 2020-04-15 08:50:56 UTC 
>6. Check plasmashell VIRT - will be at least 10g

VIRT is effectively meaningless. It is not using your RAM.

Is RES high?
Comment 2 Steve Phelps 2020-04-15 08:58:44 UTC 
RES is not high but VIRT is not meaningless.  If total VIRT exceeds total RAM then the system will start to use swap.  I have other processes requiring large amounts of memory on this machine, and plasmashell is competing for memory.
Comment 3 David Edmundson 2020-04-15 09:03:33 UTC 
>If total VIRT exceeds total RAM then the system will start to use swap.  

That's not true. 

MMapped files (which are a lot) appear in VIRT but won't be swapped out. Also a large proportion is the LMDB space which allocates a huge amount but will never write to it. It's never "used" so won't be swapped out.
Comment 4 Steve Phelps 2020-04-15 09:05:57 UTC 
ah ok- thanks for the explanation.