let us recall what we are going to solve in TS-1006, we are going to solve the memory shift problem in CLFUS ram cache，let us assume we have 10G ram total, and we set ram cache for 8G, which is reasonable for not so busy site. and we set ram cache cut size to 128KB, that is we hold 4K 8K 16K 32K 64K 128K objects in the ram cache.
in the first, all objects (size 4-128K) is able to stay in the ram cache cause the ram cache is not full when it is full, let us assume: 4K consumes 1G ... 128K consomes 3G and as the time ticks, CLFUS will try to free big objects, and replace with small objects. where the free is free to freelist, and replace is a alloctor new 4K memory blocks. at the end, we get: 4K = 3G ... 128K = 1G in our origin system, there is 2G memory waste, that is where the memory gone. then comes the root cause here, CFLUS will try to free big blocks, which is not free indeed, it is linked into the freelist, which is still in the TS memory. we should release those memory as we DO NOT need it anymore, in any time, that is what we need to archive in Yunkai's patch. FYI 在 2012-12-10一的 08:05 -0700，Leif Hedstrom写道： > On 12/9/12 11:02 PM, Aleksey Kluchnikov wrote: > > * [email protected] <[email protected]> [2012-12-09 00:47:51 +0800]: > > > > > > We use ATS on freebsd (6Gb RAM) for tens millions requests at day. > > We have to reboot it twise at day becouse of memmory waste. > > That sounds more like a memory leak. What the Taobao patch tries to solve is > the case where if you have a very large spike in requests / connections, > memory usage will go up to handle that, but then never releases that memory. > > One thing that I still don't understand is how this actually helps a whole > lot. For example, if the system has to allocate 10GB of RAM to handle a > traffic spike, and this patch later reduces that to 6GB, what are you using > that "freed" 4GB of RAM for? You can't allocate it for something else if you > ever want to handle that same size spike that brought you up to 10GB. > > What would make sense is to change how we throttle on connections, such that > we don't let the freelist's go above a certain thresshold even at spikes. > But, then again, I'm probably missing something here... > > -- Leif >
