Re: [PERFORM] Hardware upgrade for a high-traffic database

2004-08-11 Thread Brian Hirt
On Aug 11, 2004, at 3:18 PM, Jason Coene wrote:
I'm wondering why our PG server is using so little memory...  The 
system has
2GB of memory, though only around 200MB of it are used.  Is there a PG
setting to force more memory usage towards the cache?  Additionally, 
we use
FreeBSD.  I've heard that Linux may manage that memory better, any 
truth
there?  Sorry if I'm grabbing at straws here :)

i don't know about freebsd, but linux is very aggressive about using 
unused memory for disk cache.  we have dedicated linux box running pg 
with 2gb of memory,   about 250mb of memory is being used by processes 
(system+postgres) and shared memory (postgres only), and there is 
1.75gb of disk buffers in use in the kernel.  this particular database 
is only about 4gb, so a good portion of the db resides in memory, 
certainly most of the active set.  the disk subsystem is a 6 disk scsi 
u160 raid array which performs pretty well when there is io.

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match


Re: [PERFORM] my boss want to migrate to ORACLE

2004-07-30 Thread Brian Hirt
pg_autovacuum is a daemon, not something that get's run twice a day.   
I think that's what the question Matthew was getting @.  I'm not sure 
what would happen to performance if pg_autovacuum was launched twice a 
day from cron, but you could end up in an ugly situation if it starts 
up.

--brian
On Jul 30, 2004, at 12:11 PM, Dan Langille wrote:
On Fri, 30 Jul 2004, Matthew T. O'Connor wrote:
Stephane Tessier wrote:
I think with your help guys I'll do it!
I'm working on it!
I'll work on theses issues:
we have space for more ram(we use 2 gigs on possibility of 3 gigs)
iowait is very high 98% -- look like postgresql wait for io access
raid5 --raid0 if i'm right raid5 use 4 writes(parity,data, etc) for 
each
write on disk
use more transactions (we have a lot of insert/update without 
transaction).
cpu look like not running very hard

*php is not running on the same machine
*redhat enterprise 3.0 ES
*the version of postgresql is 7.3.4(using RHDB from redhat)
*pg_autovacuum running at 12 and 24 hour each day

What do you mean by pg_autovacuum running at 12 and 24 hour each 
day?
I suspect he means at 1200 and 2400 each day (i.e noon and midnight).
--
Dan Langille - http://www.langille.org/
---(end of 
broadcast)---
TIP 8: explain analyze is your friend

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly


[PERFORM] hardware raid suggestions

2004-07-15 Thread Brian Hirt
I've  been using the adaptec ZCR raid cards in our servers for a while 
now, mostly small systems with 3 or 6 disks, and we've been very happy 
with them.   However, we're building a new DB machine with 14 U320 15K 
SCA drives, and we've run into a performance bottlenkeck with the ZCR 
card where it just won't scale well.  Without going into too many 
details, we've tested RAID5, RAID10 and RAID50 on pretty much every 
array size from 4-14 disks (raid 50 tests used more drives), using JFS, 
reiserfs and EXT3.  With every different configuration,  performance 
didn't improve after array size became greater than 6 disks..   We used 
various benchmarks, including pgbench with scale factors of 10, 100, 
1000, 5000 and clients of 10, 15, 30 and 45.  We've done many other 
tests and monitoring tools, and we've come to the conclusion that the 
ZCR is the problem.

We're looking into getting an Adaptec 2200S or the Megaraid 320 2x 
which have better processors, and hopefully better performance.  We 
feel that the use of the AIC7930 as the CPU on the ZCR  just doesn't 
cut it and a faster raid controller would work better. Does anyone out 
there have any experience with these cards with postgresql and linux?  
If so, would you be willing to share your experiences and possibly give 
a recommendation?

--brian
---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PERFORM] Inconsistent performance

2003-09-15 Thread Brian Hirt
it seems like the difference is probably related to caching.   you say 
you have 1gb of ram, and the database is 2gb.Obviously the entire 
database isn't cached, but maybe your query runs fast when the table is 
in memory, and they it gets swapped out of cache because some other 
piece of information moves into memory.  In that circumstance, it has 
to load the information from disk and is therefor slow.

how busy is the system?  what other programs are running on the 
machine?  how big (on disk) is the table in question? what kind of load 
does the system have?   is it a single 80gb ide drive?   Even though 
you have 4 CPU's a small amount of memory and bad IO system will kill 
the database.

On Monday, September 15, 2003, at 05:28 PM, Joseph Bove wrote:

Stephan,

I've run explain analyze a number of times and have gotten results 
between 5.5 and 7.5 seconds

Attached is a typical output

 QUERY PLAN
-
 Aggregate  (cost=9993.92..9993.92 rows=1 width=0)
  (actual time=7575.59..7575.59 rows=1 loops=1)
-  Seq Scan on vetapview  (cost=0.00..9771.34 rows=89034 width=0)
   (actual time=0.06..7472.20 
rows=88910 loops=1)
 Total runtime: 7575.67 msec
(3 rows)

The only things changing are the actual time. The costs are constant.

The relpages from pg_class for vetapview (the table in question) is 
8881.

At the end of this message is the exhaustive contents of 
postgresql.conf. The only settings I have attempted tuning are as 
follows:

tcpip_socket = true
max_connections = 100
shared_buffers = 5000
sort_mem = 8192
fsync = false
I did have shared_buffers and sort_mem both set higher originally 
(15000, 32168) but decreased them in case over-utilization of memory 
was the problem.

The kernel setting shmmax is set to 256,000,000 (out of 1 gig)

Regards,

Joseph

postgresql.conf

#
#   Connection Parameters
#
tcpip_socket = true
#ssl = false
max_connections = 100
#superuser_reserved_connections = 2
#port = 5432
#hostname_lookup = false
#show_source_port = false
#unix_socket_directory = ''
#unix_socket_group = ''
#unix_socket_permissions = 0777 # octal
#virtual_host = ''

#krb_server_keyfile = ''

#
#   Shared Memory Size
#
#shared_buffers = 15000 # min max_connections*2 or 16, 8KB each
shared_buffers = 5000
#max_fsm_relations = 1000   # min 10, fsm is free space map, ~40 
bytes
#max_fsm_pages = 1  # min 1000, fsm is free space map, ~6 
bytes
#max_locks_per_transaction = 64 # min 10
#wal_buffers = 8# min 4, typically 8KB each

#
#   Non-shared Memory Sizes
#
#sort_mem = 32168   # min 64, size in KB
sort_mem = 8192
#vacuum_mem = 8192  # min 1024, size in KB
#
#   Write-ahead log (WAL)
#
#checkpoint_segments = 3# in logfile segments, min 1, 16MB each
#checkpoint_timeout = 300   # range 30-3600, in seconds
#
#commit_delay = 0   # range 0-10, in microseconds
#commit_siblings = 5# range 1-1000
#
fsync = false
#wal_sync_method = fsync# the default varies across platforms:
#   # fsync, fdatasync, open_sync, or 
open_datasync
#wal_debug = 0  # range 0-16

#
#   Optimizer Parameters
#
#enable_seqscan = true
#enable_indexscan = true
#enable_tidscan = true
#enable_sort = true#enable_tidscan = true
#enable_sort = true
#enable_nestloop = true
#enable_mergejoin = true
#enable_hashjoin = true
#effective_cache_size = 1000# typically 8KB each
#random_page_cost = 4   # units are one sequential page fetch 
cost
#cpu_tuple_cost = 0.01  # (same)
#cpu_index_tuple_cost = 0.001   # (same)
#cpu_operator_cost = 0.0025 # (same)

#default_statistics_target = 10 # range 1-1000

#
#   GEQO Optimizer Parameters
#
#geqo = true
#geqo_selection_bias = 2.0  # range 1.5-2.0
#geqo_threshold = 11
#geqo_pool_size = 0 # default based on tables in statement,
# range 128-1024
#geqo_effort = 1
#geqo_generations = 0#geqo_random_seed = -1  # auto-compute 
seed

#
#   Message display
#
#server_min_messages = notice   # Values, in order of decreasing 
detail:
#   debug5, debug4, debug3, debug2, 
debug1,
#   info, notice, warning, error, log, 
fatal,
#   panic
#client_min_messages = notice   # Values, in order of decreasing 
detail:
#   debug5, debug4, debug3, debug2, 
debug1,
#   log, info, notice, warning, error
#silent_mode = false

#log_connections = false
#log_pid = false
#log_statement = false
#log_duration = false
#log_timestamp = false
#log_min_error_statement = error # Values in order of increasing 
severity:

#log_min_error_statement = error # Values in order of increasing 
severity:
 #   debug5, debug4, debug3,