| From: | Marinos Yannikos <mjy(at)geizhals(dot)at> |
|---|---|
| To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Cc: | pgsql-performance(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: GiST indexes and concurrency (tsearch2) |
| Date: | 2005-02-05 13:01:40 |
| Message-ID: | 4204C3B4.1050209@geizhals.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Oleg Bartunov schrieb:
> Marinos,
>
> what if you construct "apachebench & Co" free script and see if
> the issue still exists. There are could be many issues doesn't
> connected to postgresql and tsearch2.
>
Some more things I tried:
- data directory on ramdisk (tmpfs) - no effect
- database connections either over Unix domain sockets or TCP - no effect
- CLUSTER on gist index - approx. 20% faster queries, but CPU usage
still hovers around 25% (75% idle)
- preemptible kernel - no effect
This is really baffling me, it looks like a kernel issue of some sort
(I'm only guessing though). I found this old posting:
http://archives.postgresql.org/pgsql-general/2001-12/msg00836.php - is
this still applicable? I don't see an unusually high number of context
switches, but the processes seem to be spending some time in
"semtimedop" (even though the TAS assembly macros are definetely being
compiled-in).
If you are interested, I can probably provide an account on one of our
identically configured boxes by Monday afternoon (GMT+1) with the same
database and benchmarking utility.
Regards,
Marinos
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dirk Lutzebaeck | 2005-02-05 17:25:52 | query produces 1 GB temp file |
| Previous Message | Alexandre Leclerc | 2005-02-04 20:08:56 | Re: Flattening a kind of 'dynamic' table |