Tag Info

Hot answers tagged

6

I would probably argue that you should care not about what's in the cache, but whether the most effective things have been cached. Ie, is the ARC cache being used to its maximum efficiency? I run a small-scale (9TB) ZFS implementation at work and I find Ben Rockwood's tool arc_summary.pl, and Sun's arcstat.pl, both detailed in this cuddletech blog post, to ...


4

The first script fails because the example is incorrect. You can't reference args[] while globbing the probe in that manner (as probes matching the pattern may come and go while the enabling is still in effect, so guarantees about the type of args[N] can't be made). You'd need to list each nfs3-op-* individually, comma separated ...


3

Snow Leopard ships with a DTrace sample script called /usr/bin/newproc.d. It does want you want - however only globally. To restrict it to a single process you could try something like this: cp /usr/bin/newproc.d ~/newproc.d Add a new predicate by changing the following lines 19: proc:::exec-success 20: { into this: 19: proc:::exec-success 20: / ppid ...


3

Please see my update above. This is a bad security hole if I've ever seen one. A proper implementation of dtruss should drop privileges of any program it invokes. Having several users on a system, one of them would be bound to mess this up and allow a badly written program to trash things.


3

You don't mention what OS you're running on said system, but if it's running Windows you can use Microsoft Network Monitor, which shows the process ID for each "conversation" so it should allow you to focus your analysis. "Filtering" traffic per process ID is as simple as selecting the process in the left pane and viewing it's traffic in the right pane.


2

Not sure this is what you require, but netstat can help you associate process id with network port. In wireshark you can then filter on that port number, to only sniff a specific process id's packets.


2

dtrace is definitely the tool you are looking for. you can use a relatively simple script to find out which syscall is exactly most time-consuming. Something like this: #!/usr/sbin/dtrace -s syscall:::entry /execname == "iostat"/ { self->ts = vtimestamp; } syscall:::return /self->ts/ { @[probefunc] = sum(vtimestamp - self->ts); @["- ...


2

You might find Brendan Gregg's recent blog series on filesystem latency useful. He shows a couple of scripts for investigating filesystem usage with the syscall provider (which should be more reliable for identifying the responsible processes than the io provider used by iotop). For example, the syscall-read-zfs.d script shown in Part 4 could easily be ...


2

If you want to measure which applications are reading/writing the most, you want to measure at the syscall level. At the device level it's only kernel threads doing their work.


1

I don't know dtrace, but looking at that wiki page shows that it has basic math operators built in. So there is no reason you couldn't multiply the numbers before printing them.


1

Have you tried using -f ? It tells truss to follow any children the original command spawns. I'm not sure if that will work because the tar command isn't actually spawning the gzip command. The other option that might work is: truss -leDo /tmp/truss.tar.out tar cvf - dirs/ | truss -leDo /tmp/truss.gzip.out gzip -1 > archive.tar.gz Again, however, I ...


1

Here's a script that's been updated to reflect the data in L2ARC. See: http://blog.harschsystems.com/2010/09/08/arcstat-pl-updated-for-l2arc-statistics/ Source available here: https://github.com/mharsch/arcstat


1

I think I've figured it out, it's the dtrace script which I grabbed from a Solarius site, needs to be changed for BSD.


1

On windows there is an experimental build that does this, as described on the mailing list: http://www.wireshark.org/lists/wireshark-dev/201212/msg00069.html


1

Recently I ran into a really nice solution for this problem and wanted to share. It is found in the DTrace Book: http://www.dtracebook.com You'll want to pull down the examples from here: http://www.dtracebook.com/images/dtbook_scripts.tar.gz I'm running no OS X. I extracted the scripts to dtbook under my ~/bin and executed the appropriate script as ...


1

You need to use dtrace, for that level of introspection. Here's basically the nfsv3fileio.d example from https://wikis.oracle.com/display/DTrace/nfsv3+Provider, but updated to run live (I think, my testing was minimal). That same page has a few more examples. You might also Google for 'nfssvrtop'. #!/usr/sbin/dtrace -s #pragma D option quiet ...


1

I opened a support ticket with Nexenta to try to get an official answer since I tried to search through the UI and configuration files for a tunable... Currently there is no way of increasing the timeouts for the analytics in the current version. This will be rectified in a future version.



Only top voted, non community-wiki answers of a minimum length are eligible