Re: Postmaster using only 4-5% CPU

From: Guillaume Cottenceau
Subject: Re: Postmaster using only 4-5% CPU
Date: ,
Msg-id: 87slpbkgs7.fsf@meuh.mnc.lan
(view: Whole thread, Raw)
In response to: Postmaster using only 4-5% CPU  (Edoardo Serra)
List: pgsql-performance

Tree view

Postmaster using only 4-5% CPU  (Edoardo Serra, )
 Re: Postmaster using only 4-5% CPU  ("Markus Bertheau", )
 Re: Postmaster using only 4-5% CPU  (Guillaume Cottenceau, )
 Re: Postmaster using only 4-5% CPU  (Scott Marlowe, )
  Re: Postmaster using only 4-5% CPU  (Edoardo Serra, )
   Re: Postmaster using only 4-5% CPU  ("Jim C. Nasby", )
    Re: Postmaster using only 4-5% CPU  (Scott Marlowe, )

Edoardo Serra <osdevel 'at' webrainstorm.it> writes:

> Hi all,
>          I'm having a very strange performance problems on a fresh
> install of postgres 8.1.3
> I've just installed it with default option and --enable-thread-safety
> without tweaking config files yet.
>
> The import of a small SQL files into the DB (6 tables with 166.500
> total records, INSERT syntax)
> took me more than 18 minutes as shown below (output of  "time ./psql
> benchmarks < dump.sql")
>
> real 18m33.062s
> user 0m10.386s
> sys 0m7.707s
>
> The server is an
> - Intel(R) Xeon(TM) CPU 3.60GHz - 1MB L2
> - 1 GB RAM
> - 2x HDD SCSI U320 RAID 1 Hardware (HP 6i controller)

I have seen similar very low performance for INSERTs, although
using SCSI 320 disk, controlled by LSI Logic 53C1030 (using
Fusion MPT SCSI Host driver 3.01.18 on Linux 2.6.11). Something
like tens of INSERTs per second into a small table, no more.
"iostat" reports very large figures in the "await" field compared
to other servers using raid1 controllers, that's my best guess,
but I was unable to find why and how to fix (and the vendor has
been very helpless until now). I'm wondering if we don't have an
issue with the driver but have no more clue.

--
Guillaume Cottenceau


pgsql-performance by date:

From: Simon Riggs
Date:
Subject: Re: WAL logging of SELECT ... INTO command
From: Simon Riggs
Date:
Subject: Re: Migration study, step 1: bulk write performance