On Sat, Mar 01, 2008 at 06:00:40AM -0800, Paul van den Bogaard wrote:
> 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.
For you to be running into the same problem, you would have to have some
CPU that is getting _nothing_ but deallocations. It would be interesting
to just aggregate on CPU; where you would alloc, do this:
@alloc[cpu] = count();
And where you would dealloc, do this:
@dealloc[cpu] = count();
And then in an END or tick probe, do this:
printf("%8s %8s %8s\n", "CPU", "ALLOC", "DEALLOC");
printa("%8d [EMAIL PROTECTED] [EMAIL PROTECTED]", @alloc, @dealloc);
If you're running into the bug that I recently ran into, you should have
one row that -- for some elongated period -- has zero allocations and
many deallocations.
And in terms of a workaround, try adding this clause to your D script:
profile-1hz
{
bogus[cpu, timestamp] = timestamp;
bogus[cpu, timestamp] = 0;
}
If you're running into this problem, the above clause should eliminate
the drops...
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks. http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
[email protected]
