Skip site navigation (1) Skip section navigation (2)

Re: Caching of Queries

From: "Jason Coene" <jcoene(at)gotfrag(dot)com>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'Mr Pink'" <mr_pink_is_the_only_pro(at)yahoo(dot)com>,"'Scott Kirkwood'" <scottakirkwood(at)gmail(dot)com>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Caching of Queries
Date: 2004-09-23 17:22:30
Message-ID: 200409231722.i8NHMZaX014707@ms-smtp-02.nyroc.rr.com (view raw or flat)
Thread:
Lists: pgsql-performance
Hi Tom,

Easily recreated with Apache benchmark, "ab -n 30000 -c 3000
http://webserver ".  This runs 1 query per page, everything else is cached
on webserver. 

The lone query:

SELECT 
    id, 
    gameid, 
    forumid, 
    subject 
  FROM threads 
  WHERE nuked = 0 
  ORDER BY nuked DESC, 
    lastpost DESC LIMIT 8

Limit  (cost=0.00..1.99 rows=8 width=39) (actual time=27.865..28.027 rows=8
loops=1)
   ->  Index Scan Backward using threads_ix_nuked_lastpost on threads
(cost=0.0 0..16824.36 rows=67511 width=39) (actual time=27.856..27.989
rows=8 loops=1)
         Filter: (nuked = 0)
 Total runtime: 28.175 ms

I'm not sure how I go about getting the stack traceback you need.  Any info
on this?  Results of "ps" below.  System is dual xeon 2.6, 2gb ram, hardware
raid 10 running FreeBSD 5.2.1.

Jason

last pid: 96094;  load averages:  0.22,  0.35,  0.38
up 19+20:50:37  13:10:45
161 processes: 2 running, 151 sleeping, 8 lock
CPU states: 12.2% user,  0.0% nice, 16.9% system,  1.6% interrupt, 69.4%
idle
Mem: 120M Active, 1544M Inact, 194M Wired, 62M Cache, 112M Buf, 2996K Free
Swap: 4096M Total, 4096M Free

  PID USERNAME PRI NICE   SIZE    RES STATE  C   TIME   WCPU    CPU COMMAND
50557 pgsql     98    0 95276K  4860K select 0  24:00  0.59%  0.59% postgres
95969 pgsql      4    0 96048K 34272K sbwait 0   0:00  2.10%  0.29% postgres
95977 pgsql     -4    0 96048K 29620K semwai 2   0:00  1.40%  0.20% postgres
96017 pgsql      4    0 96048K 34280K sbwait 0   0:00  2.05%  0.20% postgres
95976 pgsql     -4    0 96048K 30564K semwai 3   0:00  1.05%  0.15% postgres
95970 pgsql     -4    0 96048K 24404K semwai 1   0:00  1.05%  0.15% postgres
95972 pgsql     -4    0 96048K 21060K semwai 1   0:00  1.05%  0.15% postgres
96053 pgsql     -4    0 96048K 24140K semwai 3   0:00  1.54%  0.15% postgres
96024 pgsql     -4    0 96048K 22192K semwai 3   0:00  1.54%  0.15% postgres
95985 pgsql     -4    0 96048K 15208K semwai 3   0:00  1.54%  0.15% postgres
96033 pgsql     98    0 95992K  7812K *Giant 2   0:00  1.54%  0.15% postgres
95973 pgsql     -4    0 96048K 30936K semwai 3   0:00  0.70%  0.10% postgres
95966 pgsql      4    0 96048K 34272K sbwait 0   0:00  0.70%  0.10% postgres
95983 pgsql      4    0 96048K 34272K sbwait 2   0:00  1.03%  0.10% postgres
95962 pgsql      4    0 96048K 34268K sbwait 2   0:00  0.70%  0.10% postgres
95968 pgsql     -4    0 96048K 26232K semwai 2   0:00  0.70%  0.10% postgres
95959 pgsql      4    0 96048K 34268K sbwait 2   0:00  0.70%  0.10% postgres

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Thursday, September 23, 2004 1:06 PM
> To: Jason Coene
> Cc: 'Mr Pink'; 'Scott Kirkwood'; pgsql-performance(at)postgresql(dot)org
> Subject: Re: [PERFORM] Caching of Queries
> 
> "Jason Coene" <jcoene(at)gotfrag(dot)com> writes:
> > All of our "postgres" processes end up in the "semwai" state - seemingly
> > waiting on other queries to complete.  If the system isn't taxed in CPU
> or
> > disk, I have a good feeling that this may be the cause.
> 
> Whatever that is, I'll bet lunch that it's got 0 to do with caching
> query plans.  Can you get stack tracebacks from some of the stuck
> processes?  What do they show in "ps"?
> 
> 			regards, tom lane


In response to

Responses

pgsql-performance by date

Next:From: Greg StarkDate: 2004-09-23 17:25:25
Subject: Re: Caching of Queries
Previous:From: jason.servetarDate: 2004-09-23 17:18:14
Subject: Re: Caching of Queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group