On Tue, Apr 6, 2010 at 09:42, John R Pierce <pierce@xxxxxxxxxxxx> wrote: > Magnus Hagander wrote: >>> >>> fwiw, on my win7 pro 64bit desktop, that reads... >>> >>> %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows >>> SharedSection=1024,20480,768 >>> Windows=On SubSystemType=Windows ServerDll=basesrv,1 >>> ServerDll=winsrv:UserServerDllInitialization,3 >>> ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 >>> ProfileControl=Off >>> MaxRequestThreads=16 >>> >>> which is larger (768) than the value shown in the KB article [2] (512) >>> >> >> Hmm. I was hoping for orders-of-magniture larger though, that would >> remove the problem completely. This seems to just push it off a little >> bit more (assuming it makes a difference, that should probably be >> tested and not just assumed) >> > > I realized I have access to a win7 Pro 32bit system too, the registery > setting is... > > %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows > SharedSection=1024,12288,512 Windows=On SubSystemType=Windows > ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 > ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 > ProfileControl=Off MaxRequestThreads=16 > > on XP Pro 32bit, its > > > %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows > SharedSection=1024,3072,512 Windows=On SubSystemType=Windows > ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 > ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off > MaxRequestThreads=16 > > > > so the first number is 1MB (1024K) on all three systems. > > the middle number goes from 3MB on XP32 to 12MB on Win7 32, to 20MB on Win7 > 64bit, > > the 3rd value goes from 512k, 512k, 768k > > now, I do wonder. this IS the user32.dll heap. what library that a > service such as postgres invokes is using objects in the user32 (window > manager) heap? > > Microsoft's explanation of these three values is... > > The first SharedSection value (1024) is the shared heap size common to all > desktops. > This includes the global handle table, which holds handles to windows, > menus, icons, > cursors, and so forth, and shared system settings. It is unlikely that you > would ever > need to change this value. > > The second SharedSection value (3072) is the size of the desktop heap for > each > desktop that is associated with the "interactive" window station > /WinSta0/. User objects > like hooks, menus, strings, and windows consume memory in this desktop > heap. > It is unlikely that you would ever need to change this second > SharedSection value. > > The third SharedSection value (512) is the size of the desktop heap for > each > desktop that is associated with a "noninteractive" window station. If this > value > is not present, the size of the desktop heap for noninteractive window > stations > will be same as the size specified for interactive window stations (the > second > SharedSection value). > > Every service process executed under a user account will receive a new > desktop > in a noninteractive window station created by the Service Control Manager > (SCM). > Thus, each service executed under a user account will consume the number > of > kilobytes of desktop heap specified in the third SharedSection value. All > services > executed under the LocalSystem account with *Allow Service to Interact > with > the Desktop*/ not/ selected share the desktop heap of the "Default" > desktop in > the noninteractive service windows station (Service-0x0-3e7$). > > > it goes on to say all 3 of these consume from a 48MB total heap (no idea if > this heap is bigger on 64 bit Windows 7). The 20MB number certainly > implies it must be, since I can create several desktops via remote desktop > connections with fast user switching enabled. that clause about each > service control process using a sepearate heap allocation is a bit scary in > conjunction with that 48MB total limit. this correlates to the SVCHOST > processes, windows runs all the services owned by a given account in the > same SVCHOST process, and uses a seperate SVCHOST for each unique service > account. > > did you confirm that in fact its the 3rd number we care about for the > Postgres service? (certainly seems like it to me) Yes, it is. (It even says so in the FAQ - do we need to make that even clearer?) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
