Re: Oracle news article
От | Steve Wolfe |
---|---|
Тема | Re: Oracle news article |
Дата | |
Msg-id | 002701c0f44d$21c399a0$50824e40@iboats.com обсуждение исходный текст |
Ответ на | Re: Oracle news article (Alex Pilosov <alex@pilosoft.com>) |
Список | pgsql-general |
> > I mean allowing an unlimited amount of connections (as much as the process > > table will allow) that are served in a round-robin basis by oracle, much > > like an httpd process. I'm tired of having to up the number of user > > connections just because we get an unprecedented surge in interest from > > people viewing all of our sites. > How about doing -N 5000? Or a equally-big > your-webserver-will-melt-down-before-the-number-is-achieved. Whether that would be advantageous depends on what happens when the max number of backends is reached. If a new incoming connection simply waits for a new backend to become available, then you can do about the same thing as connection-pooling by simply setting a low number of backends - a number somewhere around the number of CPU's that you have. In theory, you keep each CPU full (assuming there aren't other bottlenecks), but avoid the extra memory usage and context-switching cost associated with a larger number of backends. However, it would block incoming requests, meaning that a few large queries could stop a few hundred small, fast queries from running. That means that the guy generating traffic statistics can keep several hundred people from seeing your site until he's done - a bad thing. : ) Overall, it seems (to me, at least) that if new connections (above the max) simply wait, then a good compromise would be limitting the number of backends to a level several times greater than the number of CPU's that you have, so that a single (or a few) large query doesn't completely monopolize the system, yet not so high that you're going to exhaust your memory or run into other problems associated with huge numbers of running processes. steve
В списке pgsql-general по дате отправления: