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
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
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
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
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
Gnanakumar gna...@zoniac.com 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
