Re: Performance problem in aset.c
От | Karel Zak |
---|---|
Тема | Re: Performance problem in aset.c |
Дата | |
Msg-id | Pine.LNX.3.96.1000713105731.7197A-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | Performance problem in aset.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, 11 Jul 2000, Tom Lane wrote: > A straightforward solution would be to scan the entire freelist > and give back the smallest block that's big enough for the request. > That could be pretty slow (and induce lots of swap thrashing) so > I don't like it much. Yes. It is right solution. A little better chunk selection can be allowed with more freelist than current 8. If we will 16 free lists a chunk real size and request size will more similar. > Another idea is to split the returned chunk and put the wasted part back > as a smaller free chunk, but I don't think this solves the problem; it > just means that the wasted space ends up on a small-chunk freelist, not > that you can actually do anything with it. But maybe someone can figure > out a variant that works better. If I good understand it is a little like my idea with one-free-chunk from block residual space. It is not bad idea, but we have aligned chunks now. A question is if in wasted part will always space for new *aligned* chunk. And second question, not will this method create small and smaller chunks? For example you after 1000 free/alloc you will have very much small chunks (from the wasted part). The chunk from wasted part is good, but you must have usage of this chunks. *IMHO* current new mem design create new demand on context. In old design we used one context for more different proccess and request-allocation-size was more heterogeneous. But now, we use for specific operetions specific contexts and it probably very often create context that use very homogeneous chunks. For example if a testing my query cache 90% of all alocation are in the range 16-32b and one cached plan need 2000-5000b --- effect it that query cache not need 8Kb blocks ...etc. Very simular situation will in other parts in PG.Tom add to AllocSet context defaul/max block size setting for each context. It is good and it is first step to more specific context setting. Hmm, I haven't idea for some next step now... But something setting is needful for chunks operations (for example primary-default chunk size and from this frequent freelist, big chunk limit setting ..etc.) Karel
В списке pgsql-hackers по дате отправления: