[dtrace-discuss] Struggling with dynvar space: how big should

[Paul van den Bogaard]

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