Live data from Hacker News

Strace - The Sysadmin's Microscope

blogs.oracle.com

1–10 of 25 posts

Re: Strace - The Sysadmin's Microscope

#3
strace tip #31415927: If your program is I/O bound, sometimes you can improve performance by increasing the size of the read buffer. A bigger buffer means fewer system calls and potentially increased performance. How do you know how big the read buffer is? Sometimes it's hard to tell even if you have the source (i.e. you're using stdio). With strace you can see the number of bytes you're trying to slurp in with each read system call. If it looks like a small number, you can then go figure out how to make it a bigger number, perhaps using setvbuf or rolling your own buffered I/O.

Re: Strace - The Sysadmin's Microscope

#10
It's also worth looking at SystemTap or DTrace, depending on what OS you're running. While strace will allow you to look at an individual process and its children, SystemTap/DTrace will allow you to gather data on system call (and then some) usage system wide. Some examples:

- monitor execve() calls system-wide

- monitor I/O to a specific file, from any process

- measure per-process network usage

(note that newer Linux kernels may have other ways of accomplishing some of these tasks that I'm not aware of).

I've had a lot of success using SystemTap to look at low-level filesystem performance issues in the kernel. We've run SystemTap scripts on our production filesystem servers for over a year with no problems whatsoever.

Edit: formatting

Post reply on HN