Re: Sudden Query slowdown on our Postgresql Server
От | Sebastian Melchior |
---|---|
Тема | Re: Sudden Query slowdown on our Postgresql Server |
Дата | |
Msg-id | 115C19C9-237C-4885-BEB8-D576CFD0C132@mailz.de обсуждение исходный текст |
Ответ на | Re: Sudden Query slowdown on our Postgresql Server (Yeb Havinga <yebhavinga@gmail.com>) |
Ответы |
Re: Sudden Query slowdown on our Postgresql Server
|
Список | pgsql-performance |
Hi, unfortunately we cannot directly control the TRIM (i am not sure it even occurs) because the SSDs are behind an LSI MegaSAS9260 Controller which does not allow access via smart. Even if some kind of TRIM command is the problem, shouldn'tthe iowait go up in this case? Sebastian On 23.03.2012, at 08:10, Yeb Havinga wrote: > On 2012-03-23 05:53, Sebastian Melchior 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. > > I've seen a ssd completely lock up for a dozen seconds or so after giving it a smartctl command to trim a section of thedisk. I'm not sure if that was the vertex 2 pro disk I was testing or the intel 710, but enough reason for us to not mountfilesystems with -o discard. > > regards, > Yeb > > > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance
В списке pgsql-performance по дате отправления: