java.lang.OutOfMemoryError: GC Overhead limit exceeded

[rollcage]

License Subsonic Premium
Version 6.0 (build a7857c) – April 30, 2016
Server jetty-6.1.x, java 1.8.0_121, Linux (146.1 MB / 175.0 MB)
Ubuntu 16.04.2 LTS

934 artists
2,291 albums
25,979 songs
235.18 GB

I'm seeing GC Overhead limit exceeded errors in Subsonic quite often. Sample:
[2017-03-19 17:25:54,779] WARN JaudiotaggerParser - Error when parsing tags in /var/music/Podcast/Marek vs. Wyshynski/mw_20161108_130414--November-8th-Edition-of-Marek-vs.-Wyshynski.mp3
java.lang.OutOfMemoryError: GC overhead limit exceeded

When I tail subsonic_sh.log, I see GC getting stuck (note uncompleted line):
[Full GC (Ergonomics) 159728K->159726K(179200K), 0.2495290 secs]
[Full GC (Ergonomics) 159726K->159726K(179200K), 0.2425956 secs]
[Full GC (Ergonomics) 159728K->159727K(179200K), 0.2426256 secs]
[Full GC (Ergonomics)

I have plenty of available RAM:
total used free shared buff/cache available
7780 2005 2094 120 3679 5219

top is showing java eating 324% CPU:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1191 root 20 0 4035984 431984 55584 S 324.3 5.4 70:02.24 java

thought it was heap size, but java is showing:
> java -XshowSettings:all
Max. Heap Size (Estimated): 1.69G

Any ideas how to fix this? The end result is that Subsonic crawls to a halt and I have to reboot my machine. The issue is becoming more and more common. I had the same issue on a previous ubuntu laptop that was ages old and had far less RAM. Eventually my Subsonic database corrupted. I moved to a faster laptop with more RAM and rebuilt the db ... this instance worked well for about 6 months before the GC overhead problem resurfaced.
Thanks!
Chris

[rollcage]

Refreshed myself on the Subsonic installation procedure and found the max-memory parameter in /etc/default/subsonic. Changed 200 to 500 and rebooted.
Upon reboot, I immediately see:
jetty-6.1.x, java 1.8.0_121, Linux (196.3 MB / 379.5 MB)
Assuming 196 is the heap size in use, I think 500 should be enough for the future.

[rollcage]

following up ...

... days later everything is still good after increasing max-memory parameter. So glad to have this fixed!