By coincidence i just noticed that this time the high CPU usage started when another client started up and connected. Maybe they were syncing file lists or something like that. Yet the data transfer was pretty low.
After several minutes the CPU usage went down again.
I have installed now Debugging Tools for Windows and next time i see it i will make some stackdumps of the active threads. This should be useful to determine what is happening there.
There’s a bit of housekeeping going on when a device connects: Exchanging config messages, potentially exchanging indexes (both wont show up as high data transfer) and after that, a sync operation is scheduled. Unless there is anything to sync (which it doesn’t look it is), that should all be fairly cheap. Another option is, that it’s web UI related: On connect it might do REST queries to the DB. You could test that by not having the UI open when a device connects.
go tool pprof -web with the filename appended is what I use.
In your case most of the time is spent in low-level functions of the database, some more in the filesystem (stating) and matching to ignores. So essentially I have no clue what’s going on/why it takes so long.
The latter happens due to scanning, and lots of the time spent in db seems to be triggered from the web UI. Both shouldn’t happen as far as I am concerned - logs with model and api debug logging might sheld light on it.
