Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> If saying "hey, I just called sbrk() for another page of memory" or "I 
>> just did six I/Os to satisfy a select query" was as easy as sending 
>> something to syslog, I expect a lot more libraries would implement those 
>> sorts of measurements.
> 
>   I'm not exactly sure what you mean by that. Examining the brk() system
> calls made by a process is quite easy using 'strace' (or in some unix systems
> 'truss').

I mean that if programmers didn't need to build the entire reporting 
infrastructure, but could instead just "add points to the graph", I 
expect programmers would be more likely to include the code to do so.

The comparison with syslog was meant to say: If every programmer had to 
recreate the entire syslog deamon and reporting infrastructure, you'd 
have far fewer programs capable of doing distributed monitoring. As it 
is, all the program needs to do is drop a UDP packet, and the whole 
"where does it go, who sees it, and do I send a page" thing is already 
written for it.

If there was a system call that said
   add_to_counter("MemoryPagesUsed", 1)
   add_to_counter("MemoryPagesUsed", -1)
already written, you'd probably see a version of the C runtime library 
with a switch that would invoke those calls within malloc and free.

Plus, you'd probably see a bunch more servers reporting the same way: 
pages served per second from Apache, queries answered by MySQL, etc. 
Rather than (for example) having to parse Apache web logs to figure that 
out for Apache, and someone else's logs to figure it out for *that* 
program, and etc.

>   But anyways, for my purposes it would be enough to get whatever tools
> like 'top' are using to measure the memory usage of the program.

Yah. I was kind of disappointed when I was running "top" and seeing (for 
example) several programs blocked, nobody running, no disk I/O, no 
network I/O, etc.  vmstat turned out to tell the real story, but not on 
a per-processes basis.

>   Simply examining mallocs and frees performed by the program does not
> give an accurate figure. The actual amount of memory used by the program
> may be significantly larger. For example memory fragmentation can cause
> this quite prominently.

Fair enough. :-)  I wasn't sure just what you were after.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message