Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

pianoplayer98

macrumors newbie
Original poster
Aug 10, 2013
1
0
MBP Early 2011 on DP 4. About four hours after each boot, a process called "systemstats" starts to use an insane amount of resources - 4.1 GB of my 8 GB as well as 100% of CPU. Evidently this is the process that collects power usage data, and I am forced to force quit it in Activity Monitor to have a usable computer again. Did anyone else have this problem or know how to fix it? Thanks.
 

mrapplegate

macrumors 68030
Feb 26, 2011
2,818
8
Cincinnati, OH
MBP Early 2011 on DP 4. About four hours after each boot, a process called "systemstats" starts to use an insane amount of resources - 4.1 GB of my 8 GB as well as 100% of CPU. Evidently this is the process that collects power usage data, and I am forced to force quit it in Activity Monitor to have a usable computer again. Did anyone else have this problem or know how to fix it? Thanks.

Sorry I have no idea. It is behaving normally on my system. Other than the usual file a bug report, I have no other ideas.
There is one thread on the developer forums
https://devforums.apple.com/message/827251#827251
They don't have any suggestions other than file a report.
 

negativzero

macrumors 6502a
Jul 19, 2011
564
55
Reboot, reset PRAM and SMC.
Also try force quitting the process, it might reload and run properly afterward.
 

Bigua

Canceled
Oct 30, 2013
6
0
I dunno how to reset PRAM and SMC.
Every time systemstats go 100%, I kill it.

btw, sorry by my poor english ;_;
 

dysamoria

macrumors 68020
Dec 8, 2011
2,244
1,866
Yes. This just happened to me just now. That's why i came to this forum thread.

WTF is with this thing? When i force quit it, the CPU and memory amount decreased a lot, but the process did NOT disappear. i cannot actually get it to really be killed.

So they created a new system service to check what system resources are being used and wasted by software, and it wastes massive amounts of resources. WTF? It got so bad that my fans went full speed, the machine heated up, and the CPU use was over 150% and the entire system wasn't being responsive.

:mad::mad:

----------

https://discussions.apple.com/message/23720771#23720771
 

dysamoria

macrumors 68020
Dec 8, 2011
2,244
1,866
Question for all of you having this problem: did you have a new Mac volume being indexed at the time? i do/did. i found mds and its assorted services using a lot of resources. Looked it up and found that it is the indexing service. Sure enough, i had plugged in my old MacBook Pro 3,1 hard drive via external USB drive enclosure, and instead of importing the index from that drive, it's just indexing it all over again on the main machine. i don't know if there's a relationship, but i though i would mention it in case anyone else noticed the same.
 

hafr

macrumors 68030
Sep 21, 2011
2,743
9
Same here, it's showing 350 % CPU usage, so practically all of it...

Don't know what's causing it to act up.
 

cerberusss

macrumors 6502a
Aug 25, 2013
932
364
The Netherlands
The systemstats process maintains a database in the folder /private/var/db/systemstat.

Perhaps it's corrupted; you could try killing systemstat, removing that database (or better rename it) and reboot.
 

Bigua

Canceled
Oct 30, 2013
6
0
Hi, thanks a lot by the reply.

I've navigate to the folder, but theres many files there:
66AE884B-D915-4458-89D5-DEF73DC8FA47.boot.events.ewpspw.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.powerd.events.sjwIXw.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.events.ZNBcf0.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.01UZLv.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.0QoyfS.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.1C3y1o.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.1X9xYL.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.2Pw1of.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.2RaUcO.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.2jIwiz.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.ACno24.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.AsyrN2.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.BzHHCB.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.Cyu1aN.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.MPnX2H.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.MexFXN.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.N0COGT.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.QW94YW.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.Trbbx1.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.UFQS5m.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.UwqGoi.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.VuRFUI.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.eNOGeO.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.kSDcvm.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.klx8tE.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.pD1Bjt.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.pPNr6s.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.qQW0Gi.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.rJ7DxO.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.sz6zBi.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.tiyIJA.stats
66AE884B-D915-4458-89D5-DEF73DC8FA47.system_events.periodic.wJ7dvr.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.powerd.events.XgSePh.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.events.dSdX70.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.19hgws.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.1SFTRc.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.3TIuLM.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.3y10GY.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.6WGErR.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.6oe8nM.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.81TE4M.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.9RqCbx.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.9UoZn5.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.AZUBFL.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.AiI0HC.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.Asu7ph.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.BUnQeK.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.C0GCfo.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.DFH7tw.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.E0tjm9.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.EuYltP.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.FuW8ve.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.Fz0WWf.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.KkB1eo.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.M4oEZ5.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.N1FJEi.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.NyaP8H.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.PkQgfD.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.Qlql8O.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.QrwlF9.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.RTaahq.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.SR1Jzs.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.SYi3QQ.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.SiAhY2.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.TRyg8M.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.Ty7wxH.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.WLUVMS.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.Wrj5P3.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.WwxFJk.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.WxhpYD.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.YAC98g.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.Z1VEM5.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.ZvVIaf.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.e49Z0f.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.ftXd0J.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.hd3zcw.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.kiJ9sH.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.luNF9k.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.oPy85Z.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.p7myRI.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.pttAVm.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.rLtEWn.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.rh3xwK.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.rsCjFG.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.sFjV7q.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.uOLYy6.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.y7gzMz.stats
9326795C-358C-4D7E-8BEB-D6A746807EF5.system_events.periodic.zKJljj.stats
current_boot_uuid
current_build
last_boot_uuid
last_build
retired
snapshots.db
snapshots.db-shm
snapshots.db-wal
state.plist
usage.plist

What is the DB? snapshots?
 

cerberusss

macrumors 6502a
Aug 25, 2013
932
364
The Netherlands
If I had to guess, the .stats files are one-time snapshots captures of resource use (resources being memory, CPU, disk usage). And the snapshots.db is probably the database, the aggregation of the .stats files.

I'd just stop the process and then rename the folder itself. That way, after a reboot everything will be recreated, I'd hazard to guess.

Run TimeMachine before doing so :)
 
  • Like
Reactions: prisstratton

Bigua

Canceled
Oct 30, 2013
6
0
Well seens like this time it works, I've renamed the folder 6 days ago, and the process not misbehave more.

thanks a lot. and again, sorry by my poor english.
 

kwamayze

macrumors member
Jun 17, 2011
31
2
MBP Early 2011 on DP 4. About four hours after each boot, a process called "systemstats" starts to use an insane amount of resources - 4.1 GB of my 8 GB as well as 100% of CPU. Evidently this is the process that collects power usage data, and I am forced to force quit it in Activity Monitor to have a usable computer again. Did anyone else have this problem or know how to fix it? Thanks.

Same problem here on early 2011 macbook pro
 

JGarrido

macrumors newbie
Feb 7, 2014
1
0
So is that essentially the prognosis and solution? The files in that folder are corrupt, so rename/delete the folder to resolve the issue?
 

prisstratton

macrumors 6502a
Dec 20, 2011
542
126
Winnipeg, Manitoba, Canada
If I had to guess, the .stats files are one-time snapshots captures of resource use (resources being memory, CPU, disk usage). And the snapshots.db is probably the database, the aggregation of the .stats files.

I'd just stop the process and then rename the folder itself. That way, after a reboot everything will be recreated, I'd hazard to guess.

Run TimeMachine before doing so :)

I know this thread is a little old, but it did help me and I would like to recognize that help.

I ran across this thread looking for a solution to a runaway systemstats process on my Mavericks server. I had found that killing the process worked, but only temporarily. This seem’s to be more of a permanent solution. Since I did this the systemstats process is behaving itself, I am still keeping an eye on things, but so far so good.

Thank you for your suggestion.

Edit: The above fix lasted for about 3 weeks.

Edit #2: Make sure that the folder is not available and the process cannot work. If you reboot, the folder will be re-created, immediately go and find the folder and rename it. This seems to be working……….Feb 02/17

Edit #3: Still working great..........Mar 28/17

Edit #4: Oct 23/17, server has now been "up" for 314 days without a problem
 
Last edited:
  • Like
Reactions: cerberusss
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.