> 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
This bug analysis is correct. The bug is fixed by Shane's patch linked earlier in the thread. With the patch, an 11MB -shm file is mapped into memory in around 350 chunks with an average size of 48KB. Total address space used is around (350*48KB). Instead of the (350*5.5MB) that 3.7.2 was using. > 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? It is separate. This bug was in the OS specific win32 layer Dan. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
