[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-performance
Subject:    Re: [PERFORM] Sudden Query slowdown on our Postgresql Server
From:       Sebastian Melchior <webmaster () mailz ! de>
Date:       2012-03-23 7:52:10
Message-ID: 115C19C9-237C-4885-BEB8-D576CFD0C132 () mailz ! de
[Download RAW message or body]

Hi,

unfortunately we cannot directly control the TRIM (i am not sure it even occurs) \
because the SSDs are behind an LSI MegaSAS 9260 Controller which does not allow \
access via smart. Even if some kind of TRIM command is the problem, shouldn't the \
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 of the 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 the disk. 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 mount \
> filesystems 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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[prev in list] [next in list] [prev in thread] [next in thread]