D
David P51
Hello Community,
I was hoping perhaps someone could help me. We are a small company running Windows 2012 R2 and using Work Folders for our Windows 10 clients. I have just under 50 Windows 10 users using Work Folders and for the last two weeks our file server's SyncShareSvcs starts consuming all the memory and all the pagefile to syncing client's files/folders.
On 02/18/20, we installed The rollup for Windows Server (KB4537821), the .Net Framework rollup, (KB4538124) and the Windows Malicious Software removal tool (KB890830). I did not read anything about these updates affecting the SyncShare service, but something is up.
The server is a 2012 R2 server and I had to increase the memory from a happy 8 GB to a full 32 GB. The pagefile is managed by the OS and is on a different lun than the Work Folders lun. This is a VMWare infrastructure and we have adequate memory and CPU for all eight of our servers, so it is not a hardware issue, rather just the SyncShareSvcs runs the system out of memory and keeps all of it in Private Bytes.
Using Process Explorer from Sysinternals, the SyncShareSvcs will consume 32 GB of ram in Private Bytes, while the Working Set will range around 3 GB of memory usage, which is what it used to consume. I have all the defaults set for Work Folders and it polls every 10 minutes for changes. If I stop the SyncShareSvcs, then run [esentutl /d meta.edb] against the SyncShareState\Workfolders\Metadata\meta.edb, it takes about 10.5 seconds to defrag the .edb file and the service will run for about 24 hours before taking all the memory on the system again. The meta.edb file is 578 MB plus another ~97 .log files that are a simple MB each.
This is just a file server, no other services or applications are running on it aside from Backup Exec and Symantec Antivirus. Those applications are not doing anything during these periods of high memory usage. This is literally just the SyncShareSvcs process.
If anyone has experienced this or knows of a fix, I would really appreciate it!
Thank you,
-David
Continue reading...
I was hoping perhaps someone could help me. We are a small company running Windows 2012 R2 and using Work Folders for our Windows 10 clients. I have just under 50 Windows 10 users using Work Folders and for the last two weeks our file server's SyncShareSvcs starts consuming all the memory and all the pagefile to syncing client's files/folders.
On 02/18/20, we installed The rollup for Windows Server (KB4537821), the .Net Framework rollup, (KB4538124) and the Windows Malicious Software removal tool (KB890830). I did not read anything about these updates affecting the SyncShare service, but something is up.
The server is a 2012 R2 server and I had to increase the memory from a happy 8 GB to a full 32 GB. The pagefile is managed by the OS and is on a different lun than the Work Folders lun. This is a VMWare infrastructure and we have adequate memory and CPU for all eight of our servers, so it is not a hardware issue, rather just the SyncShareSvcs runs the system out of memory and keeps all of it in Private Bytes.
Using Process Explorer from Sysinternals, the SyncShareSvcs will consume 32 GB of ram in Private Bytes, while the Working Set will range around 3 GB of memory usage, which is what it used to consume. I have all the defaults set for Work Folders and it polls every 10 minutes for changes. If I stop the SyncShareSvcs, then run [esentutl /d meta.edb] against the SyncShareState\Workfolders\Metadata\meta.edb, it takes about 10.5 seconds to defrag the .edb file and the service will run for about 24 hours before taking all the memory on the system again. The meta.edb file is 578 MB plus another ~97 .log files that are a simple MB each.
This is just a file server, no other services or applications are running on it aside from Backup Exec and Symantec Antivirus. Those applications are not doing anything during these periods of high memory usage. This is literally just the SyncShareSvcs process.
If anyone has experienced this or knows of a fix, I would really appreciate it!
Thank you,
-David
Continue reading...