Very Slow loading with Fanart on

[m1abrams]

I have an Intel Nuc i5 with Windows 10 and SageTV v9 and Gemstone loaded running as a SageTV client to a Linux server.

Whenever I first start up the client or after several hours of inactivity when I go to the Recorded List SageTV gets the spinning wait for 30s or more. I have increased the Heap to 1200MB and I moved the fanart to a local disk on the client and still it is slow.

Any ideas? Attached are recent logs after start up and the first delay.

[jusjoken]

On a windows server or client the max heap should be 400 for 1024 MB total. Your Linux server can be higher.

Can you ensure gemstone logging is enabled in the utility options menu and then recreate the issue and post the sage client log and gemstone log from the logs folder.

k

[m1abrams]

I always thought 32bit java on Windows should be able to support min. 1.4GB heap size


Not much in the gemstone.log file

[jusjoken]

Originally Posted by m1abrams

I always thought 32bit java on Windows should be able to support min. 1.4GB heap size


Not much in the gemstone.log file

Ate you sure logging is on and set to debug in gemstone?

The phoenix log did not help either..fanart did initialize successfully just prior to the hang.

k

[Fuzzy]

Originally Posted by m1abrams

I always thought 32bit java on Windows should be able to support min. 1.4GB heap size


Not much in the gemstone.log file

32-bit java can support a 1.4GB heap size just fine (and sometimes larger), but it depends on what the program is doing. 32 bit windows programs are limited to 2GB of addressable memory. In the case of sagetv, that 2GB holds the JVM heap, as well as all the native bits of sagetv (which reside outside the java heap) as well as many different memory buffer objects (which are used for higher performance io operations - IO being the primary task a sagetv server performs). Increasing the heap larger than 1GB in theory would work, if you were not using the native memory for much - however, that often leads to out of memory errors and crashing, because sage is constantly allocating and unallocating the native memory for the various tasks it's performing. If any of those allocations fail, sage can (will) fail.

Leaving a full 1GB of native memory free has been shown to be quite stable, and for most people, going over that invites problems.