[
https://issues.apache.org/jira/browse/MESOS-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164856#comment-13164856
]
[email protected] commented on MESOS-89:
----------------------------------------------------
bq. On 2011-12-07 21:10:13, Charles Reiss wrote:
bq. > src/Makefile.in, line 137
bq. > <https://reviews.apache.org/r/3050/diff/1/?file=62806#file62806line137>
bq. >
bq. > MONITORING_OBJ should be set to empty string unconditionally first.
Done.
bq. On 2011-12-07 21:10:13, Charles Reiss wrote:
bq. > src/monitoring/proc_utils.hpp, line 39
bq. > <https://reviews.apache.org/r/3050/diff/1/?file=62807#file62807line39>
bq. >
bq. > Please state whether RSS or VSIZE or something else.
Done.
bq. On 2011-12-07 21:10:13, Charles Reiss wrote:
bq. > src/monitoring/proc_utils.cpp, line 22
bq. > <https://reviews.apache.org/r/3050/diff/1/?file=62808#file62808line22>
bq. >
bq. > include all system .h headers either before or after standard C++
headers.
Done.
bq. On 2011-12-07 21:10:13, Charles Reiss wrote:
bq. > src/monitoring/proc_utils.cpp, line 61
bq. > <https://reviews.apache.org/r/3050/diff/1/?file=62808#file62808line61>
bq. >
bq. > Please make these file-scoped (static or anonymous namespace) or put
them in the header file.
Done.
bq. On 2011-12-07 21:10:13, Charles Reiss wrote:
bq. > src/monitoring/proc_utils.cpp, line 81
bq. > <https://reviews.apache.org/r/3050/diff/1/?file=62808#file62808line81>
bq. >
bq. > O is a pretty bad variable name.
Done. I was using outdated documentation where this field was a hard-coded 0 in
proc. It is now num_threads.
bq. On 2011-12-07 21:10:13, Charles Reiss wrote:
bq. > src/monitoring/proc_utils.cpp, line 85
bq. > <https://reviews.apache.org/r/3050/diff/1/?file=62808#file62808line85>
bq. >
bq. > Check whether this read succeeds.
Done.
bq. On 2011-12-07 21:10:13, Charles Reiss wrote:
bq. > src/monitoring/proc_utils.hpp, line 37
bq. > <https://reviews.apache.org/r/3050/diff/1/?file=62807#file62807line37>
bq. >
bq. > Why milliseconds? libprocess uses seconds since some time, and I
think USER_HZ usually (often?) isn't 1000.
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.
bq. On 2011-12-07 21:10:13, Charles Reiss wrote:
bq. > src/monitoring/proc_utils.hpp, line 33
bq. > <https://reviews.apache.org/r/3050/diff/1/?file=62807#file62807line33>
bq. >
bq. > Why strings? (and elsewhere)
bq. >
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.
- 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:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3050/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-08 00:00:32)
bq.
bq.
bq. Review request for mesos.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. 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.
bq.
bq.
bq. This addresses bug MESOS-89.
bq. https://issues.apache.org/jira/browse/MESOS-89
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. src/tests/Makefile.in ea943f7
bq. src/tests/proc_utils_tests.cpp PRE-CREATION
bq. src/monitoring/proc_utils.cpp PRE-CREATION
bq. src/Makefile.in 516f128
bq. src/monitoring/proc_utils.hpp PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/3050/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Sanity tests have been written in src/tests/proc_utils_tests.cpp for all
utility functions, and functions have been tested ad hoc.
bq.
bq.
bq. Thanks,
bq.
bq. Alex
bq.
bq.
> create utilities to collect information from the proc filesystem
> ----------------------------------------------------------------
>
> Key: MESOS-89
> URL: https://issues.apache.org/jira/browse/MESOS-89
> Project: Mesos
> Issue Type: Sub-task
> Components: slave
> Environment: This is specific to Linux, as OS X does not have a proc
> filesystem.
> Reporter: Sam Whitlock
> Assignee: Alex Degtiar
> Priority: Minor
> Labels: monitoring
>
> This is a utility for MESOS-38 https://issues.apache.org/jira/browse/MESOS-38
> Create a collection of utilities to read information from the proc
> filesystem. This will be used in MESOS-38 to collect most of the information
> for the process-based isolation usage reporting mechanism. These utilities
> will also be used for certain functionality in monitoring lxc-based isolation
> because not all of the information needed is available via the cgroup
> interface, such as the start time of the container.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
