On Fri, Sep 10, 2010 at 11:29 AM, Michele Pradella < michele.prade...@selea.com> wrote:
> I forgot to tell you something: in my situation the -shm file is > always small in size (about 6-7MB) even when I got 2GB of Virtual Bytes. > But it seams that is mapped too much times. > I see something that you could obtain if you do this: > for (int i=0;i<1000;i++) > "Map -shm in memory" > This is the strange behavior...because seams that the file is mapped in > memory but never removed: probably it's removed only when you close the > connection, but if the during the query you wast too much memory you got > "Disk I/O error" and the application reach an critical state. > > Michele, thanks for pointing out to vmmap, sysinternals made them so fast, I can not track them all. This is an excellent utility. I think that the development team already knows that is going on, just my speculation. As long as I see, every next file mapping wants to see not only requested 32k region, but also every prior, so every CreateFileMapping/MapViewOfFile wants more on every next step, 32k-64k-96k (this is visible in vmmap and corresponds to the code in winShmMap). And as long as I see, the problem is that Windows allocates separated ranges of memory space for every region even if they're intersecting, i.e every MapViewOfFile needs to find a brand new address space range for every new region request. So we have 2,000,000k = (32k*(X + 1)/2)*X where X - is the number of region requests when the memory address space get to 2g limit. And the answer for this X here is about 350 that leads us to 350*32k = 11M shm file. So this size that I noticed in my tests confirms this theory I don't know about the internal logic that requires this, but on Windows 350 regions is a maximum in this case. Does it mean that linux share address space for superset/subset regions in contrary to Windows logic? Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
