I am so glad that there are people interested in this :) The reporter actually consists of 3 parts, a user space daemon that takes snapshot from kernel and does the actual data analysis, a kernel space collector that collects the data, and a traffic interceptor that has a hook inside the TCP/IP stack. Of these, only the hook is patched to Kernel code, the other collector and interceptor stuff runs as an independent module ( implemented via a misc device ). I packaged the kernel space code into one patch to facilitate building.
We did some in-house testing on the performance impact to memcached. Generally if the reporter is turned on, there would be about 5%-10% performance hit, depending on the key size, value size, operation and number of connections. Also, we track each server independently in the kernel space, so each additional target server adds about 200M ~ 300M memory requirement to hold its related data. Haibin On May 5, 10:26 pm, Paul Nasrat <[email protected]> wrote: > I think it would certainly be worth releasing, even if it's a kernel > patch that is unlikely to get upstreamed it'd be an interesting > talking point and useful to play with. > > Do you have any stats/testing on the impact of the collector on the > kernel? > > Also if you're distributing these changes in the kernel of your > product and distributing it then releasing it is really just complying > with the kernel license. > > Paul
