-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] SaltStack 3006.x file
Function State Execution Performance Degradation
#65450
Comments
Can you provide the |
file
Function State Execution Performance Degradationfile
Function State Execution Performance Degradation
We're using the default fileserver configuration (we don't set anything as far as I'm aware), with no changes between our setup for Here's the
|
The same problem with 3006.4 |
Thanks for the fix - the I've attempted to fix it by explicitly passing through the file client where this is invoked (the |
If you are able to submit a patch that would be great, otherwise I will take a look at it. |
@cianyleow I'm going to take a look at this for 3006.8 |
@dwoz this is where I got to with my patch: cianyleow@7620c4d Hopefully this helps! |
@cianyleow Are you able to verify this patch resolves the issue? |
@dwoz I won't be able to get back to this for a couple of weeks, but I think its conceptually similar to how I patched (I went for a more explicit approach for the use cases I have). |
Fixed in |
Description of the tech debt to be addressed, include links and screenshots
When upgrading to SaltStack
3006.x
, a significant performance regression was identified in state execution, resulting in large increases to execution time for certain state functions.A side-by-side analysis of the same state application between
3005.1
and3006.3
below highlights the performance regression seen:3005.1
Timing3006.3
Timingcmd.run
cmd.wait
file.directory
file.managed
file.serialize
pkg.latest
service.dead
As can be seen in the data, the
file.managed
andfile.serialize
functions are 5-40x slower (on average) after this change, which was traced back to the re-initialization of the file client every time it was required.In particular, this change (#63984), which adjusted object lifecycle management for the
fileclient
, was identified as the initial driver of the performance impact. Coupled with a bug fix (#64113), caching of file client initialisation in thecp
anddefaults
modules as well as thejinja
utils was removed, which accounted for the increased state execution timings seen.For reference, an internal patch was applied to reintroduce file client initialisation caching, and it mitigated the performance impact completely.
Versions Report
Salt:
3006.3
Debian: Bookworm (12)
The text was updated successfully, but these errors were encountered: