On Mon, Oct 22, 2007 at 10:41:14AM +0200, Magnus Hagander wrote: > On Mon, Oct 22, 2007 at 10:23:16AM +0200, Magnus Hagander wrote: > > > >> I tried going up to 20000 max_connections, and still blew postmaster's > > > >> VM space long before paged pool was exhausted. I couldn't test any > > > >> higher values, as there's some interaction between max_connections and > > > >> shared_buffers that prevents it from mapping the buffer contiguously. > > > >> > > > >> Something's missing though, since I'm not hitting the same issue you > > > >> are. How are you generating the connections? I just have an app > > > >> calling PQconnectdb() in a loop, but I guess that's not good enough. > > > > > > I am using the ASCII version of the psqlODBC driver version 8.2.4.2 to > > > establish the test connections. > > > > Could you try the same tests with the client runnint on a different system? > > Since the client eats up a bunch of handles and such as well, and that > > would eliminate the difference due to different clients. > > Followup, when running these tests, could you check using Process Explorer > if you're hitting close to the limit of either of the two pools? See > http://blogs.technet.com/askperf/archive/2007/03/07/memory-management-understanding-pool-resources.aspx Another followup. Been working with Dave on and off today (well, him mostly on to be honest, me a bit more on and off), and it seems that both our repros clearly blame the desktop heap, and nothing else. Please use the desktop heap tool and see if it breaks when the desktop heap usage approaches 100%: http://www.microsoft.com/downloads/details.aspx?familyid=5cfc9b74-97aa-4510-b4b9-b2dc98c8ed8b&displaylang=en It'd still be good to know why the difference is so big between your two systems. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
