-
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
salt 2018.3.2 py3 on Ubuntu 18.04 takes a long time to run test.true #48773
Comments
i am not seeing >5 seconds when I attempt to replicate i'm seeing about 3 seconds, but still longer then we want. I believe you are right I believe the culprit is the ping @saltstack/team-cloud is there a reason we are using this decorator instead of handling the dependencies in virtual? |
@Depends allows for using some functions inside of a module when others cant be used.
For example, lets say part of a module uses a commandline utility, and the other functions actually use the imported library. and then lets say that you can only pip install the python package on 2.7, 3.5 and 3.6, centos 7 uses python3.4, so you can never install for 3.4, so the stuff using the imported library cannot be used, but the stuff that can still use the command line utility can still be used if you just pip install it on 2.7. That is why we use @Depends and @salt.utils.decorators.path.which. Both of these are resolved at the load time though, so it should not affect already loaded modules, just the first time they are loaded for an instance. which is why it affects salt-call. |
We are also seeing this problem and its causing us some grief. Although
only adds 6-7 seconds to every state run, some of our orchestrations are taking 10 minutes to execute instead of 2 minutes because all that overhead adds up. @gtmanfred I don't quite understand your point about python versions, but if our environment is tightly controlled to use only a single python version, is there any workaround to avoid the poor performance behaviour? |
After I configured
, it runs a little bit faster, but still quite slow. I can still see @Depends in the trace. It seems |
Sure, you may only use one python version, but we are supporting several. |
How long does it take to run when you run the |
There's no difference if I run |
@kartiksubbarao Could you try undocumented
|
@max-arnold That definitely helps. I ran a comparison just now, it cuts down the runtime from 6 seconds to 1.7 seconds. |
FYI; I have had the same slowness issues on multiple FreeBSD 11.2 machines with salt 2019.2.0. Adding disabled_grains & disabled_modules (both vsphare and esxi* as from examples above) gave great performance boost in running pretty simple states, with a total execution time from ~15-30s down to ~3s for 2 local hosts. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue. |
I don't think this should've been closed. The issue still exists in the latest release. |
I opened #57062 to fix this for good. |
Some very good background can be found on StackOverflow: * https://stackoverflow.com/questions/17407119/python-inspect-stack-is-slow I filed an issue about slow `inspect.stack()` in Python some time ago: * https://bugs.python.org/issue39643 Slow `inspect.stack()` is a problem, but it's not the problem in this case. The problem is that Salt asks Python to get a full blown stack with all the frames, but then discards everything but the second frame from the top. This is very wasteful, and it's much more economic to ask for the current frame and walk back once. Here's how long it takes to run `test.ping` with existing code: ``` $ time sudo salt-call --local test.ping local: True real 0m12.166s user 0m11.679s sys 0m0.499s ``` And this is how much better it gets with the proposed change: ``` $ time sudo salt-call --local test.ping local: True real 0m2.092s user 0m1.772s sys 0m0.336s ``` If you follow the advice from #48773 and disable `vmware` module, which is responsible for the most calls into inspect module, you won't get much better than that: ``` $ cat /etc/salt/minion disable_grains: - esxi disable_modules: - vsphere $ time sudo salt-call --local test.ping local: True real 0m2.006s user 0m1.671s sys 0m0.353s ``` Closes #48773.
saltstack/salt#48773 is meanwhile closed, there was an additional feature added to salt [1] and we face problems with our mine (which is mostly based on grains). So lets try to remove this option and see if our mine behaves better after that. [1] saltstack/salt#57062
I'm running salt 2018.3.2+ds-1 with python 3 on Ubuntu 18.04, and am finding that it takes over 5 seconds to run
salt-call --local test.true
. If I use--skip-grains
, it cuts the time down to 1 second (which is still somewhat slower than expected). While searching around I came across #26255, but in my case the number of file descriptors isn't the issue -- setting ulimit -n 1024 doesn't fix it. Here's the output from both runs. The numerousDepends decorator instantiated...
messages seem to chew up most of the time.time salt-call --local test.true -l trace
time salt-call --local --skip-grains test.true -l trace
Versions Report
The text was updated successfully, but these errors were encountered: