Re^2: 'A' web server takes another "time out" (sar)

Yes, 'sar' was what I first reached for, realizing that it is far better to compactly collect all of the performance data so that after the fact you can view slices of it this way and that to try to figure out what the matter is...

 $ sar
ksh: sar: not found
 $ ls -l /var/adm
ls: adm: Permission denied
 $ ls -ld /var/adm
drwxr-x---  3 root  wheel  512 Jan 22  2001 /var/adm/
 $
[download]

And I'm certainly not 'root' nor in 'wheel'. (:

- tye

Comment on Re^2: 'A' web server takes another "time out" (sar) Download Code

Replies are listed 'Best First'.
Re^3: 'A' web server takes another "time out" (sar) by m.att (Pilgrim) on May 04, 2006 at 18:24 UTC
Well, that's a bust.. too bad. How about capturing some regular snapshots with `vmstat`? Maybe `vmstat 60` and a `vmstat -d 60` piped to a file for a few days (or at least a good bit of time before, during and after the event in question). (These commands may require different syntax if you're on FreeBSD, which I can't test with -- we're basically looking for VM stuff and IO/disk stuff... also see `iostat`) Maybe also throw in a few vmstat -s's for good measure. This would at least provide a little bit more detail around swap in/out and IO. m.att	[reply] [d/l] [select]
Re^4: 'A' web server takes another "time out" (sar) by tye (Sage) on May 04, 2006 at 18:46 UTC
But I think that'd mostly be less information than I'm currently getting from 'top'. In any case, it doesn't give me the main system data I'm now wanting: which process(es) is creating the flood of new 'httpd's. I tell you, Win32's PerfMon sure looks great in comparison to this hacking.... - tye	[reply]