Thread: Dual-CPU slower then Single under HP?
Morning all ...
Have a client that is running an HP server, specs as follows:
> HP-UX 11.00 HP 9000 L-200, Dual CPU (400MHz - 64 bit),
> OS Disk: 9GB U2W-LVD SCSI, 10K rpm
They are trying to determine whether or not it will be able to
handle their environment, and we're trying to help them from the PgSQL
side of things ...
They've got one of the HP developers working side-by-side with
them, looking at the hardware itself, and they've found:
" Running two concurrent Psql/Postgres processes made things worse. They
are blocking each other on semaphores. Elapsed time went from 4m:30s to
6m:15s (100K inserts)."
The 4m:30s is running one process for 100K inserts ... with two
CPUs/processes, it increases the time to process by almost 40% ... ?
Does this make sense?
Looking at disk IO during the inserts, its pretty much dead ...
other then the occasional 'burst' to disk, the disks are quiet, so its all
getting tied up in CPU ...
Thoughts? Suggestions? Other things to investigate that I'm not
thinking of?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> The 4m:30s is running one process for 100K inserts ... with two
> CPUs/processes, it increases the time to process by almost 40% ... ?
Do you mean two processes inserting into the same table?
I committed some changes recently that reduce the amount of contention
involved in that scenario, but it's not released yet.
Another fairly likely issue is the not-very-good implementation of
spinlocks. We've talked about finding a way other than select() to
block on a spinlock, but no one's done anything about it yet...
regards, tom lane
On Wed, 6 Jun 2001, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > The 4m:30s is running one process for 100K inserts ... with two > > CPUs/processes, it increases the time to process by almost 40% ... ? > > Do you mean two processes inserting into the same table? Yup ... > I committed some changes recently that reduce the amount of contention > involved in that scenario, but it's not released yet. So, this is one of those "known problem, improved in v7.2" sort of issues?
Great, thanks :)
On Wed, 6 Jun 2001, Tom Lane wrote:
> The Hermit Hacker <scrappy@hub.org> writes:
> > So, this is one of those "known problem, improved in v7.2" sort of issues?
>
> Yup.
>
> regards, tom lane
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> So, this is one of those "known problem, improved in v7.2" sort of issues?
Yup.
regards, tom lane