> > It likely. First you will ran out kernel file descriptors. This could
> > be solved by increasing the kernel table or lowering
> > max_files_per_process, though. Second the total throughput will
> > rapidly descrease if you don't have enough RAM and many
> > CPUs. PostgreSQL can not handle many concurrent
> > connections/transactions effectively. I recommend to employ some kind
> > of connection pooling software and lower the max connections.
> Don't know if you saw my other message, but increasing max connects to 200
> used about 10% of all my semaphores and about 10% of my file handles.
> That was while running pgbench to create 200 simo sessions.
I'm not talking about semaphores. You see the low usage of file
descriptors is just because pgbench uses very few tables.
> Keep in mind, on my fairly small intranet database server, I routinely
> have >32 connections, most coming from outside my webserver. Probably no
> more than 4 or 5 connects at a time come from there. These are all things
> like Windows boxes with ODBC running access or something similar. Many of
> the connections are idle 98% of the time, and use little or no real
> resources, even getting swapped out should the server need the spare
> memory (it doesn't :-) that machine is set to 120 max simos if I remember
> while 200 may seem high, 32 definitely seems low. So, what IS a good
> compromise? for this and ALL the other settings that should probably be a
> bit higher. I'm guessing sort_mem or 4 or 8 meg hits the knee for most
> folks, and the max fsm settings tom has suggested make sense.
32 is not too low if the kernel file descriptors is not
increased. Beware that running out of the kernel file descriptors is a
serious problem for the entire system, not only for PostgreSQL.
> What wal_sync method should we make default? Or should we pick one based
> on the OS the user is running?
It's really depending on the OS or kernel version. I saw open_sync is
best for certain version of Linux kernel, while fdatasync is good for
another version of kernel. I'm not sure, but it could be possible that
the file system type might affect the wal_sync choice.
---------------------------(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