Re: [PHP3] BIG, BIG problems with pg_pConnect in PHP3, PostgreSQL and Apache httpd
От | Constantin Teodorescu |
---|---|
Тема | Re: [PHP3] BIG, BIG problems with pg_pConnect in PHP3, PostgreSQL and Apache httpd |
Дата | |
Msg-id | 35417B94.74C3BBD5@flex.ro обсуждение исходный текст |
Ответы |
Re: [HACKERS] Re: [PHP3] BIG, BIG problems with pg_pConnect in PHP3, PostgreSQL and Apache httpd
|
Список | pgsql-hackers |
Zeev Suraski wrote: > > At 17:49 24/04/98 -0500, John Fieber wrote: > >On Fri, 24 Apr 1998, Alex Belits wrote: > > > >> > Also, total memory usage is not simply usage of one invocation > >> > times the number of invocations. With a decent virtual memory > >> > system, all invocations share memory for the text segment which > >> > is over a megabyte for postgres. So, subtract (N-1) x 1MB from > >> > your total. > >> > >> Database servers have large amount of data in their processes, so they > >> still will have to allocate it separately, even though they handle the > >> same database. > > > >Certainly. I was just pointing ou a potential memory use > >miscalculation on the order of 1MB per process (the text size of > >postgres), which is not exactly trivial. > > I might be missing something, but idle processes of an SQL server should > take virtually no memory. The code image is shared, the read-only data is > shared, and the only memory that's not shared is the memory taken for > process specific stuff, mainly memory needed during the processing of a > query. That memory will be freed as soon as the query is done, so it > doesn't really matter. > Again, I don't know if there might be some Postgres specific issues > involved, but I've had a MySQL server with 150 threads taking all around > 5MB (while processing some queries, too). Is there a method of getting under Linux o.s. the *real* ammount of memory that all postgres process use overall ? I would inform you then how much memory will eat those processes and if there is too big, I'll inform also PostgreSQL developers about it. -- Constantin Teodorescu FLEX Consulting Braila, ROMANIA
В списке pgsql-hackers по дате отправления: