https://pantsbuild.org/ logo
Join Slack
Powered by
<@UB2J9BQA0>: it's applying the concurrency constr...
# development
w
@hundreds-father-404: it's applying the concurrency constraint: can see it in 
top -o cpu
locally
The concurrency constraint just only actually applies to process invokes: not 
@rules
h
Hm wouldn’t that lead to too much memory usage? Each rule invocation for Pytest for example has to store 
all_targets
in memory. Even if subprocess are limited, you could feasibly have to store over 400 of those variables in memory at a given time, right?
w
all_targets is a list containing n pointers to the same objects
Holding it for only the roots should be fine (you don't want to hold it for the transitive graph though)
h
We do hold in memory all transitive deps. We have to do that per https://github.com/pantsbuild/pants/pull/7720 Regardless though of what the list holds, my point is that the principle of not limiting # of rule invokes seems to be a risk for memory shortages. Each rule invoke is non-trivial in memory usage. Given enough concurrent rule invokes, as a principal you are bound to hit memory shortages like we’re seeing in CI. Further, some systems have more memory than others. Ideally we would not be sensitive to the amount of memory available
w
./pants list ::
in Twitter's repo results in ~500k rule invokes and nodes in the graph
And it takes less memory than running the unit tests in pantsbuild/pants with v2 right now
So: I suspect that the culprit is not the rules themselves, but rather what is being held by them.
I don't have a good pointer for tracking it down tonight, but can take a look tomorrow.
I get your point about capping concurrently executing rules: I just suspect that that is not the issue in this case.
h
Okay sounds good. I’m afk all night so no worries. Cc @average-vr-56795 if you have any ideas for how to investigate / profile what’s going on.
w
regarding this issue: one thing that is potentially peculiar is that after applying all of the outstanding patches, even for running a single target, 
--native-engine-visualize-to
ends up spending a huge amount of time in 
__repr__
... ie, i think that there might be some very large things
@hundreds-father-404: would suggest comparing/contrasting a tiny test run before/after
also, using https://github.com/benfred/py-spy to attach is very helpful
👍 1
h
Before and after all the patches?
w
um, the potentially relevant ones?
or each of them? could bisect?
👍 1
after a run with 
--native-image-visualize-to
, i change into the relevant directory and then do:
Copy code
export DOTFILE=graph.000.dot; dot -Tpdf -O "${DOTFILE}" && open "${DOTFILE}.pdf"
to view as PDF
👌 1
but make sure it is a small usecase, because the result is large regardless
h
@witty-crayon-22786 how would I hook up Pyspy to 
./pants
? We don’t directly call 
python3.6 my_program.py
w
sudo py-spy --pid $pid
👌 1
any luck here?
h
Only now getting into it. Was making breakfast and taking a break
w
whoops, sorry.
Open in Slack
PreviousNext
Powered by