incubator-mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Degtiar" <alex.degt...@gmail.com>
Subject Re: Review Request: Create utilities to collect information from the proc filesystem
Date Wed, 21 Dec 2011 03:24:32 GMT


> On 2011-12-07 21:10:13, Charles Reiss wrote:
> > src/monitoring/proc_utils.hpp, line 37
> > <https://reviews.apache.org/r/3050/diff/1/?file=62807#file62807line37>
> >
> >     Why milliseconds? libprocess uses seconds since some time, and I think USER_HZ
usually (often?) isn't 1000.
> 
> Alex Degtiar wrote:
>     Sam and I decided on milliseconds (since epoch when appropriate) for all measured
times because it was the granularity closest to the times in various sources, and having one
unit used consistently seemed cleaner. Would it make it more consistent with the rest of Mesos
if we scale it up to seconds?
>     
>     For reference, granularity of various times we used:
>     process start time (used for duration of initial read)- jiffies (4ms +/- depending
on system HZ)
>     boot time (used for start time to make it since epoch)- seconds
>     current time (used for duration) - nanoseconds/milliseconds since epoch (depends
on system)
>     cpu time (proc)- clock ticks (10ms +/- depending on system SC_CLK_TCK)
>     cpu time (lxc)- nanoseconds (unit returned in, not sure of actual granularity)
>     Period of measurement - potential lower bound on a single machine is probably in
the millisecond range.
> 
> Charles Reiss wrote:
>     Assuming process::Clock::now() can be counted on to be in time since the epoch (I
don't actually know if this is an API gaurentee), then I think you should have that replace
getCurrentTime() and thus use seconds since the epoch for everything.
>

Done.


> On 2011-12-07 21:10:13, Charles Reiss wrote:
> > src/monitoring/proc_utils.hpp, line 33
> > <https://reviews.apache.org/r/3050/diff/1/?file=62807#file62807line33>
> >
> >     Why strings? (and elsewhere)
> >
> 
> Alex Degtiar wrote:
>     I was deciding between using unsigned integers, something like the pid_t type, and
strings. I ultimately decided on strings because they supported special non-integer 'pids'
proc lets you query (i.e. "self"). This was convenient for testing.
> 
> Charles Reiss wrote:
>     I don't think there's any special "PID" other than "self", and that's easy replaced
with getpid() (which your test already needs).

Replaced with pid_t and getpid().


- Alex


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3050/#review3712
-----------------------------------------------------------


On 2011-12-08 00:00:32, Alex Degtiar wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/3050/
> -----------------------------------------------------------
> 
> (Updated 2011-12-08 00:00:32)
> 
> 
> Review request for mesos.
> 
> 
> Summary
> -------
> 
> The first of several patches related to resource usage monitoring. This patch provides
a collection of utilities for use on Linux for reading stats from proc. It is used by both
the lxc and proc resource collectors.
> 
> 
> This addresses bug MESOS-89.
>     https://issues.apache.org/jira/browse/MESOS-89
> 
> 
> Diffs
> -----
> 
>   src/tests/Makefile.in ea943f7 
>   src/tests/proc_utils_tests.cpp PRE-CREATION 
>   src/monitoring/proc_utils.cpp PRE-CREATION 
>   src/Makefile.in 516f128 
>   src/monitoring/proc_utils.hpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/3050/diff
> 
> 
> Testing
> -------
> 
> Sanity tests have been written in src/tests/proc_utils_tests.cpp for all utility functions,
and functions have been tested ad hoc.
> 
> 
> Thanks,
> 
> Alex
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message