LawsHosting
Verified User
Is it normal for it to use gigs of RAM? Hovers around 5Gig.
(I've compared MySQL, as it's the most used)
(I've compared MySQL, as it's the most used)
Directadmin's RAM usage
- Thread starter LawsHosting
- Start date
LawsHosting
Verified User
I restarted and instantly went to ~750MB, and climbing......
Here is a log snippet:
Is this every-minute task normal?
A few extra notes to add:
* I have the session timeout duration set to 1 week - due to only me using the whole VPS and needing to use phpmyadmin a lot;
* I am logged into my DA account via the Impersonate option in admin;
Here is a log snippet:
Code:
28/9/2026 22:13:11 finished task duration=24.208726ms task=action=service-watchdog
28/9/2026 22:13:11 executing task task=action=service-watchdog
28/9/2026 22:13:11 finished task duration=5.51921ms task=action=ssl&value=admin_ssl
28/9/2026 22:13:11 executing task task=action=ssl&value=admin_ssl
28/9/2026 22:12:11 finished task duration=25.378017ms task=action=service-watchdog
28/9/2026 22:12:11 executing task task=action=service-watchdog
28/9/2026 22:12:11 finished task duration=6.52196ms task=action=ssl&value=admin_ssl
28/9/2026 22:12:11 executing task task=action=ssl&value=admin_ssl
28/9/2026 22:11:34 license updated successfullyA few extra notes to add:
* I have the session timeout duration set to 1 week - due to only me using the whole VPS and needing to use phpmyadmin a lot;
* I am logged into my DA account via the Impersonate option in admin;
Last edited:
LawsHosting
Verified User
As there's a lack of input from the DA team, I guess I shouldn't worry? Or try to debug what's going on?
Thanks
Does the excessive memory usage only shows up in system services GUI, or does `ps o comm,rss -C directadmin` show similar numbers?
wila
Verified User
- Joined
- Dec 15, 2017
- Messages
- 113
In services it now shows up as using 4,91GB after 10 hours.
Via top it looks like this:
Bash:
# top
top - 10:03:23 up 3 days, 11:33, 1 user, load average: 0.69, 0.56, 0.58
Tasks: 194 total, 1 running, 193 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.2 us, 2.2 sy, 0.0 ni, 91.8 id, 0.0 wa, 0.0 hi, 0.8 si, 0.0 st
MiB Mem : 19996.7 total, 2198.6 free, 3433.0 used, 15191.8 buff/cache
MiB Swap: 11444.0 total, 11304.0 free, 140.0 used. 16563.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
737682 xxxxxd01 20 0 386224 78516 63028 S 10.3 0.4 0:16.43 php-fpm
655806 root 20 0 4276772 194392 48432 S 5.3 0.9 4:16.70 directadmin
642 message+ 20 0 9436 4668 3860 S 3.0 0.0 8:52.81 dbus-daemon
897 mysql 20 0 2616636 411168 13784 S 3.0 2.0 327:56.85 mysqldand your requested output looks like so:
Bash:
# ps o comm,rss -C directadmin
COMMAND RSS
directadmin 177448
directadmin 27972
directadmin 30016Directadmin gets current memory usage from systemd (equivalent cli command: `systemctl show directadmin.service --property MemoryCurrent`), which gets its data from `/sys/fs/cgroup/system.slice/directadmin.service/memory.current` which shows all memory usage (including filesystem cache) `/sys/fs/cgroup/system.slice/directadmin.service/memory.stat` should show a bit more detailed memory usage breakdown.
wila
Verified User
- Joined
- Dec 15, 2017
- Messages
- 113
Just on time as in about 20 minutes the service will restart and we have to wait again a bit for the memory to build up.
So in services it is now listed as 4.99GB
and..
There's two other directadmin hosts were this does not happen. So something environment specific is causing this.
A few more notes.
- debian 12 bookworm
- directadmin 1.712 (117d8a4b5586c5533c5dd78ce0d1ae1ea356f586)
- legacy license (on all of them)
All hosts are on PHP8.3 as default using php-fpm.
Things only on this host are:
- PHP 8.1 (set as PHP4 in custombuild)
- proftpd (can be disabled, don't think anyone is using ftp anymore)
- notifications is enabled
- composer
- php_redis (have this on another host as well directadmin on that host is 1.3GB now after 4 days, but it might be differently configured, can check if php_redis is a suspect)
- php_imap
So in services it is now listed as 4.99GB
Bash:
# systemctl show directadmin.service --property MemoryCurrent
MemoryCurrent=5307293696
Bash:
# cat /sys/fs/cgroup/system.slice/directadmin.service/memory.stat
anon 129265664
file 4929630208
kernel 214556672
kernel_stack 737280
pagetables 1904640
sec_pagetables 0
percpu 9984
sock 0
vmalloc 0
shmem 0
zswap 0
zswapped 0
file_mapped 434176
file_dirty 4096
file_writeback 0
swapcached 4763648
anon_thp 77594624
file_thp 0
shmem_thp 0
inactive_anon 145555456
active_anon 27406336
inactive_file 4552691712
active_file 376938496
unevictable 0
slab_reclaimable 211110880
slab_unreclaimable 719760
slab 211830640
workingset_refault_anon 639
workingset_refault_file 808815
workingset_activate_anon 578
workingset_activate_file 436869
workingset_restore_anon 0
workingset_restore_file 28695
workingset_nodereclaim 0
pgscan 1579049
pgsteal 1512352
pgscan_kswapd 1579049
pgscan_direct 0
pgsteal_kswapd 1512352
pgsteal_direct 0
pgfault 5791411
pgmajfault 454
pgrefill 35203
pgactivate 13156
pgdeactivate 35203
pglazyfree 0
pglazyfreed 0
zswpin 0
zswpout 0
thp_fault_alloc 5821
thp_collapse_alloc 148There's two other directadmin hosts were this does not happen. So something environment specific is causing this.
A few more notes.
- debian 12 bookworm
- directadmin 1.712 (117d8a4b5586c5533c5dd78ce0d1ae1ea356f586)
- legacy license (on all of them)
All hosts are on PHP8.3 as default using php-fpm.
Things only on this host are:
- PHP 8.1 (set as PHP4 in custombuild)
- proftpd (can be disabled, don't think anyone is using ftp anymore)
- notifications is enabled
- composer
- php_redis (have this on another host as well directadmin on that host is 1.3GB now after 4 days, but it might be differently configured, can check if php_redis is a suspect)
- php_imap
So it seems that most of that memory: reclaimable filesystem cache that probably got read once by DA and never again touched. How/why it is accounted this way is currently a mystery: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory.
How much is reclaimable could be checked empirically by comparing
How much is reclaimable could be checked empirically by comparing
memory.stat and memory.current data before and after running the equivalent of echo 3 > /proc/sys/vm/drop_caches : echo "10G" > /sys/fs/cgroup/system.slice/directadmin.service/memory.reclaim (use at your own risk)
nsc
/dev/null
- Joined
- Jul 9, 2014
- Messages
- 46
You are probably worrying too much.
DirectAdmin touches a lot of files while it runs: user configs, certificates, logs it reads for stats and bandwidth, backups, and so on. Every time a file is read, Linux keeps a copy of it in RAM, so the next time it's needed it doesn't have to go to the disk again. That's much faster. systemd counts all that cached stuff toward the DirectAdmin service, which is why the number looks big.
Your own stats show this nicely. Out of the ~5 GB, DirectAdmin itself only uses less than 200 MB. Almost all the rest (~4.9 GB) is file cache (the "file line"), and most of it is marked as "not used lately," (the "inactive_file" line) so it's the first thing the system throws away when memory is needed.
You can see DirectAdmin's real usage in top in the RES column. Sort by memory with:
Bash:
top -o %MEMFor your DirectAdmin it's around 190 MB, nowhere near 5 GB.
Same story with the free command. You don't look at the "free" column, but rather check "available." On your server that's about 16.5 GB out of 20 GB, so you have plenty of room. On Linux, lower side "free" memory is normal and actually means RAM is being put to good use.
You are not doing drop_caches periodically for those counts to match, are you?
So there's no need to restart the service or clear caches by hand. The system cleans this up on its own, behind the scenes, whenever something needs more memory.
wila
Verified User
- Joined
- Dec 15, 2017
- Messages
- 113
Thanks guys for the detailed answer.
I'm going to read all this in more details later once things calm down a bit.
Pretty busy with non hosting stuff atm. I'm aware about file caches being a good thing. Just didn't have the time to study or even remember all the different ways in which this is presented on linux.
Wasn't worried too much as the 'systemctl restart directadmin' every 12 hours does not appear to have much (if any) side effects.
A bit weird though that it assigns all these file caches to the directadmin process (yes I get it, it is because it was directadmin that was doing the reading) that should just go to OS system cache IMO. Oh well.
I'm going to read all this in more details later once things calm down a bit.
Pretty busy with non hosting stuff atm. I'm aware about file caches being a good thing. Just didn't have the time to study or even remember all the different ways in which this is presented on linux.
Wasn't worried too much as the 'systemctl restart directadmin' every 12 hours does not appear to have much (if any) side effects.
A bit weird though that it assigns all these file caches to the directadmin process (yes I get it, it is because it was directadmin that was doing the reading) that should just go to OS system cache IMO. Oh well.