We''re seeing these errors intermittently: ### Mysql::Error: Lock wait timeout exceeded; try restarting transaction: UPDATE `chairs` SET `published_at` = NULL, `updated_at` = ''2008-07-30 15:31:05'' WHERE `id` = 2147 [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/ connection_adapters/abstract_adapter.rb:147:in `log'' ### The root issue is probably slowness in the Rails app, which causes some long transactions. We''re trying to find some way to tune around this while the code is refactored; does anyone know a way to optimize mysql for this issue? --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jul 30, 4:42 pm, Aramis Kester <AramisKes...-hRtevi7K+EU+Va1GwOuvDg@public.gmane.org> wrote:> We''re seeing these errors intermittently: > > ### > Mysql::Error: Lock wait timeout exceeded; try restarting transaction: > UPDATE `chairs` SET `published_at` = NULL, `updated_at` = ''2008-07-30 > 15:31:05'' WHERE `id` = 2147 > [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/ > connection_adapters/abstract_adapter.rb:147:in `log'' > ### > > The root issue is probably slowness in the Rails app, which causes > some long transactions. We''re trying to find some way to tune around > this while the code is refactored; does anyone know a way to optimize > mysql for this issue?Well first off make sure that mysql isn''t locking rows it doesn''t need to. Mysql locks index ranges, so if you update something (or do a locking select ) and the indexed used is not very discriminating (or there isn''t an index at all) then you''ll be locking a whole bunch of rows that don''t need to be locked. Fundamentally though, this happens because something you are doing is taking too long. Pretty much the only thing you can do at the mysql (as far as I know) is change the timeout after which mysql throws that error. There is a plugin (http://github.com/rails/deadlock_retry/tree/master) that automatically retries for you. (we''ve used this although sometimes, for reasons we''ve not yet fully investigated, the retries also deadlock more often than you''d expect them to) Fred 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Try to add this line in environment.rb ActiveRecord::Base.verification_timeout = 570 Thanks&Regards, Kiran. On Jul 31, 4:13 pm, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Jul 30, 4:42 pm, Aramis Kester <AramisKes...-hRtevi7K+EU+Va1GwOuvDg@public.gmane.org> wrote: > > > We''re seeing these errors intermittently: > > > ### > > Mysql::Error: Lock wait timeout exceeded; try restarting transaction: > > UPDATE `chairs` SET `published_at` = NULL, `updated_at` = ''2008-07-30 > > 15:31:05'' WHERE `id` = 2147 > > [RAILS_ROOT]/vendor/rails/activerecord/lib/active_record/ > > connection_adapters/abstract_adapter.rb:147:in `log'' > > ### > > > The root issue is probably slowness in the Rails app, which causes > > some long transactions. We''re trying to find some way to tune around > > this while the code is refactored; does anyone know a way to optimize > > mysql for this issue? > > Well first off make sure that mysql isn''t locking rows it doesn''t need > to. Mysql locks index ranges, so if you update something (or do a > locking select ) and the indexed used is not very discriminating (or > there isn''t an index at all) then you''ll be locking a whole bunch of > rows that don''t need to be locked. > Fundamentally though, this happens because something you are doing is > taking too long. Pretty much the only thing you can do at the mysql > (as far as I know) is change the timeout after which mysql throws that > error. > > There is a plugin (http://github.com/rails/deadlock_retry/tree/master) > that automatically retries for you. (we''ve used this although > sometimes, for reasons we''ve not yet fully investigated, the retries > also deadlock more often than you''d expect them to) > > Fred > > 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---