Recommended Java Memory Settings for Java 8?

[Klaus Bachmaier, geändert vor 7 Jahren.]

In short: What are the recommended Memory Settings for a Liferay 6.2 Server running with Java 8?

My Problem: Our customer has the need to upload large video files to the document and media library. I've already adjusted the "File upload" settings in control panel, and now it's possible to upload video files up to 400MB. Whatever may be the reason, but when I click on the video file in the documet & media library the tomcat server crashes immediately. I'm just guessing that out of memory problems may be the reason for this, but there is nothing in the logs which may help me in fixing this issue. Nevertheless I would like to increase the memory available to my JVM when running Tomcat. That's why I ask about the recommended Memory Settings for Java 8.

[Juan Gonzalez, geändert vor 7 Jahren.]

Hi Klaus, I have 2 questions for you.

Do you have xuggler enabled?

If previous answer is "yes", what is the OS where your Liferay is being executed on?

Thanks.

[Klaus Bachmaier, geändert vor 7 Jahren.]

Yes, Xuggler is enabled. Servers are running on Windows 10 (dev) and WIndows Server 2008 (non-prod. and prod). Crash happenes when the video files exceed a certain limit (approx. 100 M

[Juan Gonzalez, geändert vor 7 Jahren.]

Ok, there is a known error in Xuggler and some Windows environments that can make Xuggler (and the JVM process executing it) crash.

Can you post here values of these portal-ext.properties property in your environment?

dl.file.entry.preview.fork.process.enabled

text.extraction.fork.process.enabled

Thanks!

[Klaus Bachmaier, geändert vor 7 Jahren.]

Hi Juan,

these are my properties setting:

dl.file.entry.preview.fork.process.enabled=true
text.extraction.fork.process.enabled=false

As an addition to my earlier post:

The server crash also happenes on all my customers Windows servers, even if the video file is kind of small (approx. 75M. On my local dev. PC (Windows 10) it works with videos of that size, but on Windows 2008/20012 servers Liferay crashes immedialtely when I try to open an uploaded video for preview in the D&M library, or even already when uploading the video file.

Liferay (Tomcat) ist configured to run as a service under windows. I used these settings when registering the service:

"%EXECUTABLE%" //IS//%SERVICE_NAME% ^
    --Description "Liferay Portal Server 6.2 " ^
    --DisplayName "%DISPLAYNAME%" ^
    --Install "%EXECUTABLE%" ^
    --LogPath "%CATALINA_BASE%\logs" ^
    --StdOutput auto ^
    --StdError auto ^
    --Classpath "%CLASSPATH%" ^
    --Jvm "%JVM%" ^
    --StartMode jvm ^
    --StopMode jvm ^
    --StartPath "%CATALINA_HOME%" ^
    --StopPath "%CATALINA_HOME%" ^
    --StartClass org.apache.catalina.startup.Bootstrap ^
    --StopClass org.apache.catalina.startup.Bootstrap ^
    --StartParams start ^
    --StopParams stop ^
    --JvmOptions "-Dcatalina.home=%CATALINA_HOME%;-Dcatalina.base=%CATALINA_BASE%;-Djava.endorsed.dirs=%CATALINA_HOME%\endorsed;-Djava.io.tmpdir=%CATALINA_BASE%\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Dfile.encoding=UTF8;-Djava.util.logging.config.file=%CATALINA_BASE%\conf\logging.properties" ^
    --JvmMs 4096 ^
    --JvmMx 4096

So there should be plenty of memory to process a 75MB video file.

[Juan Gonzalez, geändert vor 7 Jahren.]

Ok thanks Klaus, so I think you have two options:

* Change text.extraction.fork.process.enabled=true and add the video mime types in text.extraction.fork.process.mime.types property. This won't fix the actual issue but at least will keep your server more stable. But the metadata extraction for your files will keep failing.
* Compile xuggler for your enviromment (Windows). You can follow these instructions: (http://www.xuggle.com/xuggler/advbuild. It's known that latest sources from github are working fine in Windows.

Hope it helps.

[Klaus Bachmaier, geändert vor 7 Jahren.]

Thanks Juan, but I'm really not very happy with building the jar by myself from sources, because of the huge amount of additional software required on a Windows PC to build xuggler, which i feel would pollute my system. (Perl, gcc, gmake, yasm,pkg-config amongst others). So if anybody should have a prebuild xuggler jar for Windows 64bit I would gladly give it a try.

Btw: I'm using only EE Versions of Liferay, which come with xuggle-xuggler-arch-x86_64-w64-mingw32.jar and xuggle-xuggler-noarch.jar (hopefully in current versions)

[Juan Gonzalez, geändert vor 7 Jahren.]

Hi Klaus,

sorry but as that jar is a third party, we can't build and bundle it (they have some licenses that makes it not license friendly with Liferay for including it), so I think you could build it using some kind of dev environment so it doesn't "pollute" your prod servers.

FYI I've tried to find some other binary for some years, with no luck.

[srini vasulu, geändert vor 7 Jahren.]

Hi Klaus,
I am also facing same issue did you resolved the issues?
if yes how did you achieve this issue.


Juan,
Did you find any solution for this issue?

[Olaf Kock, geändert vor 7 Jahren.]

Klaus Bachmaier:

In short: What are the recommended Memory Settings for a Liferay 6.2 Server running with Java 8?

I recommend to have -Xmx the same as -Xms. Numerically, they should be large enough that you don't run out of memory and small enough for frequent quick - rather than infrequent long time - garbage collection. Also make sure to not run into virtual memory usage.

It might sound funny to not give numbers - but how would anyone know: People who don't upload 400M video will have different requirements than people who do. Bigger? Smaller? Well, it depends on what other operations they do, and with how many concurrent users. Seriously: You'll have to measure your server's requirement - determine if it's memory, CPU or I/O that you run out first. Adjust. Measure. Rinse/Repeat. If someone here gives you a number, it definitely will be wrong. It might fit your immediate needs, but then it's wrong for the next one coming along, just grabbing these settings.

(Reason for -Xmx to be the same as -Xms: When you start the server, you want to know immediately if you can or can't get all the memory you eventually plan to allocate for this process. Better fail immediately if you can't - that's better than sunday night at 3:00 in the night)

Sorry, no number - not from me ;)