Optimize ram usage

General system Newbie
1

i try to lower the system’s overall ram usage after boot, without sacrificing essential (to me) features like update notifications, for instance.

now, whenever an update is avaiable, discover (kde) seems to let you know via its icon in the taskbar (never used discover before).

does there exist a low footprint alternative, which will still inform you once after booting into the os, but which will not permanently run as a background task?

is it safe to remove discover, when i still have eos-udate-notifier installed, or are they bound together?

what is your approach and do you have other ram tweak tips for eos?

2

to optimize ram usage is always to know what you do…

in KDE you have to check if baloo is running in behind you can switch that off and any other indexers…

you can check autostart also if there some update icon of discover is enforce to autostart, you can disable that also… but eos-update-notifier is a low ram print so thats not the problem.

2 Likes
3

hi ringo,

yes, the usual stuff is already disabled (like baloo, animations, some extra services). there is no special use case, i just want keep a low-ram-footprint in general.

systemctl list-unit-files --type=service | grep enabled:

Summary

autovt@.service enabled
avahi-daemon.service enabled
dbus-org.freedesktop.Avahi.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
dbus-org.freedesktop.timesync1.service enabled
display-manager.service enabled
getty@.service enabled
lm_sensors.service enabled
NetworkManager-dispatcher.service enabled
NetworkManager.service enabled
sddm.service enabled
stubby.service enabled
systemd-fsck-root.service enabled-runtime
systemd-networkd-wait-online.service enabled
systemd-remount-fs.service enabled-runtime
systemd-timesyncd.service enabled
tlp-sleep.service enabled
tlp.service enabled
ufw.service enabled
upower.service enabled

btw, any more services to safely disable?

conky + plank is in autostart, and ram usage on a freshly booted system is about 620mb, which is not so bad. my “identical” manjaro install took about 540mb, so perhaps there is still some free space for ideas :wink:

4

They are not bound together in any way.

Depends on what services you have running :wink:
Candidates (if you have them) for removal or disabling are e.g.

  • kalu (uninstall if you have it)
  • pamac-tray update notifier (disable)
  • wallpaper-once (typically used only once initially, can be disabled)

but these may not save much memory.
You can use programs top, htop, glances and others for finding memory usage of programs.

Typically web browsers consume lots of memory.

1 Like
5

i removed discover from the system, thanks. so eos-update-notifier is still supposed to inform on updates nevertheless, right? that is basically what i am looking for, i guess.

i noticed that (sometimes) there is a packagekitd process with about 55mb running in the background, which i don’t seem to remember (from manjaro)?

6

Yes.

7

not so much related to ram, but i just did a systemd-analyze to see if i could get rid this problem.

systemd-analyze:

Summary

Startup finished in 2.183s (firmware) + 2.615s (loader) + 4.363s (kernel) + 8.657s (userspace) = 17.820s
graphical.target reached after 8.443s in userspace

systemd-analyze blame:

Summary

systemd-analyze blame
7.521s systemd-networkd-wait-online.service
1.860s systemd-random-seed.service
1.442s upower.service
1.060s systemd-logind.service
713ms dev-sda3.device
594ms udisks2.service
422ms systemd-timesyncd.service
320ms systemd-udevd.service
318ms systemd-networkd.service
318ms systemd-journald.service
211ms tlp.service
197ms polkit.service
192ms ldconfig.service
189ms boot-efi.mount
159ms ufw.service
120ms systemd-udev-trigger.service
95ms avahi-daemon.service
94ms user@1000.service
70ms NetworkManager.service
63ms lm_sensors.service
48ms systemd-fsck@dev-disk-by\xxx…service
45ms systemd-tmpfiles-clean.service
42ms systemd-fsck@dev-disk-by\xxx…service
37ms dev-disk-by\xxx…swap
34ms systemd-fsck@dev-disk-by\xxx…service
29ms systemd-modules-load.service
27ms home.mount
25ms systemd-journal-flush.service

any chance to optimize (or even disable) the first entry for an improved bootup?

8

Could you paste the entire systemd-analyze && systemd-analyze blame ?

9

sure, i’ve edited my previous post.

10

I don’t see any other service that can be disabled or masked … as some of those that remain, then come the problems (and I’ve already been through …)

Anyway, if you want to compare, I’ll leave you mine:

systemd-analyze && systemd-analyze blame
Startup finished in 4.838s (kernel) + 3.383s (userspace) = 8.222s 
graphical.target reached after 2.758s in userspace
1.522s systemd-random-seed.service                                                              
 967ms systemd-logind.service                                                                   
 776ms dev-sdb3.device                                                                          
 624ms tlp.service                                                                              
 518ms udisks2.service                                                                          
 440ms rtkit-daemon.service                                                                     
 346ms upower.service                                                                           
 336ms systemd-udevd.service                                                                    
 260ms ldconfig.service                                                                         
 214ms systemd-timesyncd.service                                                                
 187ms systemd-journald.service                                                                 
 170ms boot-efi.mount                                                                           
 161ms boot-esp.mount                                                                           
 153ms NetworkManager.service                                                                   
 151ms systemd-journal-flush.service                                                            
 128ms avahi-daemon.service                                                                     
 127ms systemd-fsck@dev-disk-by\x2duuid-e26173fa\x2d58ef\x2d4a6e\x2d8df6\x2d239506f516a8.service
 121ms polkit.service                                                                           
 111ms ufw.service                                                                              
 108ms systemd-fsck@dev-disk-by\x2duuid-8B2F\x2d14FD.service                                    
  94ms systemd-journal-catalog-update.service                                                   
  93ms systemd-fsck@dev-disk-by\x2duuid-8B5A\x2dC06B.service                                    
  59ms user@1000.service                                                                        
  58ms systemd-modules-load.service                                                             
  50ms systemd-rfkill.service                                                                   
  48ms systemd-tmpfiles-setup.service                                                           
  41ms systemd-udev-trigger.service                                                             
  28ms systemd-tmpfiles-setup-dev.service                                                       
  26ms systemd-sysusers.service                                                                 
  23ms wpa_supplicant.service                                                                   
  13ms dev-hugepages.mount                                                                      
  13ms systemd-sysctl.service                                                                   
  12ms dev-mqueue.mount                                                                         
  12ms systemd-update-utmp.service                                                              
  11ms sys-kernel-debug.mount                                                                   
  11ms kmod-static-nodes.service                                                                
   8ms home.mount                                                                               
   5ms systemd-remount-fs.service                                                               
   5ms systemd-update-done.service                                                              
   4ms user-runtime-dir@1000.service                                                            
   3ms systemd-user-sessions.service                                                            
   2ms sys-kernel-config.mount                                                                  
   1ms sys-fs-fuse-connections.mount                                                            
   1ms tmp.mount
1 Like
11

Are you using a traditional HDD instead of SSD? That might explain the results.

12

that is strange, the service in question:

7.521s systemd-networkd-wait-online.service

is not even part of your output?

7.5 sec is not really dramatic on my side, but i would not feel sorry for cutting it down :slight_smile:

i also updated my enabled unit files

no, it is a ssd.

13

Yeah, I missed it:

systemctl disable systemd-networkd-wait-online.service
14

ok, bootime back to standard values, thanks!

15

what for is RAM ? it is there to use it as a fast loadspace for tasks.
…but this thread is more about boottime…

2 Likes
16

indeed that was slighty offtopic (just as i stated), although many enabled services are also affecting ram usage in the end, so it is circular flow if you like.

now, to a certain degree that is of course true. on the other hand, there is heavyweight browsers making real use of avaiable ram, where doing something else besides browsing slowly turns into an adventure…

personally i very much favour a system with a modest exposure of ram (despite its hardware-specs) and try to stay with tools that keep up to this philosophy as well. to be wasteful with resources in general is something i try to avoid.

17

Because of this we do only enable minimal needed services, but to have a complete system some are needed

18

true and i am thankful for that approach, i hope you did not misinterpret it?

this is about optimizing what is already in good state, nothing spectacular :slight_smile:

deceiding which service is crucial can get difficult at times. thanks to the people here around, i could optimize it quite a bit on my machine.

any further tips that fit in are very welcome.