Over the course of the last week I have had a SP 2013 on-prem farm Install on a server (separate DB server) that has had high CPU for hours at a time. In services, I realized that the culprit was the "SharePoint Tracing Service." It was slowing down the server to a crawl at some points.
Here's what I did/ what I know:
Every time I restart the SharePoint Tracing Service in Services, the CPU usage would instantly stabilize, and become normal.
The "Log On" account for the SP Tracing Service was set to "Local Service".
The "Local Service" account had membership in the Performance Log Users and Performance Monitor Users Groups on the Local Server.
I checked that the Local Service Account was present in the Security Tab of WSSTRACESESSION14 in Performance Monitor.
It seems like a permissions issue, because when I look into the log files in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\logs, I see an Error code 5, (Win32 file store). This tells me that the tracing service (via the Local Service account) doesn't have the proper rights to write to the files possibly?
WHAT WORKED: I ended up just changing the Log On account for the SP Tracing Service to the default "Local System Account." This seemed to instantly fix the issue, and I don't see the access/write issue/error happening in the logs anymore.
That all being said, I still feel like setting the service to just use the Local System account is kind of a workaround. Is there something else I should still try in order for the Service to use the Local Service Account instead?
I don't know that a service that only writes logs to disk needs admin + network access via the Local System Account.
New Information: These screen captures are from ProcMon during the High CPU Usage. I can't upload the entire log because of included proprietary information: