Thread: Multiple postgres.exe On Processes

Multiple postgres.exe On Processes

From
Abdul Rahman
Date:
Dear All,

I have fear that sufficient increase in number of postgres.exe after one or two logins on servers may down the speed of the server or even server. Is there any solution or technique to overcome this overhead.

Regards,
Abdul Rehman.

Re: Multiple postgres.exe On Processes

From
John R Pierce
Date:
Abdul Rahman wrote:
> I have fear that sufficient increase in number of postgres.exe after
> one or two logins on servers may down the speed of the server or even
> server. Is there any solution or technique to overcome this overhead.

each connection runs one process, plus the 3 master processes for the
postmaster, the writer, etc.     with two logins, I'd expect to see 5
processes.   with 102 concurrent logins, 105 processes.  the bulk of the
memory and code is shared by these processes, with the exception of
things like per client work_mem buffers which by definition can't be
shared as they are used to service that connections requests.

what overhead are you talking about?



Re: Multiple postgres.exe On Processes

From
Serge Fonville
Date:
Hi,

I have fear that sufficient increase in number of postgres.exe after one or two logins on servers may down the speed of the server or even server. Is there any solution or technique to overcome this overhead. 

Did you test this?
What OS are you using?

With PostgreSQL every connection gets a process, processes can be reused, so unless you have a very low spec system, that should not be a problem.

PostgreSQL is designed as a client/server architecture, which requires separate processes for each client and server, and various helper processes. Many embedded architectures can support such requirements. However, if your embedded architecture requires the database server to run inside the application process, you cannot use Postgres and should select a lighter-weight database solution.

I could not find the reason as to why this way has been chosen by the developers

Hope this helps

Regards,

Serge Fonville

Re: Multiple postgres.exe On Processes

From
Serge Fonville
Date:
I have fear that sufficient increase in number of postgres.exe after one or two logins on servers may down the speed of the server or even server. Is there any solution or technique to overcome this overhead.

I did some more searching and found

Re: Multiple postgres.exe On Processes

From
Grzegorz Jaśkiewicz
Date:
poor windows users....

Re: Multiple postgres.exe On Processes

From
Harald Armin Massa
Date:
Just adding:

> processes.   with 102 concurrent logins, 105 processes.  the bulk of the
> memory and code is shared by these processes, with the exception of things
> like per client work_mem buffers which by definition can't be shared as they

please be advised that the default-view of TaskManager (XP) does NOT
show this memory as shared, but as "multiple multi megabyte
processes". In other words: the default view of TaskManager gives the
impression that shared memory is used by every process.

Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!

Re: Multiple postgres.exe On Processes

From
Abdul Rahman
Date:
Dear All,

Thanks John R Pierce for replying fruitful text. I wold like to add some text in your reply from PostgreSQL document for further clarification. i.e.

Each connection runs one process, plus the 3 master processes for the postmaster, the writer, etc. with two logins, I'd expect to see 5 processes. with 102 concurrent logins, 105 processes.[From Pierce]

The PostgreSQL server can handle multiple concurrent connections from clients. For that purpose it starts
(“forks”) a new process for each connection. From that point on, the client and the new server process
communicate without intervention by the original postgres process. Thus, the master server process is
always running, waiting for client connections, whereas client and associated server processes come and
go.[From PostgreSQL Document]

Thanks all.

Regards,
Abdul Rehman


Re: Multiple postgres.exe On Processes

From
Scott Marlowe
Date:
On Thu, Feb 12, 2009 at 1:21 AM, Serge Fonville
<serge.fonville@gmail.com> wrote:

> I could not find the reason as to why this way has been chosen by the
> developers

Because separate processes are much more robust than multiple threads.
 And on Linux, the difference in performance is minimal.  Note some
OSes like Windows, and to a lesser extent, Solaris, have significant
overhead for forking processes, and run multi-threaded apps much
faster.

Since any real db in a heavy lifting situation is probably using a
connection pooler, then the cost of startup of a new process isn't a
big deal, because they're not getting started all the time anymore.