Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-18 Thread Sergey Konoplev
Thank you for the hints. > Why only those modes?  I'd search for locks with granted=false, then see > all the other locks held by the process that's holding the conflicting > lock with granted=true (i.e. the one you're waiting on). Something like this? SELECT granted, pid, virtualxi

Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-17 Thread Alvaro Herrera
Sergey Konoplev escribió: > On Mon, Nov 16, 2009 at 9:56 PM, Alvaro Herrera > wrote: > > Sergey Konoplev escribió: > > > >> I tried to get locks with this queries > > > > Did you try pg_locks? > > > > I tried monitor locks with pgrowlocks. Isn't it better way? If it > isn't what points should I p

Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-17 Thread Sergey Konoplev
On Mon, Nov 16, 2009 at 10:17 PM, Andres Freund wrote: > On Wednesday 11 November 2009 18:50:46 Sergey Konoplev wrote: >> Hello community, >> >> >> Second time after migration 8.3.7 --> 8.4.1 I was caught by this >> problem. Migration was 8 days ago. >> (note, I never seen such situation on 8.3) >

Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-17 Thread Sergey Konoplev
> > Can you show us the non-commented settings from your postgresql.conf? Working postgresql.conf http://pastie.org/702748 > > Can you show us what the vmstat output looks like when everything is > running normally?  It looks like the blocks out are pretty high, but I > don't know how that compar

Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-17 Thread Sergey Konoplev
On Mon, Nov 16, 2009 at 9:56 PM, Alvaro Herrera wrote: > Sergey Konoplev escribió: > >> I tried to get locks with this queries > > Did you try pg_locks? > I tried monitor locks with pgrowlocks. Isn't it better way? If it isn't what points should I pay attention with pg_lock? I've just write the

Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-16 Thread Andres Freund
On Wednesday 11 November 2009 18:50:46 Sergey Konoplev wrote: > Hello community, > > > Second time after migration 8.3.7 --> 8.4.1 I was caught by this > problem. Migration was 8 days ago. > (note, I never seen such situation on 8.3) Is 8.4 configured similarly to 8.3? Andres -- Sent via pgsql

Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-16 Thread Robert Haas
On Mon, Nov 16, 2009 at 1:53 PM, Sergey Konoplev wrote: > On Thu, Nov 12, 2009 at 4:42 AM, Robert Haas wrote: >> On Wed, Nov 11, 2009 at 12:50 PM, Sergey Konoplev wrote: >>> Was this situation mentioned before and is there a solution or >>> workaround? (I didn't find any) If not please give me a

Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-16 Thread Alvaro Herrera
Sergey Konoplev escribió: > I tried to get locks with this queries Did you try pg_locks? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-16 Thread Sergey Konoplev
On Thu, Nov 12, 2009 at 4:42 AM, Robert Haas wrote: > On Wed, Nov 11, 2009 at 12:50 PM, Sergey Konoplev wrote: >> Was this situation mentioned before and is there a solution or >> workaround? (I didn't find any) If not please give me a glue where to >> dig or what information should I provide? >

Re: [HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-11 Thread Robert Haas
On Wed, Nov 11, 2009 at 12:50 PM, Sergey Konoplev wrote: > Was this situation mentioned before and is there a solution or > workaround? (I didn't find any) If not please give me a glue where to > dig or what information should I provide? I think you should use log_min_duration_statement or auto_e

[HACKERS] Unpredictable shark slowdown after migrating to 8.4

2009-11-11 Thread Sergey Konoplev
Hello community, Second time after migration 8.3.7 --> 8.4.1 I was caught by this problem. Migration was 8 days ago. (note, I never seen such situation on 8.3) Environment: PostgreSQL 8.4.1 + patch http://archives.postgresql.org/pgsql-committers/2009-10/msg00056.php CentOS release 5.4 (Final) S