Monit doesn’t really solve the problem though. I’ve also heard
mod_rails isn’t ready for primetime yet.
I’d like to know what is causing it to eat up memory and CPU usage so
badly…as it ran fine for the last few weeks up until the last few
releases.
I’ve read that it could be anything from a bad regex to low disk
space, gdb debugging rails didn’t give me much that a simpleton like
myself could understand:
1.8.5? Wow. That’s pretty old. I wouldn’t think that that would be the
problem, but it certainly couldn’t hurt to upgrade to something a bit
more recent. Unless you’re using rails 2.1 exclusively I’d suggest
1.8.6 p287 and see if that resolves your problem.
On Sun, Oct 12, 2008 at 8:50 PM, Anthony E. [email protected]
wrote:
Hi Alex,
My ISP only has 1.8.5 and Rails 2.1.
I think there is a logic error somewhere in my code, prior to about a
week ago, the site was functioning fine.
If someone has any ideas on how to debug the 99% CPU usage, I’d be
interested in hearing.
Anthony,
Are you seeing similar results when running in development? Has much
changed in the application (code or visitor-wise) in the last week or
so that could be triggering this behavior?
You might consider looking at the performance tools from New Relic or
Five Runs, which can assist you in determining where some of the
bottlenecks in your code might be lingering.
Good luck!
Robby
–
Robby R.
Chief Evangelist, Partner
PLANET ARGON, LLC
design // development // hosting
What can I do to bring this back inline with an acceptable value?
After switching hosting providers (as this was the default response I
got from many), the prod app still had the same issue and stopped
serving. Thanks to a couple of people on #rubyonrails channel, we
narrowed it down to a bad circular reference in the :include => […]
method I was using for the sortable_column_headers plugin.
Here’s the change I made, and the app loaded fine after that:
You may be able to ascertain this by tailing the production.log and
then cutting and pasting the SQL query into the mysql monitor
manually, with the words “EXPLAIN ” infront of it.
This could help explain where indexes could be useful, although that
helped it was not my problem.
My next task is to learn how to debug and profile my rails app and how
to copy production data in a test database so these issues surface as
soon as the code is written. For my case, the test database only had a
few rows, so the exponential growth in the query time was able to pass
through with only 5 data sets…on production it was 89 and tail spun
into a memory/cpu hog.
Are you seeing similar results when running in development? Has much
changed in the application (code or visitor-wise) in the last week or
so that could be triggering this behavior?
You might consider looking at the performance tools from New Relic or
Five Runs, which can assist you in determining where some of the
bottlenecks in your code might be lingering.
Good luck!
Its very odd, I have test.example.com (test) and example.com (prod) on
the same server, and the code has been deployed to both. However every
time I start the prod mongrel_rails server, each request hangs and
eats up CPU at 95% and takes 10 seconds for a request to complete.
test.example.com does not have this problem, it serves the pages in
under a second.
I originally thought it may be the DB, so I made prod (example.com)
use the test environment, and the issue continues.
I don’t know what else it could be, as they are seemingly identical
when both are running as “test” environment.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.