On 2019.07.30 14:00, Jeff Hostetler wrote:

On 7/29/2019 6:20 PM, Josh Steadmon wrote:

quoted

trace2 can write files into a target directory. With heavy usage, this
directory can fill up with files, causing difficulty for
trace-processing systems.

I'm routing data in my org to a daemon via a Named Pipe or UD Socket,
so I'm not seeing the thousands of files problems that you're seeing.
However, we were being overwhelmed with lots of "uninteresting" commands
and so I added some whitelisting to my post-processing daemon.  For
example, I want to know about checkout and push times -- I really don't
care about rev-parse or config times or other such minor commands.

I went one step further and allow either "(cmd_name)" or
the pair "(cmd_name, cmd_mode)".  This lets me select all checkouts
and limit checkouts to branch-changing ones, for example.  I drop
any events in my post-processor that does not match any of my whitelist
patterns.

Perhaps you could run a quick histogram and see if something would
be useful to pre-filter the data.  That is, if we had whitelisting
within git.exe itself, would you still have too much data and/or
would you still need the overload feature that you've proposed in
this RFC?

Our problem is not so much with the volume of data as the fact that a
few special users have a ton of git invocations in rapid succession,
each of which creates a new trace file. If we had a more synchronous
collection system like yours it would probably not be so much of a
challenge. But the massive number of files created in a short timeframe
revealed some inefficiencies in our collection system (which are
thankfully being addressed by the owners of that code). But we probably
still want some sort of overload prevention feature as long as we're
using the target directory approach.