rickey c weisner wrote:
Joachim,
I do not have a solution to your tcpsnoop issues. Basically when Solaris
changes the way the tcp stack works in the kernel, tcpsnoop gets broken.
O.k., I'll have a second look, maybe I can get it to work without too
much hassle. Just wanted to check before.
Hye everybody,
I just try to write a simple DTrace program to trace I/O from the application
point of view (and not the Disk Driver point of view (io::*:* provider)).
My first idea is to trace calls to syscall read and write.
Is it enougth to trace efficiently all application I/O or not ?
I'm troubleshooting an I/O performance problem with one of our applications
that does a lot of writing, generally blocks just over 32K, sequentially
writing large files. It's a Solaris 10 x86 system with UFS disk. We're often
only seeing disk write throughput of around 6-8MB/s, even when
Cross-posted to perf-discuss.
You can't change the write behavior of the app without
changing the app itself. The code would need to be modified
to issue fsync() calls on the file(s), or open the files for
synchronous writes (O_SYNC | O_DSYNC flags).
fsflush will run, by default, once per
