I deploy my applications in Grails 4.0.3 using an embbebed Tomcat as a micro service. I have noticing recently that the application is being down a lot of times. It looses cotectiom with the database.
So I woull like to know two things. The first one is, what the default Grails memory allocation when deplying an app is. Te second one: could I increase the efault memory alloctaion when deploying my app, I mean, when I tun the comman java -jar (in order to deploy the app)?
Thanks.
Alfredo
Related
I have had a Rails 3 app deployed on Elastic Beanstalk for close to 2 years now. For the most part, I haven't had any issues; however, I recently upgraded to one of their new Ruby configurations (64bit Amazon Linux 2014.09 v1.0.9 running Ruby 2.1 (Passenger Standalone)) and I've been fighting an issue for several days where one of more Ruby processes will consume the CPU - to the point where my site becomes unresponsive. I was using a single m3.medium instance, but I've since moved to a m3.large, which only buys me some time to manually log into the EC2 instance and kill the run away process(es). I would say this happens once or twice a day.
The only thing I had an issue with when moving to the new Ruby config was that I had to add the following to my .ebextensions folder so Nokogiri could install (w/bundle install)...
commands:
build_nokogiri:
command: "bundle config build.nokogiri --use-system-libraries"
I don't think this would cause these hanging processes, but I could be wrong. I also don't want to rule out something unrelated to the Elastic Beanstalk upgrade, but I can't thing of any other significant change that would cause this problem. I realize this isn't a whole lot of information, but has anyone experienced anything similar to this? Anyone have suggestions for tracing these processes to their root cause?
Thanks in advance!
Since you upgraded your beanstalk configuration, I guess you also upgraded Ruby/Rails version. This bumped up all gem versions. The performance issue probably originate from one of these changes (and not the Hardware change).
So this brings us into the domain of RoR performance troubleshooting:
1. Check the beanstalk logs for errors. If you're lucky you'll find a configuration issue this way. give it an hour.
2. Assuming all well there, try to setup the exact same version on your localhost (passenger + ruby 2.1 + gems version). If you're lucky, you will witness the same slowness and be able to debug.
3. If you'd like to shoot straight for production debugging, I suggest you'd install newrelic (or any other application monitoring tool) and then drill into the details of the slowness in their dashboard. I found it extremely useful.
I was able to resolve my run away Ruby process issue by SSHing into my EC2 instance and installing/running gdb. Here's a link - http://isotope11.com/blog/getting-a-ruby-backtrace-from-gnu-debugger with the steps I followed. I did have to sudo yum install gdb before.
gdb uncovered an infinite loop in a section of my code that was looping through days in a date range.
I just got a chance to test-drive a VPS for a week, and decided to try Grails on it. The problem is, that it shuts itself down.
Details:
VPS - 512MB Ram, Ubuntu 12.10 x64 (no particular reason for x64)
Oracle Java 7u17
Latest GVM 0.9.5
Grails 2.2.1
What I did was follow along this tutorial http://grails.org/Quick+Start, which is very basic. Everything went smooth until I did grails run-app.
After doing the initialization, it showed running for like 5s, and I could even start loading the page, but it suddenly showed Killed in the terminal. This is what the terminal showed:
root#jp:/var/grails/my-project# grails run-app
| Running Grails application
Killed
There was no input during that time whatsoever. Any ideas on the cause of this problem?
You should only ever run Grails with the run-app command when developing locally. The reason behind this is because run-app starts your Grails app with a lot of dynamic behavior that is great for rapid development, but horrible performance-wise for running on an actual server.
Refer to Grails' User Guide on how best to deploy your application:
http://grails.org/doc/latest/guide/gettingStarted.html#deployingAnApplication
As the docs above state, the correct way to run your Grails app is to embed it in a servlet container. Tomcat is a good place to start since Grails uses that by default when running locally. You may also need to play around with the VM flags of your servlet container, depending on your environment (again, the docs give a few suggestions here).
You can redirect output of your command if it get's killed immediately on your terminal.
grails run-app > output.txt
Then open output.txt and from there you can dissect the problem.
For my case, i got an incorrect JAVA_HOME directory.
Hope it helps.
I've run 80,000 http calls thru my grails app running on my desktop PC and it did not fail. On cloudfoundry, the same app runs out of memory after about 3000 http calls. The app uses MySql, Mongodb, and RabbitMQ. On Cloudfoundry, I have increased the memory to 1G using the VMC command. While the test program is running, I can watch the memory usage with the VMC stats command and the memory usage grows up to 1G and the app fails. I'm using Grails 2.0.1 on my local machine.
What could be causing this problem?
Could it be related to this: http://burtbeckwith.com/blog/?p=73 ?
You might get some use out of this post as your test app is likely much like a batch application.
You should use jconsole to monitor your application when running locally and set your local memory allocated to java to the same values as cloudfoundry to see if you can reproduce the error. If jconsole shows that you're never letting go of memory, then you likely have a leak and aren't allowing things to get garbage collected.
For Java web apps you need to also set the Xmx:
vmc set-env APP JAVA_OPTS="-Xmx1024M"
Recently I configured my instance into a micro environment in EC2 with glassfish and mysql in windows..
I deployed my war and i was able to access my site through http.
I changed my application and redeployed the war and it also worked.
When I was about to redeploy the war for 4th or 5th time, the application got deployed, I saw the message in the log file. But I was unable to access the site through http.
Then I tried the command "asadmin list-applications" and I got the following message.
Error occurred during initialization of VM
Could not reserve enough space for object heap
After that I was not able to connect to my instance through RDP and I had to reboot, I was able to access it again after that. I started the servers again (glassfish mysql), but no luck.
I noticed that the memory usage is around 90% or more. CPU isage is low.
now I can not access my site through http. what shall i do ?
Thanks in advance !
Honestly, there are a couple issues working against you here:
1) Windows requires FAR more RAM than Ubuntu to run at a minimum decent level.
2) GlassFish has a much larger footprint than Tomcat or Jetty.
Is there any particular reason you need Windows? Like is there a specific need that your server run some executables for file processing or something like that outside the JVM? Most would agree that Linux (Ubuntu or other) will give you much better results in performance and stability to run an App Server like GlassFish in any environment.
I'm currently porting a Rails App currently using REE to JRuby so I can offer an easy-to-install JRuby alternative.
I've bundled the app into a WAR file using Bundler which I'm currently deploying to GlassFish. However, this app has a couple of daemon processes and it would be ideal if these could be part of the WAR file, and potentially monitored by Glassfish (if possible).
I've looked at QuartzScheduler, and while meets my needs for a couple of things, I have a daemon process that must execute every 20 seconds as it's polling the database for any delayed mail to send.
If anyone can provide any insight as to how best to set up daemon processes in a JRuby/Java/Glassfish environment any help will be greatly appreciated! :)
One way to daemonize a JRuby process is to use akuma framework (on *nix) or others.
I would rather use cronjobs (schedulling) rather than daemons as they are less error-proned, daemons can leak memory, can stop on errors etc. Check jruby-quartz and quartz_scheduler
EDIT
If one uses Torquebox it offers support for services and scheduling.