"Gnanakumar" wrote:
>> When you hit that issue, there is not a continual slowdown --
>> queries which normally run very fast (a small fraction of a
>> second) may periodically all take tens of seconds. Is that the
>> pattern you're seeing?
>
> Yes, you're correct. Queries those normally run
> Are those wrapped in a transaction or not? Each transaction forces a fsync
> when committing, and if each of those INSERT/UPDATE statements stands on
> it's own it may cause of lot of I/O.
Yes, it's wrapped inside a transaction. May be this could be a reason for
slowdown, as you've highlighted
On 23 Březen 2012, 11:10, Gnanakumar wrote:
> First off, thank you *so much* for that detailed explanation comparing
> with
> a real-time application performance benchmark, which was really
> enlightening
> for me.
>
>> How are you handling concurrency? (Are you using FOR SHARE on your
>> SELECT s
First off, thank you *so much* for that detailed explanation comparing with
a real-time application performance benchmark, which was really enlightening
for me.
> How are you handling concurrency? (Are you using FOR SHARE on your
> SELECT statements? Are you explicitly acquiring table locks befo
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.
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 a
