On 1/7/16, 10:19 AM, "Tom Lane" wrote:
>Scott Rankin writes:
>> Any other ideas?
>
>If there's no lock waits, and the tables are static, it's difficult to
>arrive at any other conclusion but that the process is simply losing the
>CPU for long inte
On 1/6/16, 11:14 PM, "Jim Nasby" wrote:
>On 1/6/16 12:01 PM, Scott Rankin wrote:
>> I guess we’re back to lock contention?
>
>Is there by chance an anti-wraparound vacuum happening on that table?
>
>Actually, for that matter... if autovacuum is hitting that table
>
>So what seems more likely after more thought is that the pages are staying
>in our shared buffer arena just fine, but the kernel is randomly choosing
>to swap out parts of the arena, and the delays correspond to swap-in
>waits. (There would still have to be a mighty crummy disk subsystem
>under
>
>Hm, well, given that you are able to capture instances of the behavior
>in EXPLAIN ANALYZE, I'd suggest trying EXPLAIN (ANALYZE,BUFFERS).
>That will tell you the number of pages it found in shared buffers vs.
>having to read them. Now, a "read" just means we had to ask the kernel,
>not necessar
On 1/6/16, 10:38 AM, "Tom Lane" wrote:
>
>A possible theory is that the slow cases represent times when the desired
>page is not in cache, but you'd have to have a seriously overloaded disk
>subsystem for a disk fetch to take hundreds of ms. Unless maybe this is
>running on some cloud service wi
On 1/6/16, 10:19 AM, "Tom Lane" wrote:
>Scott Rankin writes:
>> I’m trying to track down why some queries on my database system are
>> intermittently much slower than usual. I have some queries that run, on
>> average, 2-3ms, and they run at a rat
Hi all,
I’m trying to track down why some queries on my database system are
intermittently much slower than usual. I have some queries that run, on
average, 2-3ms, and they run at a rate of about 10-20 queries/second. However,
every 3-5 seconds, one of the queries will be 500-100ms. This is
