Forum OpenACS Q&A: Re: Server melting down

6: Re: Server melting down (response to 1)

Posted by C. R. Oldham on 09/16/03 11:52 PM

Heh,

We just put our new annual report online for our members to fill out. On a dual 800 MHz Xeon (AOLserver 3.5.6) with 2 GB of RAM, Linux kernel 2.4.22 we have

ns_param MaxThreads 40        ;# Maximum threads
ns_param MinThreads 40        ;# Start this many on server start
ns_param ThreadTimeout 60     ;# Shut down a thread if idle after 60 seconds
ns_param MaxConnections 100   ;# Queue and service this many conns.
	                      ;# If over this many conns, send 503 Server Busy
ns_param MaxDropped 0         ;# Disable auto shutdown of server in case of
                              ;# too many Server Too Busy messages.

And each of the main/log/subquery database pools have 55 connections configured. I did it that way because I didn't want a thread to wait on a connection if by some chance all the threads hit the DB at the same time.

Our nsd RSS sizes are hovering around 719 MB and have been as high as 1.1 GB. That doesn't seem normal to me, but things are running OK, so I'm not (yet) worried.

We are seeing OK performance. I think it should be better but I'm having a hard time telling if the database or the webserver is the bottleneck. Suggestions for determining that will be appreciated.

7: Re: Server melting down (response to 6)

Posted by Patrick Giagnocavo on 09/17/03 12:10 AM

C.R. , that seems tremendously high.

I would not be surprised to find performance increases if you dropped the threads to 20 and the db pools to say 15 apiece.

You could try using the nstelemetry.adp and loading the page a few times when the server is busy to see how many threads are actually busy.

My guess: unless you are serving more than 5000 visitors per day the lower counts I recommend will be more than adequate. A better number for RAM usage would be under 200; one client serves 50GBytes + per month of db-intensive pages and stays at about 100-115MB for the nsd8x process size.

You should probably bump up the amount of shared memory that Postgres uses and the buffers settings, etc. should also be increased.