Re: Process balancing on smp db server/apache web serve
От | Ron Snyder |
---|---|
Тема | Re: Process balancing on smp db server/apache web serve |
Дата | |
Msg-id | F888C30C3021D411B9DA00B0D0209BE803BB99F4@cvo-exchange.cvo.roguewave.com обсуждение исходный текст |
Ответы |
Re: Process balancing on smp db server/apache web server
|
Список | pgsql-general |
What OS are you using that "assigns" a cpu to a process at start up? I believe that all of our multiprocessor machines (Linux, Sun, HP, AIX, IRIX, Dec^Wcompaq^WHP) will run a ready process on whatever cpu is available. -ron > -----Original Message----- > From: Peter Darley [mailto:pdarley@kinesis-cem.com] > Sent: Thursday, May 23, 2002 6:56 AM > To: Pgsql-General > Subject: [GENERAL] Process balancing on smp db server/apache > web server > > > Friends, > I have been thinking about my smp db server and how it > interacts with my > web server. I'm using mod_perl on Apache, which uses > Apache::DBI to connect > to the db server via a private network segment. It occurs to > me that since > the web server is connecting early (on startup), when there > is probably no > load on the db server, the cpu that each backend is assigned > to will be > largely random, or, if there is a large syslogd operation or > something right > at that time, it might even put the majority of backends on the same > processor. > When someone hits the web site it seems to me that > there would be a greater > than 50% chance that any two large queries from the web > server would end up > being run on the same processor. Similarly, if I start a > large processing > script that uses the db, since the web associated backends are already > assigned to a processor, there's a good (~50%?) chance that > any big queries > that come in through the web will be on the loaded cpu. > Does this make sense to anyone? If this is true, are > there any suggestions > about how I can keep my persistent connections from Apache, > while getting > the db server to balance the load more efficiently? > Thanks, > Peter Darley > > > ---------------------------(end of > broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
В списке pgsql-general по дате отправления: