I start rwsnoop -n bash (read/write monitor, only on processes named bash) and iosnoop -m / (I/O monitor, only on the root partition).Nice way to understand buffering and I/O scheduling.Īnother example combining rwsnoop and iosnoop : Analyze disk I/O : how much data was written/read to/from the disk, by which process.Monitor all TCP connections received by the system.Monitor all open syscalls issued on the whole system.DTrace does this by monitor write syscalls issued by your browser containing a GET and mesuring the delay before the subsequent read returns. Mesure the average latency between GET requests and their result when you browse the web using mozilla.Of course, you can also get the usual vmstat results, but only for events caused by a specific process. And you don’t need to restart the app before monitoring it. Monitor system calls for the whole system or a specific app (yeah, DTrace can replace strace, but you already knew that ).Monitor user and library function calls, and profile them like gprof (yeah, DTrace can replace gprof).The execsnoop script (which would be a one-liner if you remove the output formatting, and is available in the DTrace Toolkit) shows that logging in by ssh and running for i in $(seq 1 3) do /bin/echo $i done runs the following processes :Ġ 1172 1171 sh -c /usr/bin/locale -a 0 1172 1171 /usr/bin/locale -a 0 1175 1173 -b1176 id -u 0 1179 1178 dircolors -b 0 1174 1173 pt_chmod 9 0 1180 1175 mesg n 0 1181 1175 seq 1 3 0 1182 1175 /bin/echo 1 0 1183 1175 /bin/echo 2 0 1184 1175 /bin/echo 3 Monitor process creation, even the short ones.With DTrace, you can monitor a lot of stuff and find the answer to a lot of questions, like : It also allows to monitor much more stuff than current Linux tools, in a very easy and clean way. DTrace changes this and uses push instead, which allows to monitor events that you wouldn’t notice on Linux. Most system monitoring tools on Linux use polling : they retrieve some data from the system at regular intervals (think of top, “vmstat 1”, …). This nice graph from the DTrace howto explains it much better than I do : DTrace is a tracing framework, which allows a consumer application (generally a D script) to register with some DTrace providers (probes) and get some data. Yeah, both of them can display windows, and there are still people thinking that fvwm is enough for everybody. It’s like comparing the GNOME project with fvwm. It’s funny how people continue to compare DTrace to strace. In the demo, the developer used DTrace to “discover” that running xterm writes in ~/.bash_history. (In approximate english: DTrace : a sort of layer above ltrace/strace. En démonstration, un type utilise DTrace pour “découvrir” que lancer une xterm écrit dans ~/.bash_history. – DTrace : Sorte de surcouche de strace/ltrace. And I got the chance to play with DTrace.īefore writing this blog entry, I was considering writing a LinuxFR article about DTrace, when I came across this LinuxFR “journal” about Solaris 10, which gave me a good laugh. It works very well (good hardware support & detection, nice GNOME desktop). NexentaOS is basically Debian GNU/kOpenSolaris (Debian userland, with an OpenSolaris kernel.
Today, I installed NexentaOS on a Grid5000 cluster node. Posted in Technology 1 Comment Played with DTrace It’s very easy to use : # dd if=/dev/hda12 | pv |dd of=/dev/hda13 88.2MB 0:00:04 Īnd it can even give an ETA if you use it like cat (e.g: pv file | nc -w 1 3000). Its standard input will be passed through to its standard output and progress will be shown on standard error. To use it, insert it in a pipeline between two processes, with the appropriate options. Description: Shell pipeline element to meter data passing through pv (Pipe Viewer) can be inserted into any normal pipeline between two processes to give a visual indication of how quickly data is passing through, how long it has taken, how near to completion it is, and an estimate of how long it will be until completion. Interesting, isn’t it ? But I’ve found something even more interesting : pv (packaged in Debian/Ubuntu). If you read the doc, you would have found this : Sending a USR1 signal to a running ‘dd’ process makes it print I/O statistics to standard error and then resume copying. You often run it through complex pipes (well, I do), and you never know if it’s performing well (or if you forgot to tune the HD perf with hdparm before).
0 kommentar(er)
