I think it is the same bug you mentioned. Not sure if I completely understood
your guidance though. I changed the original DTrace script so it contains the
following pieces of extention:
postgresql*:postgres::ready_for_query_start
{
alloc["readyForQuery"] = cpu;
self->readyForQuery = timestamp;
}
postgresql*:postgres::ready_for_query_end
/self->readyForQuery && alloc["readyForQuery"] != cpu /
{
@migrations["readyForQuery"] = count();
}
postgresql*:postgres::ready_for_query_end
/self->readyForQuery && alloc["readyForQuery"] == cpu /
{
@nonmigrations["readyForQuery"] = count();
}
postgresql*:postgres::ready_for_query_end
/self->readyForQuery /
{
@count["readyForQuery", '-'] = count();
@elapsed["readyForQuery", '-'] = sum(timestamp - self->readyForQuery);
self->readyForQuery = 0;
}
Here I add the "alloc" array to recall the cpu used when assigning to a self
var. If this same self var is set to zero later on I either increment the
@migrations or the @nonmigrations assocarr for the key equal to that self var
name.
The results of this is:
(MIG: migrations; NMG: NON migrations)
MIG readyForQuery 294974
MIG handleCommand 4288534
MIG ts[arg0,arg1] 8474999
MIG mode[arg0] 8512348
NMG mode[arg0] 5217
NMG ts[arg0,arg1] 75472
NMG readyForQuery 948196
NMG handleCommand 1383594
This shows there is a overwhelming abundance of migrations.
--Paul
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
[email protected]
