Well, I've found a reason for the problem, but don't know how to solve it yet. But I suspect it's a Rails bug.
I found this statement over at the mysqlplus_adapter page ( http://github.com/methodmissing/mysqlplus_adapter) : "the mysql ruby gem forces GC every 20 queries, that’s a guaranteed GC cycle every 5th request for a request with a 4 query overhead." Sure enough, if I count the number of queries that run quickly, there are 20 of them. All subsequent queries take 10x as long. I looked at the Mysql gem source code, changed the GC_STORE_RESULT_LIMIT from 20 to 200, and recompiled it. Running my test again, now 200 queries run blazing fast, all others are 10x as slow. So whenever store_result_count > GC_STORE_RESULT_LIMIT, the garbage collector is run. Since it seems to be getting run every time after GC_STORE_RESULT_LIMIT, it seems like the store_result_count is never getting decremented, which means it's never getting freed. The reason I think this is a Rails bug is the fact that if I run the code on Rails 2.1, there isn't a problem. Using Rails 2.3, with the same mysql gem and mysql server, resources are not getting freed, causing constant garbage collection. Has anyone seen this, or know how to fix it? Thanks, Brett On Mon, Nov 30, 2009 at 10:10 PM, BW <[email protected]> wrote: > Fred, > > Thanks for the suggestion. I tried it out, but it didn't help. I pushed > pool up to 150 and wait_timeout to 1, no real change. > > I'm really stuck with this. And the performance is so bad that it's > extremely painful to do any work on the app. Let me know if you have any > other ideas. > > Brett > > > On Mon, Nov 30, 2009 at 2:10 PM, Frederick Cheung < > [email protected]> wrote: > >> >> >> On Nov 30, 3:28 am, BW <[email protected]> wrote: >> > Fred, >> > >> > I'm using the default, the CookieStore. >> > >> >> That's fine. I ran into an issue because of a database store that >> wasn't activerecord store. The issue was that the session store wasn't >> returning connections to the connection pool, so after a few normal >> page loads all of the connections are marked as busy and you start >> having to wait for timeouts before subsequent actions can get a >> database connection. >> >> If this is the problem then reducing wait_timeout or increasing the >> pool size (in database.yml - see >> >> http://rubyclub.com.ua/doc/api-rails-2.2/classes/ActiveRecord/ConnectionAdapters/ConnectionPool.html >> ) >> will delay the onset of the problem (this isn't a fix though - you >> need to find what is leaking connections) >> >> Fred >> >> > On Mon, Nov 30, 2009 at 3:53 AM, Frederick Cheung < >> > >> > >> > >> > [email protected]> wrote: >> > >> > > On Nov 29, 6:58 pm, BW <[email protected]> wrote: >> > > > I'm finally upgrading one of my apps to Rails 2.3.5 from 2.1. One >> thing >> > > > I've noticed is that I'm getting terrible performance with MySQL >> under >> > > Rails >> > > > 2.3. The 2.3 version runs 10x slower than the 2.1 version. Same >> > > database, >> > > > almost the same code, different version of Rails. >> > >> > > what session store are you using ? >> > >> > > Fred >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Talk" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<rubyonrails-talk%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-talk?hl=en. >> >> >> > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
