From: Vlad K. <hv...@us...> - 2009-04-30 07:00:54
|
> On Monday 27 April 2009 12:29:16 Vlad Khorsun wrote: >> > On Friday 24 April 2009 16:31:00 Vlad Khorsun wrote: >> >> I see two options : >> >> >> >> a) disable "parent_redirect". It will make HEAD work almost as 2.1, >> >> AFAIU >> >> >> >> b) rework "parent_redirect" to request medium sized memory chunks from >> >> parent pool (say 4-8KB) and use it to allocate memory for immediate >> >> callers. When such pool is freed it (pool) have to deallocate from >> >> parent pool much less number of memory blocks. >> >> >> >> Opinions ? >> > >> > In v.3.0 we plan to use vulcan's memory allocator. Looks like it can >> > behave better, specially under MT load. Therefore I suggest to choose >> > option (a) - sooner of all it's no use wasting time with MemoryPool >> > optimization. What about memory - it's cheap :) >> >> I have concern with this simple solution. Before v2.5 we allocated some >> pools from database pool - in DFW, DYN (i don't care about it much as it is >> short lived temporary pools) and in CMP which is more questionable, i >> think. > > Did you take a look - how did it 1.5 where we had no "parent_redirect" ? As far as i can see JrdMemoryPool used in CMP_compile2 allocates at least 16KB with malloc at creation time. Current pools will allocate at least 64KB from OS with VirtualAlloc\mmap. >> Disable "parent_redirect" in CMP pool (this is request's pool) will >> make every request allocate 64KB at least (despite of real needs). Is it >> what we want ? > > On the one hand, memory is cheap today. On the other - do we have some > statistics about it? If we really use not more than Xkb (where X is much than > 64) per typical request, may be request single medium-size memory chunk of > Xkb from parent and later continue with normal operation? It will be > something like inline storage in arrays. Is it different from my option (b) above ? Another compromiss could be to reduce REDIRECT_THRESHOLD from current 32KB to some less value. Regards, Vlad |