I'm not sure if this is a result of the latest updates made to the software, but something seems to be seriously wrong with synthetic full backups. All of our client's are configured as follows with image backups. Daily incrementals images, with monthly synthetic full images on the 1st day of each month to Wasabi. Today is the 1st of the month, so all of our client's are running their synthetic fulls. I woke up this morning to several client complaints of slow performance on servers and some so bad they were inaccessible. We quickly found that Cloudberry is absolutely pegging RAM utilization on the majority of our client's servers that are doing their synthetic full backups
For instance, I have a client that has 32GB's of RAM and out of this Cloudberry was using over 30GB's of RAM, and I've found the same situation on multiple client's servers. This is a major issue and we're not sure what to do at this point. I've opened a ticket with support and was told it would be escalated to engineers, but have heard nothing back as of now. It doesn't make sense that I can run a full new backup quicker than I can run a synthetic full backup. Because of this issue, we've had to stop the backups just so the client can continue working. I'm in dire need of help with this.
High RAM utilization during the synthetic full is a known issue, it was escalated to our R&D Team and they are currently investigating it and working on the fix.
Have you already sent the diagnostic logs from one of the affected servers? If you have, could you please let me know the associated ticket number, so I can check the logs and provide more details on this issue?
Anton, following up as this issue is still occuring. Really hoping for a fix to resolve this. Today is the 1st of the month and we're having the same problems as we were previously. I've had a ticket open for a month and it was escalated to the developers, but I haven't heard anything back. Thanks.