Too much memory usage

[satheesh]

Hi. Been testing the RC for a while now and on different clients and environments. One thing that is a recurring thing is that the memory usage is extremely high. Doesn't matter the OS or amount of mailboxes.

Anyone else notices this problem? Something that needs to be addressed for sure in future versions.


Direct link to image: http://bildr.no/image/UWxLdlN5.jpeg

[Gostev]

How high? Can you give us some numbers?

[Gostev]

OK, I used direct link to screenshot from your post code and it worked (4 GB).

[satheesh]

How high? Can you give us some numbers?

Sorry for not being clear, but let's say your server has 4 GB of RAM, it will then use almost all of it or for sure half. Doesn't really matter how much RAM you dedicate to the server. I've attached a couple more screenshots from another server. Also, it doesn't use anything when you start the server/service and no backup has yet been made. As soon as the backup is running and/or finished, the memory usage will be locked and never released. Even when the backup job(s) have finished.


Direct link to image: http://bildr.no/image/VGlzYVJi.jpeg


Direct link to image: http://bildr.no/image/NVpzWHBP.jpeg

[Gostev]

This is normal. Jet database cache consumes up to half of server's available RAM. This is by ESE design to make a good use of all available hardware.

[satheesh]

But isn't it supposed to release it after it's done backup up? Or not in use?

[Gostev]

No, there's no point in doing so, as this will slow down future job run or restore without any benefits whatsoever.

[arijnbeek]

Currently have Veeam Backup for Microsoft Office 365 running on a virtual machine with 8GB dedicated memory. The Veeam.Archiver.Service.exe is consuming 11.196.660 KB Commit memory and has a working set of 6.33.012 KB. The server becomes completely unresponsive until i remote kill this process. I have no active jobs running (there are all disabled) but did restore a couple of mailboxes back to office 365.

Not releasing memory for future job is ok but more then 100% is rediculus

you can contact me for more info

[foggy]

Alexander, could you please open a case with our technical support regarding this issue and share the case ID here? Thanks!

[Matt.Sharpe]

Is this still the use case/configuration of the JetDB? We are seeing extremely high memory consumption to a point the server doesn't respond. Does the JetDB still not release the RAM post job completions?

If you're running multi-tenancy and alot of different organizations and jobs. Then the RAM will build up over time and never release? Is there a way to manually clear the cache on a schedule etc?

[Polina]

Hi Matt,

Things have changed since 2016. There are still might be some cases when proxy RAM is overloaded (not necessarily caused by Jet), but our support engineers should be able to help you with this. Would you please open a support case and provide us your case ID?

Can you suggest which VBO version are you running?

[FAlter]

Hi,

I've just noticing a high memory consumption in task manager and found out it was a lot with veeam. I found this old thread but it seems it was never resolved. I don't have any issue noticed due to the high memory consumption (at least not yet). Veeam was only running idle in background at this moment in the afternoon, the backup is scheduled at nighttime.

Here the screenshot:
https://imgur.com/a/wRk13QI
TL;DR: Veeam.Archiver.Service 6GB, Veeam.Archiver-Proxy 3GB - The system has 16 GB in total so Veeam consumes more than half.

[Polina]

Hi @FAlter,

Are you running the latest build 7.0.0.4388?

[FAlter]

Hello Polina,

it is build 7.0.0.3968 according to about dialog. I wasn't informed about an available update and even when I check manually it tells me I am up to date.

A reboot temporarily lowers the memory consumption.

[Polina]

In 7.0.0.3968 there was a memory leak issue discovered, and it is now fixed in the latest 7.0.0.4388. For more details, please see this KB: https://www.veeam.com/kb4425

[FAlter]

The update to 7.0.0.4388 did fix the memory consumption issue. The system (and veeam services) haven't been rebooted for 12 days now and the memory consumption is ok.

[Mike Resseler]

Thanks for letting us know @FAlter
But please be aware that the issue (it is a MSFT memory leak) is still present. We have created some workarounds but keep an eye on it for now. I suspect that your memory usage is still higher as it was in CP3 or before