I'm developing a new site based on Ruby on Rails 3 beta. I knew this might be a bad idea considering it's just beta, but I still thought it might work.
Now though I'm having HUGE problems with Rails consuming huge ammounts of memory.
For my application today it consumes about 10 mb per request and it doesn't seem to release it either. So I thought this might be because of bloat in my application and thus I created a test app just to compare.
For my test app I just generated a model with a scaffold and then created about 20 records on this model.
I then went to the index page and hit refresh and I could immediately see memory taking off! Less than my app but still about 1-3 mb per request.
I'm working in OSX Leopard, with Ruby 1.8.7, Rails 3.0.0.beta and a SQLLite db for development.
Does anyone recognize my problem?
I would really appreciate some help here. :/
Thanks!
Well, you should consider how a production Rails app would be served. For example, the above setting (with regards to caching) is typically enabled for the production environment and you should also compare performance with your app running under Passenger (Apache or Nginx).
I do believe there is an easy means to force Passenger to play nicely in dev mode as well.
There were some memory leakage issues in the Rails 3 betas. Is there a reason you're not on 3.0.6?
Edit: D'oh, just saw the date this was asked.
Related
Recently I upgraded our EC2 instances to c3.large in order to boost more unicorn workers to handle increased traffic to our site. (6xworkers per machine - 2 ec2 instances).
When I did this, I started seeing duplicate records being created! It looks like somehow, that maybe 2 unicorn workers are attempting to process the same request?
In my nginx logs I see ONE [POST] request to a particular rails controller - yet two records are being created in the database. Obviously I'm hitting some kind of race condition issue - but have no idea how to debug this. It doesn't happen all the time, but when it does it's frustrating as well. I also noticed that the two database records are within 5 seconds of each other. (And yes I disable the button when the user clicks the submit button).
Unicorn 4.8.2
Ruby 1.9.3
Rails 3.2.14
Any help would be great! Thanks!
Although it may not fix your problem, upgrade to Ruby 2.0.0. There are some blog mentioning that is a good idea to upgrade to Ruby 2.0.0 if you are using Unicorn.
For example: https://www.digitalocean.com/community/articles/how-to-optimize-unicorn-workers-in-a-ruby-on-rails-app
Specifically:
If you are using Ruby 1.9, you should seriously consider
switching to Ruby 2.0. To understand why, we need to understand a
little bit about forking.
Forking and Copy-on-Write (CoW)
When a child process is forked, it is
the exact same copy as the parent process. However, the actual
physical memory copied need not be made. Since they are exact copies,
both child and parent processes can share the same physical memory.
Only when a write is made-- then we copy the child process into
physical memory.
So how does this relate to Ruby 1.9/2.0 and Unicorn?
Recall the Unicorn uses forking. In theory, the operating system would
be able to take advantage of CoW. Unfortunately, Ruby 1.9 does not
make this possible. More accurately, the garbage collection
implementation of Ruby 1.9 does not make this possible. An extremely
simplified version is this — when the garbage collector of Ruby 1.9
kicks in, a write would have been made, thus rendering CoW useless.
Without going into too much detail, it suffices to say that the
garbage collector of Ruby 2.0 fixes this, and we can now exploit CoW.
Running a pretty sizable rails app, we've recently gotten around to upgrading it to rails 3.
Our stack is ruby-1.9.3p484, rails 3.2.16 and passenger 4.0.23 running on top of apache.
After throwing some traffic at a couple of our machines, we started noticing a few really strange errors coming down.
Things like random methods not being defined on objects that would obviously have them, instance variables being nil inside AR associations, and objects just being randomly replaced with 'false'. Just all around strange behavior.
Inspecting apache's logs gave us another bit of info, namely that as these errors were coming in, more often than not, their respective processes would keel over as well, on random bits of the app.
Sometimes it would be just a ruby node getting passed in as null, other times it would be just some random string overflowing, just random stuff getting mangled about.
None of this happened during testing, so the only 'reliable' way of reproducing this thus far has been to just throw traffic at the respective machines and see when / if they start exhibiting this behavior.
Having gone through all of this, here's a list of things we've ruled out up to now:
passenger's oob garbage collection
rails 3 itself ( apparently we'd been getting these before as well, but they were far enough apart to not set off any alarms )
serialization / shoving things in and out of memcached
libxml - there were some reports about of version 2.5.0 causing memory corruption, upgrading to 2.7.0 didn't really make a difference
turning off prelinking ( this can cause memory corruption, per https://www.ruby-forum.com/topic/205897 )
Returning the GC settings to stock seems to have alleviated the problem, but we don't really have anything conclusive in that regard. It would seem though that more collections result in a lower occurrence rate for the issue.
Any thoughts on what might be causing this or we could use to help us pinpoint the issue?
I've had 1.9.3-p484 segfault at_exit on test runs as well but I haven't looked into it yet. In my case it seems to be triggered by certain dependencies for the test suite.
We've also had problems with another project on Rails 3 that ended up abandoning their port to Rails 3 and sticking with 2.3 ):
Have you tried running the app outside of Apache / Passenger?
We are running 2 rails application on server with 4GB of ram. Both servers use rails 3.2.1 and when run in either development or production mode, the servers eat away ram at incredible speed consuming up-to 1.07GB ram each day. Keeping the server running for just 4 days triggered all memory alarms in monitoring and we had just 98MB ram free.
We tried active-record optimization related to bloating but still no effect. Please help us figure out how can we trace the issue that which of the controller is at fault.
Using mysql database and webrick server.
Thanks!
This is incredibly hard to answer, without looking into the project details itself. Though I am quite sure you won't be using Webrick in your target production build(right?), so check if it behaves the same under Passenger or whatever is your choice.
Also without knowing the details of the project I would suggest looking at features like generating pdfs, csv parsing, etc. Seen a case, where generating pdf files have been eating resources in a similar fashion, leaving like 5mb of not garbage collected memory for each run.
Good luck.
My 3.1.3 rails app takes quite a while to start up, and even running rails console seems to take longer than it reasonably should. For example, with my app it's 50 seconds from rails c to the command prompt. In a test fresh rails app (e.g. from rails new) it's about 5 seconds.
Needless to say, this is really annoying, particularly when trying to run tests, etc.
I've seen the links at https://stackoverflow.com/a/5652640/905282 but they're pretty involved; I was hoping for maybe something that would be at a higher level, like "oh yeah, here's how long each gem is taking up during startup".
Suggestions, or do I just need to dive into the details?
Ruby 1.9.3 fixes a performance problem in 1.9.2 when a large number of files have been loaded with require.
That post describes how the performance of including new files is O(N), getting progressively slower the more files are already loaded. Since Rails loads in a lot of files, it is a serious drag on start-up time.
I'm new to Rails 3.
I use ruby 1.9.2 and Rails 3.0.7 and Windows 7
So, my problem
When I start a server this process last for a minute
When I try to access it from the browser (http://127.0.0.1:3000/demo/index) this page loads very long (from 1 minute and more)
I tried to turn off the antivirus, user faster_require gem... I just have no clue what to do...
Whats is the problem?
When Rails starts up it needs to load the entire stack as well as a good chunk of your application, so this can take some time. It's not abnormal for it to take twenty to thirty seconds to get ready even on a current machine.
Generally this isn't an issue as the framework will do smaller reloads while it is running if in development mode. Anything you change in app/ or config/routes.rb will be detected and adjusted for between requests.
The first page load is always the slowest, but after that you should have a very responsive server. If not, something might be amiss configuration-wise.
Some people suggest using Mogrel instead of webrick. I'd recommend to give it a try.
I had this problem with a non-rails project and Apache. Disabling IPv6 fixed the problem. YMMV.