Re: Slow copy with little CPU/disk usage

От: Mischa Sandberg
Тема: Re: Slow copy with little CPU/disk usage
Дата: ,
Msg-id: 1113971840.4265dc810374c@webmail.telus.net
(см: обсуждение, исходный текст)
Ответ на: Re: Slow copy with little CPU/disk usage  (Tom Lane)
Ответы: Re: Slow copy with little CPU/disk usage  ("Jim C. Nasby")
Список: pgsql-performance

Скрыть дерево обсуждения

Slow copy with little CPU/disk usage  ("Jim C. Nasby", )
 Re: Slow copy with little CPU/disk usage  (Tom Lane, )
  Re: Slow copy with little CPU/disk usage  (Mischa Sandberg, )
   Re: Slow copy with little CPU/disk usage  ("Jim C. Nasby", )
 Re: Slow copy with little CPU/disk usage  (Greg Stark, )
  Re: Slow copy with little CPU/disk usage  ("Jim C. Nasby", )

Quoting Tom Lane <>:

> "Jim C. Nasby" <> writes:
> > A friend of mine has an application where he's copying in 4000 rows at a
> > time into a table that has about 4M rows. Each row is 40-50 bytes. This
> > is taking 25 seconds on a dual PIII-1GHz with 1G of RAM and a 2 disk
> > SATA mirror, running FBSD 4.10-stable. There's one index on the table.
>
> If there's no hidden costs such as foreign key checks, that does seem
> pretty dang slow.
>
> > What's really odd is that neither the CPU or the disk are being
> > hammered. The box appears to be pretty idle; the postgresql proces is
> > using 4-5% CPU.
--
This sounds EXACTLY like my problem, if you make the box to a Xeon 2.4GHz, 2GB
RAM ... with two SCSI drives (xlog and base); loading 10K rows of about 200
bytes each; takes about 20 secs at the best, and much longer at the worst. By
any chance does your friend have several client machines/processes trying to
mass-load rows at the same time? Or at least some other processes updating
that table in a bulkish way? What I get is low diskio, low cpu, even low
context-switches ... and I'm betting he should take a look at pg_locks. For my
own problem, I gather that an exclusive lock is necessary while updating
indexes and heap, and the multiple processes doing the update can make that
pathological.

Anyway, have your friend check pg_locks.


"Dreams come true, not free." -- S.Sondheim, ITW



В списке pgsql-performance по дате сообщения:

От: Dawid Kuroczko
Дата:
Сообщение: Re: How to improve db performance with $7K?
От: Richard van den Berg
Дата:
Сообщение: When are index scans used over seq scans?