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.
Related
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 was trying to run cassandra thru command line
{C:\Program Files (x86)\apache-cassandra-3.11.11\bin>cassandra}
WARNING! Powershell script execution unavailable.
Please use 'powershell Set-ExecutionPolicy Unrestricted'
on this user-account to run cassandra with fully featured
functionality on this platform.
Starting with legacy startup options
Starting Cassandra Server
Error occurred during initialization of VM
Could not reserve enough space for 2097152KB object heap
RAM - 16 GB
Due to above problem, I have tried running java with runtime paramter -Xms3G, still cassandra is not running.
Request some help, how to solve this issue? Let me know if any other details required.
Heap size
This error indicates that you don't have enough free memory on your machine:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Shutdown other apps you don't need to free up some memory then try to start Cassandra with a more conservative allocation of 1GB for max heap size and 400MB for NewGen by uncommenting the following lines in the "Heap Settings" section of conf/jvm.options:
-Xms1G
-Xmx1G
-Xmn400M
Powershell permissions
You need to grant Powershell permissions to the Windows account running the Cassandra script.
You can grant permissions to all Windows accounts on your machine with:
C:\> powershell Set-ExecutionPolicy Unrestricted
WARNING: You need to run the command prompt as an administrator for the command above to work.
As an alternative, you can grant unrestricted access just for your current user with:
C:\> powershell Set-ExecutionPolicy -Scope CurrentUser Unrestricted
Windows support
I wanted to let you know that there is very limited Windows support in Cassandra 3.11 and there are several known issues that will not be fixed due to limitations in the operating system.
Furthermore, Windows support has been completely dropped in Cassandra 4.0 due to lack of maintainers and testing (CASSANDRA-16171).
As a workaround, we recommend the following:
Deploy Cassandra in Docker
Deploy Cassandra in a VM using software like VirtualBox
Deploy K8ssandra.io
If you just want to build apps with Cassandra as a backend, Astra DB has a free tier that lets you launch a Cassandra cluster in a few clicks with no credit card required. Cheers!
I am trying to make a Minecraft mod. I have set the gradle.properties to use 3GB of ram. If I do this it is able to load the daemon process however it immediately displays
Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/2.14/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
Error occurred during initialization of VM
Could not reserve enough space for 3072000KB object heap
It is running out of RAM, and I have no idea why as I have 16GB installed.
I tried closing all other programs but got the same problem. Next up I changed the gradle.properties to use 1GB and then 2GB of RAM, and instead just got an error saying it ran out of memory (I googled this error and the common solution was to give it some more RAM)
* What went wrong: Execution failed for task ':decompileMc'. > Process 'command 'C:\Program Files (x86)\Java\jdk1.8.0_211\bin\java.exe'' finished with non-zero exit value 1
Francisco Mateo recommended I update my gradle version - sadly didn't help.
I tried changing the distributionUrl in the gradle-wrapper.properties to the new version of gradle I am using so it now reads distributionUrl=https\://services.gradle.org/distributions/gradle-5.5.1-bin.zip
I also tried running InteliJ as administrator. Still no luck.
Not a clue what is happening here - help appreciated. If it makes any difference the error occures at 10:08 of https://www.youtube.com/watch?v=RZ66HdNkank
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.
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.