OK, By heart, not tested!
/*
To check how well we are allocating connections from memory instead
of creating them.
Of course a connection is merely a piece of memory and not a
resource intense thing as
a database connection. But stil.
*/
memcached*:::conn-allocate
{
@["allocated"] = count();
}
memcached*:::conn-create
{
@["created"] = count();
}
/*
The above can be combined like:
Must say I have never seen the comma separator while
only specifying the probename.
*/
memcached*:::conn-allocate,
memcached*:::conn-create
{
@[probename] =count();
}
/*
How many system calls were there, and which one
between allocation of a connection and the release
of it.
*/
memcached*:::conn-allocate
{
self->allocate = arg0;
}
memcached*:::conn-release
/self->allocate/
{
self->allocate = 0; /* Not sure if 0 is a valid value for a connID
though. If that's the case this does not work */
}
syscall:::entry
/self->allocate/
{
@syscalls[pid, probefunc] = count();
}
it is basically this way of using a combination of multiple
providers that makes DTrace unique. If you use internal stats
counters they just provide a story without context.
Have fun playing with it. Questions? Ask. Sometime I now an anwer ;^)
--Paul
On 7-mrt-2008, at 15:42, Roy Lyseng wrote:
Well, I hoped it would spur some more clever ideas...
I thought it could be useful if you have some problems with your
application, and can use dtrace to track what operations are
actually performed on one particular key.
But aggregations may probably be more interesting.
Roy
Paul van den Bogaard wrote:
Mmm, I think that if copyinstr(arg1) == '1234..." that your trace
output will be rather dull :-)
--Paul
On 7-mrt-2008, at 14:37, Roy Lyseng wrote:
Another, slightly more advanced script is memcached-keytrace.d:
:memcached::command-set,command-add,command-delete,command-get
/pid == $target && copyinstr(arg1) == "123456789"/
{
trace(copyinstr(arg1));
}
END
{
}
This one will trace set, add, delete and get commands applied to
one specific key:
Invoke as:
dtrace -s ~/memcached/dtrace/memcached-trace.d -p 24167
Then run a telnet session:
telnet system 11211
Trying 9.9.9.9...
Connected to system.
Escape character is '^]'.
abcdefghij
ERROR
set 123456789 0 0 10
abcdefghij
STORED
delete 123456789 0 0
DELETED
get 123456789 0 0 0
END
And the dtrace script reports:
CPU ID FUNCTION:NAME
1 54165 complete_nread:command-set 123456789
0 54159 process_delete_command:command-delete 123456789
1 54160 process_get_command:command-get 123456789
Useful? Maybe...
Roy
Dustin Sallings wrote:
For those of us who haven't truly unleashed the power of
dtrace, can you describe the kinds of things we can learn from
this (perhaps with scripts)?
--Dustin Sallings (mobile)
On Mar 6, 2008, at 4:48, Trond Norbye <[EMAIL PROTECTED]> wrote:
On Mar 5, 2008, at 3:52 PM, Trond Norbye wrote:
The following patch adds a new configure-option (--enable-
dtrace) that adds DTrace probes to various parts of memcached.
Please comment.
Trond
I discovered that I had some "leftovers" in this patch from
before I fixed the comments regarding the large page support..
The attached version is replacement for the original patch.
Trond
<dtrace.patch.gz>
---------------------------------------------------------------------
------------------------ Paul van den
Bogaard [EMAIL PROTECTED]
ISV-E -- ISV Engineering, Opensource Engineering group
Sun Microsystems, Inc phone:
+31 334 515 918
Saturnus 1
extentsion: x (70)15918
3824 ME Amersfoort mobile:
+31 651 913 354
The Netherlands
fax: +31 334 515 001
------------------------------------------------------------------------
---------------------
Paul van den Bogaard
[EMAIL PROTECTED]
ISV-E -- ISV Engineering, Opensource Engineering group
Sun Microsystems, Inc phone: +31
334 515 918
Saturnus 1
extentsion: x (70)15918
3824 ME Amersfoort mobile: +31
651 913 354
The Netherlands
fax: +31 334 515 001
