Re: 8.2.3: Server crashes on Windows using Eclipse/Junit

From: "Trevor Talbot" <quension(at)gmail(dot)com>
To: "Rainer Bauer" <usenet(at)munnin(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 8.2.3: Server crashes on Windows using Eclipse/Junit
Date: 2007-10-23 17:07:14
Message-ID: 90bce5730710231007s7e0fbd53rd912a7c813b4ad6f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 10/23/07, Rainer Bauer <usenet(at)munnin(dot)com> wrote:
> "Trevor Talbot" wrote:

> >It could be that there's a significant difference between XP and 2003
> >in how that's handled though. I do have an XP SP2 machine here with
> >512MB RAM, and I'll try tests on it as soon as I can free up what it's
> >currently occupied with.
>
> Yeah, Win2003 behaves differently accoriding to this source:
> <http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx>
>
> <quote>
> Session paged pool allows session specific paged pool allocations. Windows XP
> uses regular paged pool, since the number of remote desktop connections is
> limited. On the other hand, Windows Server 2003 makes allocations from
> session paged pool instead of regular paged pool if Terminal Services
> (application server mode) is installed.
> </quote>

That's a little different. There's a specific range of kernel VM
space dedicated to session-specific data, so each session references
the same addresses but it can be backed by different physical memory
(same concept as separate processes). The session paged pool area of
that VM space is used to allocate the individual desktop heaps from.

It's saying that under XP, it's mapped to the main kernel paged pool,
while under 2003 TS it's mapped to session-specific memory, to avoid
depleting the main paged pool. (Each Terminal Services connection
creates an entire Session.) It doesn't change how desktop heap is
actually used though, which is the issue we're running into.

The system I'm testing on doesn't have Terminal Services running in
appserver mode.

> After increasing the session heap size in the registry from 512KB to 1024KB
> the no. of connections was roughly doubled. So this might be a solution for
> people running out of Desktop heap.
>
> Alter the value of the following key
> <HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows>
>
> The numeric values following "SharedSection=" control the heap management:
> On WinXP these are the default values: "SharedSection=1024,3072,512"
> Altering this to "SharedSection=1024,3072,1024" will increase the heap for all
> non-interactive window stations to 1024KB.

It's probably safe to do on a typical XP box, but it's unfortunately
not something you want the installer to do, or even suggest as blanket
advice. I also wondered about having postmaster create more desktops
on demand, but that has about the same amount of sanity (i.e. not
much).

I think it boils down to getting postgres to avoid using desktop heap
if at all possible, and if not, advising people to avoid XP for high
concurrency, except for suggesting the above change in specific
circumstances.

I suspect win2000 has the same issue, but I don't have a system to
test. It'd be interesting to know if 2000 Professional behaves any
differently than Server.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Martin Marques 2007-10-23 17:56:02 Re: Bitmap Heap scan 8.1/8.2
Previous Message Trevor Talbot 2007-10-23 16:43:33 Re: 8.2.3: Server crashes on Windows using Eclipse/Junit

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-10-23 17:07:35 Re: Feature Freeze date for 8.4
Previous Message Andrew Dunstan 2007-10-23 16:45:14 Re: Feature Freeze date for 8.4