Hi
Is it normal that the WAN accelerator service continues to hold memory even after all jobs are finished?
Using memory during the copies are OK but after all jobs are finished we still see that the service is having 26 GB in Commit and Working Set, is this normal or should I cretae a case to look it up?
//Mats
-
- Expert
- Posts: 170
- Liked: 15 times
- Joined: Apr 20, 2018 8:12 am
- Full Name: Mats Holm
- Contact:
-
- Veteran
- Posts: 1943
- Liked: 247 times
- Joined: Dec 01, 2016 3:49 pm
- Full Name: Dmitry Grinev
- Location: St.Petersburg
- Contact:
Re: WAN accelerator not releasing memory
Hi Mats,
That's not normal behavior.
Kindly raise a support ticket and share case ID here, so we can track it internally. Thanks!
That's not normal behavior.
Kindly raise a support ticket and share case ID here, so we can track it internally. Thanks!
-
- Product Manager
- Posts: 2579
- Liked: 708 times
- Joined: Jun 14, 2013 9:30 am
- Full Name: Egor Yakovlev
- Location: Prague, Czech Republic
- Contact:
Re: WAN accelerator not releasing memory
Hi Mats!
Both Commit and Working Set memory pages could be(or not) shared between processes. Also Commit memory doesn't necessarily mean that memory pages were allocated from physical memory(aka virtual memory was allocated, but was never accessed, thus physical memory pages were not reserved).
It is worth checking Microsoft VMMap utility, that will show better if memory was actually eaten by a process, reserved and is not available for allocation to other processes, or it is shared and free. Even though Task Manager will show 26GB in Commit by WAN Accelerator, it might have come that 25.5GB out of those are actually free for allocation to other processes on demand.
Please check memory allocation on our service and if it is actually reserved and not freed for allocation after the process, than it should be definitely investigated further with support.
Hope that helps!
Both Commit and Working Set memory pages could be(or not) shared between processes. Also Commit memory doesn't necessarily mean that memory pages were allocated from physical memory(aka virtual memory was allocated, but was never accessed, thus physical memory pages were not reserved).
It is worth checking Microsoft VMMap utility, that will show better if memory was actually eaten by a process, reserved and is not available for allocation to other processes, or it is shared and free. Even though Task Manager will show 26GB in Commit by WAN Accelerator, it might have come that 25.5GB out of those are actually free for allocation to other processes on demand.
Please check memory allocation on our service and if it is actually reserved and not freed for allocation after the process, than it should be definitely investigated further with support.
Hope that helps!
Who is online
Users browsing this forum: No registered users and 47 guests