> On April 16, 2018, 10:32 a.m., Alexander Rukletsov wrote: > > 3rdparty/libprocess/src/memory_profiler.cpp > > Lines 286 (patched) > > <https://reviews.apache.org/r/63368/diff/10/?file=1998458#file1998458line286> > > > > Can we add a subfolder with current process pid to address scenarios > > where multiple libprocess processes are profiled on the same machine?
The `XXXXXX`-part already makes it unique per process. > On April 16, 2018, 10:32 a.m., Alexander Rukletsov wrote: > > 3rdparty/libprocess/src/memory_profiler.cpp > > Lines 325-328 (patched) > > <https://reviews.apache.org/r/63368/diff/10/?file=1998458#file1998458line325> > > > > This can also happen if there are no useful data in the profile. Is it > > what you mean by "empty"? Yes, that's what I meant. Reworded to "contains data". > On April 16, 2018, 10:32 a.m., Alexander Rukletsov wrote: > > 3rdparty/libprocess/src/memory_profiler.cpp > > Lines 667-672 (patched) > > <https://reviews.apache.org/r/63368/diff/10/?file=1998458#file1998458line667> > > > > Current logic allows users to download profiles from the _previous_ run > > while the _current_ run is active. Is it done on purpose? > > > > I can imagine users expecting download to return intermediate results > > of the _current_ run, hence I'd rather either clean the state before > > starting a new run or disallow implicit, i.e., without id, download request > > if a profiling is running. Ok, added as a special case. - Benno ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/63368/#review201184 ----------------------------------------------------------- On April 10, 2018, 2:39 p.m., Benno Evers wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/63368/ > ----------------------------------------------------------- > > (Updated April 10, 2018, 2:39 p.m.) > > > Review request for mesos, Alexander Rukletsov and Benjamin Mahler. > > > Repository: mesos > > > Description > ------- > > This class exposes profiling functionality of jemalloc memory allocator > when it is detected to be the memory allocator of the current process. > > In particular, it gives developers an easy method to collect and > access heap profiles which report which pieces of code were > responsible for allocating memory. > > > Diffs > ----- > > 3rdparty/libprocess/Makefile.am c895d3ac7b9cc5ffd6c8b57ff24def866eb0213d > 3rdparty/libprocess/include/process/process.hpp > c36df991b6a2c120ab0562e8ff907f9fbf8630d1 > 3rdparty/libprocess/src/CMakeLists.txt > 0ce7dac5deea94623530820d173ce3ffe5b42ea4 > 3rdparty/libprocess/src/memory_profiler.hpp PRE-CREATION > 3rdparty/libprocess/src/memory_profiler.cpp PRE-CREATION > 3rdparty/libprocess/src/process.cpp > 9eb37465cd86f408d69f5f98fb76c4f4b93b9acd > CHANGELOG c02d56d6612c432bb079a15fde84cb30d7455971 > > > Diff: https://reviews.apache.org/r/63368/diff/11/ > > > Testing > ------- > > > Thanks, > > Benno Evers > >
