We are using innodb mysql, each insert (autocommit) will take about 50 ms.
For each physical write, it usually takes about 10 ms, so there must be a
few physical IO caused by the sql.
Based on mysql doc, each sql will cause a fsync to sync the redo to disk.
And one fsync will at least write the
Hi
I'm running a simple DTrace script that has the following clause:
pid$target::ReportTx:entry
/arg1 != 0 this-numEntries != 0/
{
printf(NumEntries: %lld\n, (long long)this-numEntries);
this-entry =
(ReadAcqEntry*)copyin((uintptr_t)(this-rAcqArr[this-numEntries-1]),
On Tue, May 4, 2010 at 11:23 AM, Yossi Lev yosef@sun.com wrote:
Hi
I'm running a simple DTrace script that has the following clause:
pid$target::ReportTx:entry
/arg1 != 0 this-numEntries != 0/
{
printf(NumEntries: %lld\n, (long long)this-numEntries);
this-entry =
Thanks Chad, but I don't think that this is the problem. The this-rAcqArr
points to the beginning of an array in the traced process. I initialize it in
a previous clause that has exactly the same probe:
pid$target::ReportTx:entry
/arg1 != 0 /
{
this-dataP = (ProfData*)copyin(arg2,
I have some more information, that suggests that something is just wrong with
the way I'm using stringof. I tried replacing stringof(this-pcInt) with
stringof(5) and still got the error.
So, I tried the following one-liner from the shell:
dtrace -n 'BEGIN{printf(%s\n,stringof(0x5));}'
dtrace:
On Tue, May 4, 2010 at 12:58 PM, Yossi Lev yosef@sun.com wrote:
Moreover, I know that the value that I'm getting is valid, because I had the
following printf statement:
pid$target::ReportTx:entry
/arg1 != 0 this-numEntries != 0/
{
printf(NumEntries: %lld\n, (long
Check out slides 17 and 18 of DTrace Tips, which you can find
here;
http://blogs.sun.com/bmc/entry/dtrace_tips_tricks_and_gotchas
On May 4, 2010, at 6:23 PM, Jianhua Yang wrote:
I wanted to find out what the single threaded process was doing with dtrace
but it returned with Not enough
Hi All,
I used the following script from the dtrace manual to measure how long a
particular process runs on the cpu. Modified it to look at the exact timestamps:
[i]
sched:::on-cpu
{
self-ts = timestamp;
printf(on=%d\n, self-ts)
}
sched:::off-cpu
/self-ts/
{
printf(off=%d\n, timestamp)
self-ts
Cool,
thanks a lot, Jim !
Jianhua Yang
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
