Closed alexec closed 11 months ago
For posterity, from this comment: https://github.com/argoproj/argo-workflows/pull/11928#issuecomment-1754122835. It was an incidental finding here: https://github.com/argoproj/argo-workflows/pull/11928#issuecomment-1743703111.
Perhaps it is in the watch?
In JS-land and Docker/VM-land in years past, watchers were definitely a common area of inefficiencies (partially due to implementation differences across OSes and FSes etc), so I wouldn't be surprised by that, especially as it seems to get worse with code changes.
So I did some tracing on this incidental finding and it seems like this is more likely a memory leak with Webpack (which would be less surprising too). The only strange part is that it seems to behave slightly differently based on its parent process for some reason 🤔
From the Workflows devcontainer
:
Webpack will continuously go up in memory usage and rarely go down. Its CPU can be very spiky on a reload as well (jumping by 100% CPU sometimes). kit
remains fairly stable throughout, though at ~1.7% CPU, it is one of the higher utilization processes.
When I run Webpack standalone, outside of kit
, here's what it looks like:
It seemed like the floor of the CPU is lower when it is standalone. kit
is also using less than half of its memory and a third of CPU when not the parent of Webpack. (or not the parent of yarn start
, which is the parent of Webpack, to be specific)
So it seems like the memory leak is with Webpack, but kit
perhaps exacerbates it somehow by also using more resources? and perhaps having some effect on reaping? Not really sure how this interaction works, it's quite strange to see different behavior due to a parent process; I can't make heads or tails of it
Left kit
on for longer as a parent and the floor did drop relatively equivalently. The only observation that adds up for why my fans are running louder / more frequently when using kit
is b/c kit
's own CPU when it is the parent of Webpack can be substantially higher, so it has some (fairly small) bit of duplicative effect on total CPU usage.
kit
's CPU did drop quite substantially throughout the run as well. It started at 5.0%
, then dropped to 2.0%
, then 1.6%
, and eventually to 0.7%
.
(Also yes, a timeseries graph would be great to see of this, but this is all local, not running on a server producing metrics somewhere 😅 need a tool that can run locally, do a long timespan (10min+), and drill down individual processes)
In any case, this is not a memory leak in kit
, so this can be closed (I can't close it myself as I didn't open it). There may be some CPU wonkiness to watch out for though, particularly when kit
is a parent of other spiky or CPU-heavy processes.
There aren't too many places there could be a memory leak. Perhaps it is in the watch?