I'm trying to setup / clone an existing grails-project. I managed to install it fine on several windows/macos computers and also 3-4 servers running Ubuntu (ranging from 16.04 to 20.04). But the newest vServer I rented seems to have some problems regarding the gradle-build, as it always throws an OutOfMemoryException, no matter what I try to do.
I already tried increasing the maximum memory size, that grails / gradle are allowed to use but I still get the OutOfMemoryException. I managed to narrow it all down to gradle, which seems to have a problem with the vServer, which has no swap-memory - that's what I read out of everything gradle told me in the error-log:
There is insufficient memory for the Java Runtime Environment to continue.
Cannot create GC thread.
Out of system resources.
Possible reasons:
- The system is out of physical RAM or swap space
Other than that, i noticed, that gradle uses around one to 1,5GB of memory before crashing - but I assigned him with up to 6GB using -Xmx6G (note that the system has 8GB availaible)
Maybe someone here can help me and tell me what I can do to solve this / get grails up and running (I tried everything I could find).
Attached I have the stacktrace of the (failed) build: https://pastebin.com/Kv2c4gu0
Thanks in advance.
EDIT:
The server has 8GB of memory; 4 cores;
I installed Java 1.8.0_252 through the openjdk 8
Gradle should be the version 4.4.1
Grails is installed with the version 4.0.1
The problem has been resolved:
The vServer had 0b of swap-storage, which led to gradle/grails throwing an error of insufficient memory.
All I needed to do was create a swap-partition to have gradle compile.
Related
When I open intellij IDE with my spring boot app, I can see too much cpu and memory usage of my system. Facing this problem from last 1-1.5 month. Earlier, it was running smoothly.
I am using the latest intellij version in ubuntu 18.04 LTS.
I have increased intellij heap size to 6144. But still get hung after running the app for some time.
Below is the resource consumption stats:
I have recently started Flutter development and on my machine, and the gradle build seemingly takes forever when completely restarting the app or running it for the first time, at times it gets quite frustrating. I am using an Ubuntu 20.04 (KDE Plasma env) with 8 GB RAM/ 240 GB SSD and using VS Code for running the app. Is there any way to optimize this? Would appreciate any suggestion on the same. Thanks in advance.
According to this documentation by developer.android.com there is a way to optimize gradle build by using JVM Garbage collector.
Add this parameter to your gradle.properties in your android folder you can find it on /{your-project}/android/:
org.gradle.jvmargs=-XX:+UseParallelGC
and if there are already value set in this field, just add a new option:
org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC
I'm using Grails 2.0. I used to develop under Grails 1.3.7 but when running an application under Grails 2.0 the performance is very slow. A page can take more than 30 seconds to show and it's very embarrassing and unproductive.
I googled and I found that GSPs in 2.0 are in some cases 10 times slower than 1.3.7 ;
Greame explained that there is a new way of handling GSPs in dev mod, but when executing grails prod run-app I have almost the same problem.
What should I do to speed up development process ? I'm loosing too much time.
PS : My GRAILS_OPTS are "-server -Xmx600M -Xms600M -XX:MaxPermSize=250m -Dfile.encoding=UTF-8 -Dserver.port=9090"
I posted an small announcement on the mailing list about 20 minutes ago:
http://grails.1312388.n4.nabble.com/GSP-Compilation-tt4632864.html#a4635595
This issue was fixed:
http://jira.grails.org/browse/GRAILS-9423
Please test the performance of the latest 2.1.x snapshot build.
Try these
export GRAILS_OPTS="-server -noverify -XX:PermSize=256m
-XX:MaxPermSize=256m -Xmx600M -Xms600m -XX:+UseParallelGC -Djava.net.preferIPv4Stack=true
-Dsun.reflect.inflationThreshold=100000"
For me, the trick was to set Xmx and Xms to the same value and set the PermSize and MaxPermSize to the same value. sun.reflect.inflationThreshold helps with the permgen. (http://jira.grails.org/browse/GRAILS-7878?focusedCommentId=66447&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66447 in the Grails jira for the explanation)
btw. I filed this issue 10 mins ago:
http://jira.grails.org/browse/GRAILS-9444
If it's interesting, please vote on the issue.
Grails 2.x is slower than 1.3.x for development mode because of the reloading improvements. It uses Spring-Loaded reloading agent that is similar to JRebel.
Make sure that your development laptop has enough memory (>4GB), a SSD and a fast i7 CPU.
Get a recent laptop with 16GB memory & a fast SSD and you won't be thinking of slowness anymore. I'd also recommend a i7 series CPU. That costs only about $1200 currently.
To make sure you are using the latest fixes to the Spring-Loaded reloading agent, use Grails 2.1.x instead of Grails 2.0.x . For Grails 2.1.1 you might want to upgrade the Spring-Loaded reloading agent to a snapshot version.
You can get the latest snapshot from:
https://repo.springsource.org/snapshot/com/springsource/springloaded/springloaded-core/
Currently it's https://repo.springsource.org/snapshot/com/springsource/springloaded/springloaded-core/1.1.1.BUILD-SNAPSHOT/springloaded-core-1.1.1.BUILD-20120821.173635-2.jar .
Replace $GRAILS_HOME/lib/com.springsource.springloaded/springloaded-core/jars/springloaded-core-1.0.6.jar with the downloaded snapshot (rename the snapshot to the same file name springloaded-core-1.0.6.jar).
This answer will be outdated as soon as springloaded-core version 1.1.1 gets released.
I recently got a new Macbook Pro at work and noticed that building our codebase in Maven2 takes about 15 minutes while others on my team with slightly older Macbooks (but similar/same specs) build in about 5 minutes. After asking around, I've found one other person on my team whose builds take 15+ minutes. I'm talking about a fresh checkout of the code, with all of us on the same version of Maven (2.2.1) and Java version: 1.6.0_29, running 'mvn clean install' from the root of the project. Both of us with slow builds are on Lion (10.7.3), while the people with 5 minute builds are on Lion or Snow Leopard. My machine has 8GB RAM with 2.3 GHz i7, so it doesn't seem like that should be a problem. AFAIK, the machine came with Lion (versus upgraded from Snow Leopard) so I don't think it's that it was upgraded in place from Snow Leopard which it seems some people have had issues with. We with the slow builds both have 5400 RPM drives while most of the others have 7200 RPM drives, but alas, one of the other guys with the 5 minute builds has the exact same 5400 RPM drive as us ... so that sort of rules out that theory.
I've run a memory test (checked out fine), run disk verify and permissions repair in Disk Utility (fixed some permission issues, but didn't change build times), disabled swapping, made sure filevault was off, build from a different directory, all to no avail. A few interesting points which makes me suspect an OS issue:
I have a Ubuntu VM on said machine, and doing a 'mvn clean install' in there is even considerably faster than natively in OSX (10 minutes versus 15 minutes)! FYI, the native Ubuntu guys on our team also build around 5 minutes. And when I was running Ubuntu in a VM on my Windows box a few months ago, builds averaged 15-20 minutes.
Building the slowest component of our project by itself takes about 3-4 minutes normally. The interesting thing about this component is that there is very little code in it. In fact, all it is is one test case and 135 MB of resource files. Of the 3-4 minutes, I counted about 100+ seconds of it is sitting on "Copying 63 resources".
Running in OSX Safe Mode, building the aforementioned slowest component took only 42 seconds, of which about 7 seconds were spent on copying the 63 resources.
I'm not sure what else to try at this point, but I feel I'm so close to nailing it down. If it wasn't such a marked difference, I wouldn't worry about it so much, but 15 mins versus 5 mins is huge in my workflow. I don't feel real comfortable about giving my work computer to the Apple Genius guys, and our IT guy's not a Mac person. Reinstalling the OS seems to be the answer I've seen online, but that seems a bit excessive and intrusive. (I realize this is more of an OSX question than a Maven question, probably, but Maven's been my benchmark. I don't notice any other slowness, but it's hard to say without using others' computers)
Has anyone encountered something like this? Any ideas on what to try? Thanks
Run mvn -X ... command on your machine and on fast one and compare times from the log files what tasks/plugins take the most time. That should give you a starting point. The two slowest parts are file system scanning and network access for checking artifacts/dependencies/plugin updates.
The former can be improved by tuning disk access (e.g. cache or switching to the SSD).
The latter can be improved by adding Maven repository manager, such as Nexus or Artifactory that would cache and optimize access to all remote Maven repositories.
I am trying to setup YouTrack and TeamCity on a VM with less than 1GB running on Windows. There will be a very low usage (both users and requests). This is a POC environment, if it works I may push it onto an extra-small or small Azure or Amazon VM instance.
Anyone has got this to work?
PS: I understand that this is way below JetBrains recommended settings.
I have a running YouTrack instance with only 256MB RAM allocated (never tried a smaller value), on an old server with only 1GB RAM, under Debian. It feels pretty responsive, but I'm the only user so far :D
If you're using Windows XP, it might work ok, if Team City would run with only 256MB RAM.
Is there a specific need for using TeamCity, or you need it only for integrating YouTrack with Git/Mercurial/SVN?
I tried installing WARs under TomCat and I could not get TeamCity to play nice in TomCat 7. I ended up using the out of the box installers provided by JetBrains and all worked fine.
I have resolved same problem in the next way:
Installed application on VM with more than 1 GB memory.
Configured my application.
Reduced size(memory) of the VM to 700 Mb available
As application was used JetBrains YouTrack 6.0 with 250 issues and 3 users. It was failing to install from msi package on VM with 700 Mb of memory. After processing mentioned steps it works fine.