-
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
Remote state execution is much slower on 2016.11.1 compared to 2016.3.4 #38758
Comments
@Ch3LL do I need that on master, on minion or on both? |
Adding that on minion did not help. |
I did some profiling and here's what's happening on CPU-heavy state.apply path:
I can give you the whole profile for inspection if you want. |
@bobrik thanks for the profiling information. Before we further troubleshoot this can you try making this change on the master side and seeing if there are performance improvements. That PR was meant to tackle an issue between the the time it takes between hitting "enter" and the master getting a publish command. |
I'm going to setup a test scenario to see if i can't replicate this as well. I think I might possibly be mistaken with the fix for this issue. |
@bobrik okay it looks like I can replicate this and the PR does not fix the issue. I realized when re-reading your issue a litte more careful that this is something on the minion side, because you were querying both minions at the same time. Apologies on that, but I can indeed replicate this and we will need to get this fixed up.
And when removing the source and adding contents to that file state i see about hte same times just as you stated:
So it seems there is indeed an issue with the file state when looking for source. ping @terminalmage any idea on this one? I believe I saw some issues a while back about slow performance with file.maanged on 2016.3 but I cannot find those for the life of me in the issue backlog. But it looks like there was even more of a performance hit in 2016.11.1 |
Nevermind @terminalmage ...@cachedout is gonna take a look |
I think the more pillars (?) you have, the more #37378 will hit you. We have around 500kb of fairly complex structures per minion in this test case. |
I just updated the salt-master and one salt-minion and the highstate to one machine jumped from ~5s to ~140s, yet salt-call on the remote host is still about 5s Doing a Reverting salt-minion to 2016.3.4 i get the old performance back (still with salt-master in 2016.11.1) |
Sad to see the there's no fix in 2016.11.2. |
Same issue here :( EDIT: context is not the problem. But I still see file.maaged being slow with remote file client instead of local. 40-50ms is clearly too much when master is on localhost |
2016.11.2:
2016.11.2 with the following changes (which I am sure will mess up some salt functionality):
Same states applied:
Downgraded to 2016.3.5:
All tests were done on the same master/minion. |
Could any of you please measure any improvements made by applying #39505? Thanks. |
@cachedout, I did a test run for a state with many templates and yuge complex pillar.
Looking forward to upgrading to 2016.11.3 with this patch applied. |
Description of Issue/Question
Master:
Minion on 2016.3.4:
Minion on 2016.11.1:
Setup
Both machines are identical apart from salt minion versions.
Consider the following state:
Both machines have comparable timings with
salt-call
:Timings are dramatically different with
salt
call from master:But they get the same without template:
This gets very bad very quickly: 71s vs 750s for local vs remote mode on 2016.11.1.
Debug logs from minions:
The text was updated successfully, but these errors were encountered: