Hey all,
SSPService.exe is bringing numerous windows 10 pro machines to a crawl in my department where the memory usage is 99-100% as seen under Processes in the task manager. This appears to be 100% of the time.
What is the current solution? These machines are all on latest updates for Sophos and windows.
Thanks,
matt
Hello,
We are also experiencing the same problem, it is really bogging down some desktops. We have also had the issue on one of our Windows servers.
The windows server in question has 16GB of RAM allocated to it (simple file server) yet the SSP Service was using around 12GB of this. Killed the service and restarted it and it is now okay. Have had to upgrade the RAM on a few machines in the last week or so due to reported slowness, I think this may be the cause.
All Sophos software is fully up to date.
That memory consumption is not right and sounds like a bug. Do you know how it grows?
If you restart SSPService and start
typeperf "\Process(sspservice)\Working Set - Private" -si 30 -o C:\ssp.csv
What does C:\ssp.csv look like after say 3 hours? Has it grown? Maybe after 6 hours? Is it a straight line or does it step up at certain times.
It would be good to get a ETL trace when it's leaking, e.g. From an admin prompt:
wpr.exe -start VirtualAllocation
leave it for up to 4 mins, ideally when leaking based on previous data. Then run:
wpr.exe -stop C:\VirtualAllocation.etl
Should be possible for Support to use this trace and the csv to say why the memory is growing, at least in the captured time frame. Problem being, it could be memory is allocated that is freed just outside the trace. The csv for a while first might make it apparent when would be a good time to trace,
Hope it helps.
That memory consumption is not right and sounds like a bug. Do you know how it grows?
If you restart SSPService and start
typeperf "\Process(sspservice)\Working Set - Private" -si 30 -o C:\ssp.csv
What does C:\ssp.csv look like after say 3 hours? Has it grown? Maybe after 6 hours? Is it a straight line or does it step up at certain times.
It would be good to get a ETL trace when it's leaking, e.g. From an admin prompt:
wpr.exe -start VirtualAllocation
leave it for up to 4 mins, ideally when leaking based on previous data. Then run:
wpr.exe -stop C:\VirtualAllocation.etl
Should be possible for Support to use this trace and the csv to say why the memory is growing, at least in the captured time frame. Problem being, it could be memory is allocated that is freed just outside the trace. The csv for a while first might make it apparent when would be a good time to trace,
Hope it helps.
Hello,
Thanks for the reply, I will try the above. The ssp service is not running currently as i have killed it off temporarily. However when you start it, the memory usage slowly goes up and up at a constant rate to around 9/10GB where it rounds off and sits.
OK, It might also be worth also creating a couple of process dumps, one after say 5 mins, then anohter after 1hr, if the mem usage has gone up enough to feel like the issue. E.g.
procdump -ma sspservice
Having downloaded procdump from Microsoft first. The 2 dmp files would be useful.
(PDH-CSV 4.0) (GMT Daylight Time)(-60),Process(sspservice)\Working Set - Private 06/28/2022 14:20:26.458,59428864 06/28/2022 14:20:56.465,80326656 06/28/2022 14:21:26.473,84545536 06/28/2022 14:21:56.478,92495872 06/28/2022 14:22:26.488,92868608 06/28/2022 14:22:56.492,96006144 06/28/2022 14:23:26.497,96096256 06/28/2022 14:23:56.502,96186368 06/28/2022 14:24:26.507,102445056 06/28/2022 14:24:56.512,102858752 06/28/2022 14:25:26.517,103731200 06/28/2022 14:25:56.521,105353216 06/28/2022 14:26:26.525,105349120 06/28/2022 14:26:56.530,105365504 06/28/2022 14:27:26.536,106070016 06/28/2022 14:27:56.542,106090496 06/28/2022 14:28:26.545,106344448 06/28/2022 14:28:56.550,106377216 06/28/2022 14:29:26.555,106696704 06/28/2022 14:29:56.560,106762240 06/28/2022 14:30:26.563,109686784 06/28/2022 14:30:56.567,109686784 06/28/2022 14:31:26.573,109973504 06/28/2022 14:31:56.576,110186496 06/28/2022 14:32:26.582,111980544 06/28/2022 14:32:56.586,112066560 06/28/2022 14:33:26.591,112099328 06/28/2022 14:33:56.595,112455680 06/28/2022 14:34:26.599,112537600 06/28/2022 14:34:56.606,112623616 06/28/2022 14:35:26.611,112668672 06/28/2022 14:35:56.616,114192384 06/28/2022 14:36:26.621,114597888 06/28/2022 14:36:56.624,292380672 06/28/2022 14:37:26.628,526237696 06/28/2022 14:37:56.631,760905728 06/28/2022 14:38:26.637,996491264 06/28/2022 14:38:56.692,1187725312 06/28/2022 14:39:26.699,1360867328 06/28/2022 14:39:56.703,1587359744 06/28/2022 14:40:26.707,1800630272 06/28/2022 14:40:56.715,2014617600 06/28/2022 14:41:26.720,2217496576 06/28/2022 14:41:56.727,2434723840 06/28/2022 14:42:26.733,2653696000 06/28/2022 14:42:56.738,2863337472 06/28/2022 14:43:26.775,3077095424 06/28/2022 14:43:56.781,3299995648 06/28/2022 14:44:26.785,3496865792 06/28/2022 14:44:56.788,3711782912 06/28/2022 14:45:26.789,4055142400 06/28/2022 14:45:56.794,4283002880 06/28/2022 14:46:26.837,4500381696 06/28/2022 14:46:56.841,4713910272 06/28/2022 14:47:26.846,4928405504 06/28/2022 14:47:56.849,5142044672 06/28/2022 14:48:26.855,5348343808 06/28/2022 14:48:56.864,5557387264 06/28/2022 14:49:26.882,5775171584 06/28/2022 14:49:56.887,5995999232 06/28/2022 14:50:26.893,6208286720 06/28/2022 14:50:56.898,6426951680 06/28/2022 14:51:26.903,6633881600 06/28/2022 14:51:56.910,6849871872 06/28/2022 14:52:26.915,7082323968 06/28/2022 14:52:56.919,7333470208 06/28/2022 14:53:26.924,7568183296 06/28/2022 14:53:56.931,7797641216 06/28/2022 14:54:26.938,8013692928 06/28/2022 14:54:56.942,8241111040 06/28/2022 14:55:26.945,8488599552 06/28/2022 14:55:56.951,8712019968 06/28/2022 14:56:26.958,8932618240 06/28/2022 14:56:56.964,9164881920 06/28/2022 14:57:26.967,9392046080 06/28/2022 14:57:56.971,9574977536 06/28/2022 14:58:26.975,9594064896 06/28/2022 14:58:56.979,9617920000 06/28/2022 14:59:26.982,9632935936 06/28/2022 14:59:56.987,9650221056 06/28/2022 15:00:26.991,9668907008 06/28/2022 15:00:56.996,9684529152 06/28/2022 15:01:26.999,9705332736 06/28/2022 15:01:57.002,9724690432 06/28/2022 15:02:27.005,9727123456 06/28/2022 15:02:57.011,9727123456 06/28/2022 15:03:27.015,9727123456 06/28/2022 15:03:57.020,9727123456 06/28/2022 15:04:27.026,9727123456 06/28/2022 15:04:57.029,9727123456 06/28/2022 15:05:27.032,9727242240 06/28/2022 15:05:57.035,9727262720 06/28/2022 15:06:27.040,9727254528 06/28/2022 15:06:57.045,9727275008 06/28/2022 15:07:27.048,9727299584 06/28/2022 15:07:57.052,9727287296 06/28/2022 15:08:27.056,9727295488 06/28/2022 15:08:57.061,9727291392 06/28/2022 15:09:27.067,9725644800 06/28/2022 15:09:57.071,9726660608 06/28/2022 15:10:27.076,9725452288 06/28/2022 15:10:57.080,9724338176 06/28/2022 15:11:27.085,9732124672 06/28/2022 15:11:57.089,9755738112 06/28/2022 15:12:27.092,9769054208 06/28/2022 15:12:57.097,9785245696 06/28/2022 15:13:27.102,9807208448 06/28/2022 15:13:57.106,9825140736 06/28/2022 15:14:27.110,9845714944 06/28/2022 15:14:57.172,9869881344 06/28/2022 15:15:27.184,9880129536 06/28/2022 15:15:57.188,9880133632 06/28/2022 15:16:27.193,9880002560 06/28/2022 15:16:57.196,10016993280 06/28/2022 15:17:27.199,10155802624 06/28/2022 15:17:57.205,10335399936 06/28/2022 15:18:27.210,10519040000 06/28/2022 15:18:57.214,10697105408 06/28/2022 15:19:27.226,10828603392 06/28/2022 15:19:57.229,11003703296 06/28/2022 15:20:27.233,11178434560 06/28/2022 15:20:57.240,11352551424 06/28/2022 15:21:27.243,11530559488 06/28/2022 15:21:57.247,11603230720 06/28/2022 15:22:27.252,11798773760 06/28/2022 15:22:57.256,11861561344 06/28/2022 15:23:27.260,11935592448 06/28/2022 15:23:57.263,12117635072 06/28/2022 15:24:27.267,12256423936 06/28/2022 15:24:57.269,12185374720 06/28/2022 15:25:27.274,12305600512 06/28/2022 15:25:57.279,12506542080 06/28/2022 15:26:27.283,12671156224 06/28/2022 15:26:57.286,12807131136 06/28/2022 15:27:27.290,12770263040 06/28/2022 15:27:57.293,12587966464 06/28/2022 15:28:27.297,12589879296 06/28/2022 15:28:57.300,12555370496 06/28/2022 15:29:27.304,12484022272 06/28/2022 15:29:57.307,12324458496 06/28/2022 15:30:27.312,12417359872 06/28/2022 15:30:57.324,12301557760 06/28/2022 15:31:27.328,12274298880 06/28/2022 15:31:57.331,12274364416 06/28/2022 15:32:27.336,12356751360 06/28/2022 15:32:57.339,12425469952 06/28/2022 15:33:27.342,12426596352 06/28/2022 15:33:57.347,12547010560 06/28/2022 15:34:27.350,12615790592 06/28/2022 15:34:57.354,12579577856 06/28/2022 15:35:27.358,12577247232 06/28/2022 15:35:57.363,12568354816 06/28/2022 15:36:27.368,12579176448 06/28/2022 15:36:57.372,12611710976 06/28/2022 15:37:27.376,12648513536 06/28/2022 15:37:57.379,12680724480 06/28/2022 15:38:27.383,12698955776 06/28/2022 15:38:57.387,12713439232 06/28/2022 15:39:27.390,12724203520 06/28/2022 15:39:57.397,12708950016
Wouldnt let me upload the .csv so I have converted it to .txt but here. I could only run for an hour and a half before users started to complain of slowness.. You can see it gradually increase to 9727123456 where it hovers for a bit before continuing to 12708950016.
Noticed this happening on another server now. Server had a total of 8GB RAM but had 20GB committed to the sspservice...eating into the storage as a "virtual memory/page file" (as i understand it anyway)
Sorry I missed the reply, given it grows so quickly I would run:
wpr.exe -start VirtualAllocation
Leave it for 3 minutes while growing, then run:
wpr.exe -stop C:\VirtualAllocation.etl
if you give that to Sophos they should be able to see the stacks responsible for the mem allocations.
