I have a really basic play! app which simply handles a couple of normal GET and POST requests and talks to a MySQL database, nothing fancy.
I ran play dist and transferred the zip file to my EC2 instance. After unzipping it, going to the bin folder and running ./myapp, I get a message:
Java HotSpot(TM) 64-Bit Server VM warning: Info: os::commit_memory ... error='Cannot allocate memory' (errorno=12)
There is insufficient memory for the Java Runtime Environment to continue.
I'm running Play version 2.2.1 and this instance has about 512MB of ram, with the 64-bit version of the Oracle JDK. Is this not enough to run a play! app or am I missing something?
Thanks.
Play Framework 2.3 now has a nifty little feature.
$ /path/to/bin/<project-name> -mem 512 -J-server
Shoule get the job done.
Read http://www.playframework.com/documentation/2.3-SNAPSHOT/ProductionConfiguration
Specifying additional JVM arguments
You can specify any JVM arguments to the start script. Otherwise the default JVM settings will be used:
$ /path/to/bin/ -J-Xms128M -J-Xmx512m -J-server
As a convenience you can also set memory min, max, permgen and the reserved code cache size in one go; a formula is used to
determine these values given the supplied parameter (which represents maximum memory):
$ /path/to/bin/ -mem 512 -J-server
Using play 2.2.1 I had to run play dist to generate the zip file. Then I copied that to the aws instance.
Once there, I extracted the zip and changed the executable file:
from:
local mem=${1:-1024}
to:
local mem=${1:-512}
That did it for me. I got the idea from here but I didn't want to just delete the logic they had there, so I just reduced the default value.
Also please note that on aws ec2 micro:
$ java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.14) (amazon-65.1.11.14.57.amzn1-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
So you have to use the same Java JDK when runnin play dist.
EDIT:
I updated java to openjdk 7 and was able to run the sample play applications without any errors.
Related
I have a spring boot app that is running well on AWS Linux VM. Now, I am trying to run it on Azure Linux VM.
I am launching the application using this command (just like I am doing on AWS):
java -Dspring.profiles.active=prod -jar /home/azureuser/myapp/myapp-server.jar
But nothing happens after this. It doesn't exit but there is no output/log message at all. Ideally, I should see output generated on the shell but it prints nothing. There is no error/exception stack trace.
The same jar is working fine on AWS Linux VM.
The only difference in my AWS and Azure VMs is that on AWS, I have Java 16:
openjdk version "16.0.2" 2021-07-20
OpenJDK Runtime Environment Corretto-16.0.2.7.1 (build 16.0.2+7)
OpenJDK 64-Bit Server VM Corretto-16.0.2.7.1 (build 16.0.2+7, mixed mode, sharing)
while on Azure VM, I have Java 17:
openjdk version "17.0.4.1" 2022-08-12 LTS
OpenJDK Runtime Environment Microsoft-40354 (build 17.0.4.1+1-LTS)
OpenJDK 64-Bit Server VM Microsoft-40354 (build 17.0.4.1+1-LTS, mixed mode, sharing)
But I have tested the jar on my local windows machine on Java 17 and it works fine.
Any idea what might be the issue? Is the output going somewhere else that I don't know about?
It is working. I launched the application and then got busy with something else. When I checked back on the window after 10-15 minutes, I saw the output.
The issue was that Azure VM is a lot slower/underpowered than AWS VM. Since the app starts up in a few seconds on AWS, I never imagined that it would be that slow on Azure. It is taking more than one minute for the first line of output to show and more than 5 minutes for the app to finish start up.
I am trying to run the sonar scanner on a docker virtual machine as part of my private Azure DevOps build server and am getting an error with the pagefile not having enough memory to complete the analysis. My docker image is running windows server core 2019 base image with JDK 11.0.13 installed and Sonarqube scanner 5.0.0. The server also has the following environment variables set to try and increase the Java VM size:
JAVA_OPTS="-Xms1024m -Xmx4608m"
SONAR_SCANNER_OPTS="-Xmx4608m"
My image is running with 5GB RAM and monitoring the container is showing that there is plenty of memory still available to use. I have noticed that the first time I run the scan after starting the container it runs fine but each attempt afterwards gets the error:
##[error]Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000789c00000, 703594496, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
Can someone please help me with why it is failing to allocate around 700MB when there is more than 2GB RAM available.
The versions of everything are:
Azure DevOps agents: 2.194.0
JDK: 11.0.13
Sonarqube scanner extension: 5.0.0
Docker: 20.10.7
Docker base image: dotnet/framework/sdk:4.8-gbt-windowsservercore-ltsc2019
The issue turned out to be related to the JavaXmlSensor detecting some very large xml test files in the test project, it was trying to load them into memory and analyse them causing the out of memory error.
To fix it I added **/*.xml to the sonar.exclusions and also added the same list of exclusions to the sonar.test.exclusions setting.
I'm facing an issue.
Currently running a build, in On-Demand Bamboo server in AWS, I'm getting an error and the log says:
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory.......failed; error='Cannot allocate memory' (errno=12)
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map XXXXX bytes for committing reserved memory."
Does anyone know how can I allocate memory to Bamboo, since is hosted in AWS? (I do not have much experience with both)
Thank you.
Did you ever solve this? I would start by checking the memory usage (free -m) and then try running the build outside of Bamboo, to see if that work as expected.
You can also update the setenv.sh file in the bamboo bin directory to add memory options. Update the JAVA_OPTS with some reasonable values, e.g. -Xmx768m -Xms512m, that makes sense for your build projects.
i am running tomcat 7.0.33 on windows server 2008 R2
(i installed tomcat as windows service)
JDK version: jdk1.6.0_25 64-bit
Tomcat options:
Java Virtual Machine: C:\Program Files\Java\jre6\bin\server\jvm.dll
(BTW, i don't have client folder inside jre)
Initial memory pool: 1000 MB
Maximum memory pool: 2000 MB
when i check the server status, i can see that the server is using
the memory i configured.
Environment Variables (SYSTEM VARIABLES) Configuration:
JAVA_HOME: C:\Program Files\Java\jdk1.6.0_25
Path: ...;%JAVA_HOME%\bin;....
do i need to add CATALINA_HOME and JAVA_OPTS system variables too ?
ISSUE: i have two web applications APP1,*APP2*
when i deploy each one separately, i can find that memory use for
APP1= 198 MB
APP2= 104 MB
Information about the applications:
APP1,APP2: Spring Maven applications that includes in the libraries other small maven spring applications.
APP1: contains webservices, that APP2 uses them.
if i tried to deploy both of them on same tomcat instance, i always get
java.lang.OutOfMemoryError: PermGen space
please advise what might be causing this issue.
the solution was beside setting initial & maximum memory pool, is to add -XX:MaxPermSize=1000m to the java options in the java tab.
You probably need to set/increase the MaxPermSize setting for your Tomcat instance. Note that the MAVEN_OPTS have nothing to do with Tomcat, those are options for the Maven command-line process (mvn). The fact that your application is a "maven" application means nothing at run-time as Maven is not involved in the running of your application, only the building of it.
In the \bin folder in your tomcat installation, there should be an application called "tomcat7.exe". You can use this to update the settings for your tomcat service.
Try something like
tomcat7.exe //US//[name of your tomcat service] --JvmOptions=-Xmx2g
-Xms1g -XX:MaxPermSize=512m
Edit: above statement should be on one line, not two...
I had a similar problem as our app run on Tomcat without problems when Tomcat run standalone and we kept getting permgen out of memory exceptions when running Tomcat as a service.
I found a solution simillar to the one of Pap. You need to access the Tomcat service configuration GUI by running bin/tomcat7w.exe //ES//name_of_service. There you go to the Java tab and set respective java properties directly - e.g.
-XX:MaxPermSize=1000m
Here is a blog post which helped me a lot explaining what all Tomcat settings are ignored by Tomcat when running as a service.
http://www.12robots.com/index.cfm/2010/10/8/Giving-more-memory-to-the-Tomcat-Service-in-Windows
You need to increase PermGen space. Add something like -XX:MaxPermSize=128m to your parameters (you can reserve more perm gen space if you want to). The -Xmx and -Xms settings are for heap whereas here you're running out of PermGen space which is administered separately.
Is there a way to reduce the memory required by the YUI compressor or is there another compressor able to run via command line in "low" memory environments?
My hosting provider has limits on the amount of memory and virtual memory I can use from the shell. Currently it looks like: ulimit -m 200000 -v 200000. The -v argument is the one that seem to have a real effect. I get one of the following two results when trying to run the YUI Compressor in this environment:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
or
Exception java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?
The difference is due to using the JVM arguments -Xms18m -Xmx18m for the second one. I can duplicate this effect on my local linux box with the following:
( ulimit -v 200000; java -Xmx18m -jar yui-compressor-2.4.2.jar -o foo-min.css foo.css )
I'm looking to build both javascript and the css on the hosting provider immediately after an update of the source code to push to the live site.
I was able to get the YUI Compressor to execute in the restricted memory space by using the Small Footprint Runtime Environment from Sun.
$ java -version
java version "1.5.0_10-eval"
Java(TM) 2 Runtime Environment, Standard Edition for Embedded (build 1.5.0_10-eval-b02, headless)
Java HotSpot(TM) Client VM (build 1.5.0_10-eval-b02, mixed mode)
Evaluation version, 90 days remain in evaluation period
Only problem I see is that it's an evaluation version but with this version I didn't have to monkey around with -Xmx or -XX:MaxPermPool options whatsoever.