Re: [HACKERS] Re: [PHP3] BIG, BIG problems with pg_pConnect in PHP3, PostgreSQL and Apache httpd
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] Re: [PHP3] BIG, BIG problems with pg_pConnect in PHP3, PostgreSQL and Apache httpd |
| Дата | |
| Msg-id | 11618.893522801@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [PHP3] BIG, BIG problems with pg_pConnect in PHP3, PostgreSQL and Apache httpd (Constantin Teodorescu <teo@flex.ro>) |
| Список | pgsql-hackers |
> Zeev Suraski wrote:
>> 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.
Well, not really. On most versions of Unix, free() will never give
acquired memory back to the OS, so a process's data space never shrinks.
Therefore, each backend process will own an amount of memory
corresponding to the largest/most complex query it has processed to date.
An idle backend won't necessarily have a minimal amount of data space.
Of course, if the process is idle then its data space is likely to get
swapped out. So you're right that the amount of real memory it is
using might be little or none.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера