On 10/23/07, Harald Armin Massa <haraldarminmassa@xxxxxxxxx> wrote: > > The Desktop Heap appears to be a place for processes belonging to the same > > "desktop" to allocate shared objects such as GUI elements. These are allocated > > in shared space so they can be manipulated by any process running in that > > "desktop". > > Using this knowledge and Daves response, also looking back at "3,2kb > per backend", I stumbled upon that KB entry: > > http://support.microsoft.com/?scid=kb%3Ben-us%3B184802&x=15&y=14 [...] > Postgres is definitely NOT started as LocalSystem account; so using a > "logical not" on Microsofts Words that could indicate the reason why > our service-backends consume that memory? Add to this that MS SQL runs > as LocalSystem; and as much as I know also Oracle. It's not quite what you think. The link Rainer posted upthread does a decent job describing it, although there's still some room for confusion: http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx The hierarchy of containers goes Session, Window Station, Desktop. Everything relevant is under the same Session, so I'll ignore that for now. The console gets a Window Station; this is the interactive one since the user sitting down works with it directly. It normally contains one Desktop of interest (Default), which is what the user actually sees. (It's possible to create multiple desktops as a framework for a "virtual desktop" type of thing, but that's all third-party stuff.) Each service registered with the Service Manager has a specific account it logs in under. For each account, the Service Manager creates a Window Station to contain it, and all services using the same account share the default Desktop inside it. Most services run under one of the 3 canned accounts, which is what that KB article is talking about with the Local System bit. Each Desktop created has a fixed-size chunk of memory allocated to it. Desktops created under the interactive Window Station get the larger chunk of memory (3072KB) since they expect to contain lots of UI stuff. Desktops created under other Window Stations get the smaller chunk of memory (512KB), since they aren't presenting a UI to the user. That fixed-size desktop heap is used to track objects handled by the USER subsystem, which is mostly UI elements like windows and such. Most of the API interaction for those resources go through user32.dll, and apparently its initialization procedure grabs some of that heap space for each process it's loaded into. The PostgreSQL service is set to log in under its own account, so it gets its own Window Station, and a default Desktop inside that. This is a non-interactive Window Station, so the Desktop gets the smaller heap. All postgres.exe processes run in that Desktop and share one 512KB heap. As each process ends up carving out a chunk of that space, it uses up all 512KB and fails to create more backends. ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
