pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Justin <justin@emproshunts.com>
To: pgsql-performance@postgresql.org
Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
Date: Fri, 14 Mar 2008 03:31:29 -0500
Message-ID: <47DA37E1.6050104@emproshunts.com> (raw)
In-Reply-To: <dcc563d10803132319u19480a4fn16115c415ee57844@mail.gmail.com>
References: <f966c2ee0803052142l6a105678jfe2da92a0d9371@mail.gmail.com>
	<Pine.GSO.4.64.0803060813570.11897@westnet.com>
	<47D00DB2.7040007@emolecules.com>
	<18451.1204824562@sss.pgh.pa.us>
	<47D0AFC1.5070305@emolecules.com>
	<08115901408538@mail.emproshunts.com>
	<47D93A43.6020503@emolecules.com>
	<016301c8854e$851e06e0$3101a8c0@JDell>
	<dcc563d10803132312o1539215fk859bbae03f36e566@mail.gmail.com>
	<47DA1866.3050500@krogh.cc>
	<dcc563d10803132319u19480a4fn16115c415ee57844@mail.gmail.com>


> Is this on a 64 bit or 32 bit machine?  We had the problem with a 32
> bit linux box (not sure what flavor) just a few months ago.  I would
> not create a filesystem on a partition of 2+TB
>   
Yes this machine is 64bit
> You do know that effective_cache_size is the size of the OS level
> cache.  i.e. it won't show up in postgresql's memory usage.  On a
> machine with (I assume) 12 or more gigs or memory, you should have
> your shared_buffers set to a much higher number than 100Meg.  (unless
> you're still running 7.4 but that's another story.)


Sorry for my ignorance of linux, i'm used to windows task manager or 
performance monitor showing all the
memory usage.  I
decided to move to Linux on the new server to get 64bit so still in the 
learning curve with that

I played with shared_buffer and never saw much of an improvement from
100 all the way up to 800 megs  moved the checkpoints from 3 to 30 and
still never saw no movement in the numbers.

i agree with you, those numbers are terrible  i realized after posting i
had the option -C turned on
if i read the option -C correctly it is disconnecting and reconnecting
between transactions. The way read -C option creates the worst case.

The raid controller setting is set to make sure it don't lie on fsync

shared_buffers = 800megs
temp_buffers 204800
work_mem 256MB
fsync_on
wal_syns_method fysnc



C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 10000 -v -h
192.168.1.9 -U postgres empro
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
tps = 1768.940935 (including connections establishing)
tps = 1783.230500 (excluding connections establishing)


C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 10000 -v -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
starting vacuum accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 567.149831 (including connections establishing)
tps = 568.648692 (excluding connections establishing)

--------------now with just Select --------------

C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 10 -t 10000 -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
transaction type: SELECT only
scaling factor: 100
number of clients: 10
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
tps = 16160.310278 (including connections establishing)
tps = 17436.791630 (excluding connections establishing)

C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 40 -t 10000 -h
192.168.1.9 -U
postgres empro
Password:
starting vacuum...end.
transaction type: SELECT only
scaling factor: 100
number of clients: 40
number of transactions per client: 10000
number of transactions actually processed: 400000/400000
tps = 18338.529250 (including connections establishing)
tps = 20031.048125 (excluding connections establishing)







view thread (45+ messages)  latest in thread

Message-ID: <47DA37E1.6050104@emproshunts.com>
Permalink:  ../47DA37E1.6050104@emproshunts.com/
Also on:    postgresql.org/message-id/47DA37E1.6050104@emproshunts.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: justin@emproshunts.com
  Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  In-Reply-To: <47DA37E1.6050104@emproshunts.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox