Skip to content
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

Custom Script initialisation via API requests full execution history of that script for no obvious reason #17333

Closed
pgnuta opened this issue Aug 31, 2024 · 4 comments · Fixed by #17373
Assignees
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@pgnuta
Copy link
Contributor

pgnuta commented Aug 31, 2024

Deployment Type

Self-hosted

NetBox Version

v4.0.10

Python Version

3.12

Steps to Reproduce

  1. Have 300,000+ execution history records for one particular custom script (2000+ executions per hour).
  2. Have an architecture that includes a database server not hosted on the same host as the netbox process.
  3. Initialise a new execution of that custom script via an API call.
  4. Observe that the API call HTTP response takes 20+ seconds to return.

Expected Behavior

The script execution job should be added to the background queues list faster than it is.

Observed Behavior

When the API call is first received by netbox it performs an SQL query requesting the entire execution history for that script:

2024-08-31 23:23:46.694 NZST [23469] netbox_test LOG: statement: SELECT "core_job"."id", "core_job"."object_type_id", "core_job"."object_id", "core_job"."name", "core_job"."created", "core_job"."scheduled", "core_job"."interval", "core_job"."started", "core_job"."completed", "core_job"."user_id", "core_job"."status", "core_job"."data", "core_job"."error", "core_job"."job_id" FROM "core_job" WHERE ("core_job"."object_type_id" = 69 AND "core_job"."object_id" IN (2)) ORDER BY "core_job"."created" DESC

This query takes a long time to transfer the volume of data in the table due to the size of the execution history and it waits for this to finish before the job is inserted into the table:

2024-08-31 23:24:06.992 NZST [23469] netbox_test LOG: statement: INSERT INTO "core_job" ("object_type_id", "object_id", "name", "created", "scheduled", "interval", "started", "completed", "user_id", "status", "data", "error", "job_id") VALUES (69, 2, 'SyncLibrenms', '2024-08-31 11:24:06.972273+00:00'::timestamptz, NULL, NULL, NULL, NULL, 1, 'pending', NULL, '', '7667384535e94785b75acb525133e6c5'::uuid) RETURNING "core_job"."id"

As far as i can tell there is no reason to perform this query as it is not performed when initialising a custom script execution through the frontend.

@pgnuta pgnuta added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Aug 31, 2024
@pgnuta
Copy link
Contributor Author

pgnuta commented Aug 31, 2024

Just a followup:

  • Yes i know that 300k+ executions in the history table is a lot, retention has been shortened from 90 days to 5 days as a workaround while we resolve this.
  • The issue is that when a lot of these scripts are fired off by external systems hitting the API at random they consume a uwsgi/gunicorn worker for 20+ seconds and the whole application grinds to a halt.

@arthanson arthanson added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation severity: low Does not significantly disrupt application functionality, or a workaround is available and removed status: needs triage This issue is awaiting triage by a maintainer labels Sep 3, 2024
@arthanson arthanson self-assigned this Sep 4, 2024
@arthanson arthanson added status: accepted This issue has been accepted for implementation and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation labels Sep 4, 2024
@arthanson
Copy link
Collaborator

@pgnuta can you please try the PR #17373 (Note: On NetBox 4.1.0) please let me know if that resolves the issue for you.

@arthanson
Copy link
Collaborator

@pgnuta ?

@pgnuta
Copy link
Contributor Author

pgnuta commented Sep 11, 2024

@arthanson. I have tested the PR and it has resolved the issue, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants