Re: Postgresql Performance on an HP DL385 and

>
> >Sounds like there are a few moving parts here, one of which is the ODBC
> >driver.

Yes, I need to use it since my clients use it for their veterinary
application.

>First - using 7.4.x postgres is a big variable - not much experience on
> this
> >list with 7.4.x anymore.

Like the previous, we have to use it since the manufacturer/vendor uses a
4GL language which only supports Postgresql 7.4.x

>What OS versions are on the two machines?

Centos 4.3 x84_64 on both boxes.

>What is the network configuration of each - is a caching DNS server
> >available to each? What are the contents of /etc/resolv.conf?

The database is configured for the local/loopback on 127.0.0.1. This is my
local network. No DNS.

>Have you run "top" on the machines while the benchmark is running? What is
> >the top running process, what is it doing (RSS, swap, I/O wait, etc)?

I am not running top, but here's an average per second for the 20-25min
run from vmstat presented in a high/peak, low and median

Sun box with 4-disc array (4GB RAM. 4 167GB 10K SCSI RAID10 LSI MegaRAID
128MB). This is after 8 runs.

dbserver-dual-opteron-centos,08/08/06,Tuesday,20,swapd,128,128,128
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,free,21596,21050,21327
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,buffers,1171,174,595
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,cache,3514368,3467427,3495081
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,bi,97276,1720,31745
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,bo,9209,832,4674
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,in,25906,23204,24115
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,cs,49849,46035,47617
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,us,12,2,5
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,sy,59,50,53
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,wa,1,0,0
dbserver-dual-opteron-centos,08/08/06,Tuesday,20,id,45,26,38

Average TPS is 75

HP box with 8GB RAM. six disc array RAID10 on SmartArray 642 with 192MB RAM.
After 8 runs, I see:

intown-vetstar-amd64,08/09/06,Tuesday,23,r,0,0,0
intown-vetstar-amd64,08/09/06,Tuesday,23,b,2,0,0
intown-vetstar-amd64,08/09/06,Tuesday,23,swapd,0,0,0
intown-vetstar-amd64,08/09/06,Tuesday,23,free,33760,16501,17931
intown-vetstar-amd64,08/09/06,Tuesday,23,buffers,1578,673,1179
intown-vetstar-amd64,08/09/06,Tuesday,23,cache,7881745,7867700,7876327
intown-vetstar-amd64,08/09/06,Tuesday,23,bi,66536,0,4480
intown-vetstar-amd64,08/09/06,Tuesday,23,bo,5991,2,2806
intown-vetstar-amd64,08/09/06,Tuesday,23,in,1624,260,573
intown-vetstar-amd64,08/09/06,Tuesday,23,cs,2342,17,1464
intown-vetstar-amd64,08/09/06,Tuesday,23,us,31,0,3
intown-vetstar-amd64,08/09/06,Tuesday,23,sy,16,0,1
intown-vetstar-amd64,08/09/06,Tuesday,23,wa,99,6,50
intown-vetstar-amd64,08/09/06,Tuesday,23,id,78,0,42

Average TPS is 31.

>Are any of the disks not healthy? Do you see any I/O errors in dmesg?

I don't know. I do the following message:
"PCI: MSI quirk detected. PCI_BUS_FLAGS_NO_MSI set for subordinate bus"

Otherwise, no disc error messages.

Note that tarring up the database directory and untarring it actually
> changes the block layout of the files on the disk from what the database
> might have done when it was created. When you create a tar archive of the
> files in the DB directory, their contents will be packed in file name
> order
> in the tar archive and unpacked that way as well. By comparison, the
> ordering when the database lays them on disk might have been quite
> different. This doesn't impact the problem you describe as you are
> unpacking the tar file on both machines to start the process (right?).

Yes, I am running this on both machines with the same RPMs of Postgresql and
same conf files.

Also, just for this testing, I am not unmounting, formatting, untaring. I am
doing it once than running the series of tests (usually 10 runs).

Thanks again for your time. If you're in the SF area, I'll owe you lunch and
> beer.

Steve