Bug #12425
closed![Author: Anonymous](/images/anonymous.png?1697023634)
Fact import triggers ip conflicts checks, which drives cpu utilization to 100% on smart-proxy
Description
This is an expensive call, and performing lots of them has a serious impact on smart-proxy. See http://projects.theforeman.org/issues/12392 for more details and discussion.
Updated by Anonymous almost 9 years ago
- Related to Bug #12392: 100% cpu usage on foreman-proxy DHCP calls added
Updated by Dominic Cleal almost 9 years ago
From #12392, Dmitri says:
It might be possible to set some flag indicating that fact import is in progress, but it's going to be messy.
When saving hosts during fact/report importing we use .save(:validate => false)
- not really in an attempt to disable validation, but to disable orchestration (as I understand it). The same isn't done for saving network interfaces, and now that orchestration's in those models, it's running.
If we had a flag to disable orchestration generally instead of disabling validation, we might be able to keep validation on NICs (something we really shouldn't go backwards on by disabling) while disabling orchestration changes at a high level?
Updated by Toni Schmidbauer over 8 years ago
setting ignore_puppet_facts_for_provisioning to true resolved this issue for us.
Updated by Timo Goebel over 8 years ago
Makes this worse as Foreman now does two calls to smart-proxy during fact import effectively doubling the load.
Updated by The Foreman Bot over 8 years ago
- Status changed from New to Ready For Testing
- Assignee set to Timo Goebel
- Pull request https://github.com/theforeman/foreman/pull/3471 added
Updated by Anonymous over 8 years ago
If you are using ISC dhcpd, I would suggest testing import against changes in https://github.com/theforeman/smart-proxy/pull/409, calls to smart-proxy's dhcp module (when used with ISC dhcpd) no longer incur heavy penalty.
Updated by Dominic Cleal over 8 years ago
- Related to Bug #13725: Orchestration fails with 409 when there is a MAC DHCP conflict added
Updated by Anonymous over 8 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 5351c86f9e066fdfae8687e512d35c1fe3e4336f.
Updated by Dominic Cleal over 8 years ago
- Translation missing: en.field_release set to 136
Updated by Lukas Zapletal over 4 years ago
- Related to Bug #15306: Orchestration does not roll back queued actions if DB error occurs added
Updated by Lukas Zapletal over 4 years ago
- Triaged set to No
The misbehavior was re-introduced by #15306 fyi. If that's important to you, check it.
Updated by Lukas Zapletal over 4 years ago
Oh I take it back, it resolves the issue.