When starting the urbackup service, it occupies less than 20MB.
A few days later, it grows to a few gigabytes.
After restarting the service, it gets back to less than 20MB.
Running on Ubuntu 18.04, storage is on ext4.
How much RAM on server, how many clients backed up?
Database servers use available RAM if it’s there to optimize performance.
6GB total RAM, 4 clients.
Another thing I noticed, is that right when the service starts, it uses about 6 processes, and it grows from there to 100+ processes over time. I don’t know if it’s normal behavior.
Hi
If it s really that, it doesn’t sounds right.
I can actually do nothing for you , but you should post more detailed infos, like process list and ram usage using the most precise way you can think of. To know if t s memory used, resident, shared, if it’s the urbackup process , or the total threads on server and whatnot. Maybe compare after 1 day, one week, one month usage.
The threads also have names and it would be interesting which ones are running. There should be ~2 per idle running client.
htop can be setup to show them + ps with option e.g. -o 'pid tid cmd comm'
I have noticed the same on my server. Two days ago the machine was running out of RAM (8GB)+Swap (1GB). No backups were in process. The urbackupsrv process was using almost all of it. I restarted it and it went back down to less than 100MB usage (I don’t recall the exact amount). It’s now about 460MB. I’m running 2.2.11 compiled from source on Slackware64 14.2.
This is a server instance running for > 3 days as an example (htop, Linux):
It has a lot of active backups and clients so the memory usage is okay. It has 260 threads. For memory usage you’d need to substract the SHR column from the RES column. The VIRT column is kind of irrelevant for memory usage.
I have some more data. I set up a cron job to run “ps -vp” on the urbackupsrv PID every day at 5pm and log it (below). At this time of the day the system is completely idle as it is well outside both the backup and cleanup windows. Every day the process’s RAM consumption (RSS) goes up. There are a couple points where the RSS goes down, but I believe that is because it is being swapped to disk. According to /proc/{urbackupsrv pid}/status the VmSwap is up to 500MB. The system has 8GB of RAM so in order for this to be pushed to swap it’s got to be untouched data.
17:00:01 up 1 day, 7:04, 1 user, load average: 0.36, 1.07, 1.13
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 0:01 35 6287 5405288 63332 0.7 /usr/bin/urbackupsrv run -d
--
17:00:01 up 2 days, 7:04, 0 users, load average: 0.02, 0.04, 0.00
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 91:36 57718 6287 5475800 576748 7.2 /usr/bin/urbackupsrv run -d
--
17:00:01 up 3 days, 7:04, 0 users, load average: 0.14, 0.07, 0.02
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 109:30 133635 6287 5394192 716016 8.9 /usr/bin/urbackupsrv run -d
--
17:00:01 up 4 days, 7:04, 0 users, load average: 0.12, 0.11, 0.09
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 114:39 134536 6287 5394192 713160 8.9 /usr/bin/urbackupsrv run -d
--
17:00:01 up 5 days, 7:04, 0 users, load average: 0.05, 0.05, 0.00
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 190:58 148514 6287 5509000 858896 10.7 /usr/bin/urbackupsrv run -d
--
17:00:01 up 6 days, 7:04, 0 users, load average: 0.11, 0.06, 0.01
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 246:12 168476 6287 5459888 1043412 13.0 /usr/bin/urbackupsrv run -d
--
17:00:01 up 7 days, 7:04, 0 users, load average: 0.01, 0.07, 0.04
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 301:06 187948 6287 5476280 1168060 14.6 /usr/bin/urbackupsrv run -d
--
17:00:01 up 8 days, 7:04, 0 users, load average: 0.04, 0.07, 0.08
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 350:28 203781 6287 5550044 1315640 16.4 /usr/bin/urbackupsrv run -d
--
17:00:01 up 9 days, 7:04, 0 users, load average: 0.00, 0.01, 0.00
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 401:21 221838 6287 5517260 1494568 18.7 /usr/bin/urbackupsrv run -d
--
17:00:01 up 10 days, 7:04, 0 users, load average: 0.08, 0.08, 0.02
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 424:34 275850 6287 5451692 1412188 17.6 /usr/bin/urbackupsrv run -d
--
17:00:01 up 11 days, 7:04, 0 users, load average: 0.15, 0.08, 0.01
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 429:30 278675 6287 5451692 1404740 17.5 /usr/bin/urbackupsrv run -d
--
17:00:02 up 12 days, 7:04, 0 users, load average: 0.03, 0.14, 0.14
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 472:17 289191 6287 5550076 1456820 18.2 /usr/bin/urbackupsrv run -d
--
17:00:02 up 13 days, 7:04, 0 users, load average: 0.11, 0.05, 0.01
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 530:29 378265 6287 5606192 1394964 17.4 /usr/bin/urbackupsrv run -d
--
10:05:37 up 14 days, 9 min, 1 user, load average: 1.00, 0.66, 0.39
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
24065 ? Sl 576:20 396612 6287 5803296 1481156 18.5 /usr/bin/urbackupsrv run -dCould you post the number of shared pages (like in the screenshot above)?
It is currently 12024.
If you want to investigate this further, the best and easiest to use method I found recently is heaptrack ( https://github.com/KDE/heaptrack ).
It is difficult to compile (but you only need the command line, not the GUI part), but then it is easy to run, i.e. heaptrack urbackupsrv run. Please use a compiled version of urbackupsrv with debugging symbols.
Heaptrack will show some memory leaks, but that is usually stuff it allocates once. There is a command line option to urbackup server to reduce that, but that is currently not exposed on Linux.