Question High memory consumption while uploading Plesk backup to external storage

[Nextgen-Networks]

Server operating system version

Ubuntu 20.04.6 LTS

Plesk version and microupdate number

Plesk Obsidian version 18.0.51 Update #1

When transferring Plesk backups to external storage targets, an unusually high memory load on the Plesk server can be observed.
Apparently, the entire available RAM is used for transferring the backups (see also screenshot from monitoring).
This leads to a massively slowed down overall system and also to timeouts for some requests and has a particularly severe effect when large full backups are moved to the external storage target, as this can take several hours.


Occurred with the following storage targets:
- FTP(S)
- S3 block storage

This behavior occurs with 2 Plesk installations, each with the same version level. (Ubuntu 20.04.6 LTS - Plesk Obsidian version 18.0.51 Update #1)

Does this behavior also occur with other Plesk installations?
Is there any way to limit the amount of memory needed to transfer the backup?
... or is this in fact a bug?

 

[Peter Debik]

I don't see anything wrong with memory usage according to your screenshot. The biggest part is cached content. That will not impact performance negatively unless in addition to physical RAM swap is being used. The slowing you may experience rather comes from compression and CPU utilization. That would be normal, because compression is a cpu intensive operation. If you want to avoid this, you can try to disable compression on backups. You can also adjust the I/O and cpu niceness levels, so that backup gets the lowest priority and other processes always come first. This will slow down the backup, but ensure that other processes retain a good performance. The setting can be applied in the general backup settings page.

 

[Nextgen-Networks]

Hey Peter,

thank you for the quick reply.
I don't think that the poor performance of the system is due to the CPU load, which is also quite moderate.

A possible and in the monitoring difficult to recognize cause came to my mind in the follow-up to the text written by me: Disk I/O
Possibly their performance/capacity is too low, that this slows down the system correspondingly.
I'll test this later witch YABS but not sure what to take as comparison/baseline (any hints are welcome ;-) ).

I have in any case taken your tip seriously to run the planned backup with lower priority and will observe this more closely at the next planned full backup in 7 days.

 

[ford]

Hello,
what was the result, I have the same problem

 

[bgptbg]

I have the same problem when backup to ftp too:

CentOS Linux 7.9.2009 (Core)
Version 18.0.57 Update #3

 

[Peter Debik]

@bgptbg What problem do you see?

 

[bgptbg]

I suspect there is a connection, but I can't confirm it exactly. The longer the server runs, the more memory is cached. Especially when it comes to backup processes. Sending a small or even empty email sometimes takes up to a minute. Only restarting the server will help and everything will run smoothly again.

 

[Kaspar]

The longer the server runs, the more memory is cached.

That's to be expected (and perfectly fine), because thats how linux available utilizes memory. See Help! Linux ate my RAM! for more information.

Your swap usage doesn't look out of the ordinary either. But your swap space is rather small for a server with that amount of memory. (Plesk recommends a swap space of 1/2 times the amount of memory. )

Backups don't require a whole lot of memory, it's mainly a disk and CPU intensive task. When running backups, other processes might slow down because the CPU is occupied with the backup process. Peter explained this quite well I think in his previous post:

I don't see anything wrong with memory usage according to your screenshot. The biggest part is cached content. That will not impact performance negatively unless in addition to physical RAM swap is being used. The slowing you may experience rather comes from compression and CPU utilization. That would be normal, because compression is a cpu intensive operation. If you want to avoid this, you can try to disable compression on backups. You can also adjust the I/O and cpu niceness levels, so that backup gets the lowest priority and other processes always come first. This will slow down the backup, but ensure that other processes retain a good performance. The setting can be applied in the general backup settings page.