B1643 ROCK log stats question

Early Access
1

I generally keep a close eye on memory stats in the server logs to try and see where and when the nonsense starts (zones disappear, app hangs etc).

With this latest build I see the stats are very different. Is this because memory use is actually different or is the way it is being reported changed ?

Typical stats over the last few months

03/05 09:14:36 [Local 03/05 09:14:36] Info: [stats] 19700mb Virtual, 8972mb Physical, 4082mb Managed, 4890mb estimated Unmanaged, 668 Handles, 102 Threads, 3.92% of runtime in GC pauses, 48ms last GC pause duration

B1643 stats

03/19 18:14:03 [Local 03/19 18:14:03] Info: [stats] 71022mb Virtual, 9946mb Physical, 4233mb Managed, 5713mb estimated Unmanaged, 1194 Handles, 78 Threads, 8.32% of runtime in GC pauses, 125ms last GC pause duration
03/19 18:14:04 [Local 03/19 18:14:04] Trace: [Headphones] [Lossless, 24/96 FLAC => 24/96] [100% buf] [PLAYING @ 0:25/6:40] Dub Conquers All - Dub Colossus

I still get zone drops needing a reboot so not sure what to make of this.

2

Hi, @ncpl, thank you for the report. I will pass this observation to our dev team.

Thanks!

–
Ivan

3

B1644 using similar memory ~71000 vs 16000 previously.

4

@ncpl I saw this post after reading…

Is your situation similar to what I describe in Memory under pressure: your experiences with Roon garbage collection?

“Interacting with Roon feels increasingly sluggish over time and when it lags, music playback and streaming to audio devices stops intermittently. The following usually happens because network communication failed while the Roon server froze during garbage collection.”

At first glance, your system numbers look normal to me:

  • Virtual: 71.022 GB
  • Physical: 9.946 GB
  • Managed: 4.233 GB
  • Unmanaged: 5.713 GB

But these do not look healthy:

  • % runtime in GC pause: 8.32%
  • Last GC pause duration: 125 ms

In processing time (not human wall clock time), 8.32% of the time Roon server was running, it was frozen due to garbage collection. That’s not good. Especially if those pauses are 100s of milliseconds long. For example, Roon expects a network socket to respond to a data request in microseconds, but Roon server may have paused processing for 500 ms, so the client gave up or retried several times, and you experience that as a slow or failed action.

If you care to, would you answer a few questions…

  1. After a Roon restart, how long does it take before you notice problems?
  2. Have you aggregated and looked at those [stats] over time?
  3. If you have, can you share the min, max, and median duration for GC pauses?