Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 157 by neil.mckee.ca: Instrumenting memcached with sFlow
http://code.google.com/p/memcached/issues/detail?id=157
This patch is a proposed enhancement against the central repo that adds
sFlow monitoring.
This approach addresses the same problem-space as ticket 109:
http://code.google.com/p/memcached/issues/detail?id=109
However with sFlow all the analysis is moved off the server, leaving only
the essential minimum. Alternative approaches such as tcpdump, systemtap
and dtrace do not scale well in a production environment.
For background on this, see:
http://blog.sflow.com/2010/09/memcached.html
If you compile with this patch, then you can run with "memcached -u
nobody -o sflow=on", and it will pick up configuration from /etc/
hsflowd.auto, such as:
sampling=400
polling=20
agentIP=10.0.0.112
collector=10.0.0.111 6343
"agentIP" should be the IP of the server, and "collector" should be
the IP of an sflow collector such as "sflowtool":
http://www.inmon.com/bin/sflowtool-3.17.tar.gz
(This config file is generated automatically if you install hsflowd.
hsflowd is the host sFlow daemon from host-sflow.sourceforge.net which
contributes an sFlow feed of server performance stats.)
Neil
NOTES:
(1). Provided the sampling-rate is set appropriately, the overhead
should be roughly equivalent to adding one extra stats counter. The
critical path is just a decrement-and-test on a per-thread counter (no
locking).
(2). The changes are all within "#ifdef SFLOW" except for (3) below.
(3). I changed memcached.h:struct conn->request_addr to be of type
struct sockaddr_storage so it would work for IPv6 too.
What version of the product are you using? On what operating system?
Attachments:
sfmc_20100923.zip 24.8 KB
