Re: Sudden Query slowdown on our Postgresql Server
От | Scott Marlowe |
---|---|
Тема | Re: Sudden Query slowdown on our Postgresql Server |
Дата | |
Msg-id | CAOR=d=0X0Z1M_X4VMOKnvbr1WS2V02yAqSasrDWng9cr8hhVhw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Sudden Query slowdown on our Postgresql Server (Sebastian Melchior <webmaster@mailz.de>) |
Список | pgsql-performance |
What does vmstat say about things like context switches / interrupts per second? On Thu, Mar 22, 2012 at 10:53 PM, Sebastian Melchior <webmaster@mailz.de> wrote: > Hi, > > we already used iostat and iotop during times of the slowdown, there is no sudden drop in I/O workload in the times ofthe slowdown. Also the iowait does not spike and stays as before. > So i do not think that this is I/O related. As the disks are SSDs there also still is some "head room" left. > > Sebastian > > On 23.03.2012, at 05:48, Scott Marlowe wrote: > >> I'd suggest the handy troubleshooting tools sar, iostat, vmstat and iotop >> >> On Thu, Mar 22, 2012 at 10:37 PM, Sebastian Melchior <webmaster@mailz.de> wrote: >>> Hi, >>> >>> yeah we log those, those times do not match the times of the slowdown at all. Seems to be unrelated. >>> >>> Sebastian >>> >>> >>> On 23.03.2012, at 01:47, Stephen Frost wrote: >>> >>>> * Sebastian Melchior (webmaster@mailz.de) wrote: >>>>> Does anyone have any idea what could cause this issue or how we can further debug it? >>>> >>>> Are you logging checkpoints? If not, you should, if so, then see if >>>> they correllate to the time of the slowdown..? >>>> >>>> Thanks, >>>> >>>> Stephen >>> >>> >>> -- >>> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) >>> To make changes to your subscription: >>> http://www.postgresql.org/mailpref/pgsql-performance >> >> >> >> -- >> To understand recursion, one must first understand recursion. > -- To understand recursion, one must first understand recursion.
В списке pgsql-performance по дате отправления: