starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-12 05:20:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Displaying the page of a Prefix with many Child Ranges, IPAdresses and Child Prefix is slow #8668

New Issue
Closed
opened 2025-12-29 20:39:39 +01:00 by adam · 8 comments
adam commented 2025-12-29 20:39:39 +01:00
Owner
Copy Link

Originally created by @reduzent on GitHub (Sep 25, 2023).

NetBox version

v3.6.1

Python version

3.11

Steps to Reproduce

The page ipam/prefixes/13/ on our Netbox instance takes more than 20mins to display und runs into a timout when not increasing timeout values.

The particular prefix counts:

  • Child prefixes: 1851
  • Child IP Adresses: 4524
  • Child Ranges: 3513

For historic reasons, this Prefix is heavily segmented, which explains the large number of child Prefixes and Child Ranges. However, since the page only displays a count for each type, the time to render the page shouldn't grow as such.

There is a related discussion where it appears that we can't do much about it but hope that this going to be addressed in Netbox itself.

Expected Behavior

The page should be rendered within reasonable time.

Observed Behavior

We get a 504 when trying to visit the particular page.

Originally created by @reduzent on GitHub (Sep 25, 2023). ### NetBox version v3.6.1 ### Python version 3.11 ### Steps to Reproduce The page `ipam/prefixes/13/` on our Netbox instance takes more than 20mins to display und runs into a timout when not increasing timeout values. The particular prefix counts: * Child prefixes: 1851 * Child IP Adresses: 4524 * Child Ranges: 3513 For historic reasons, this Prefix is heavily segmented, which explains the large number of child Prefixes and Child Ranges. However, since the page only displays a count for each type, the time to render the page shouldn't grow as such. There is a related [discussion](https://github.com/netbox-community/netbox/discussions/13471) where it appears that we can't do much about it but hope that this going to be addressed in Netbox itself. ### Expected Behavior The page should be rendered within reasonable time. ### Observed Behavior We get a 504 when trying to visit the particular page.
adam added the type: bugstatus: revisions needed labels 2025-12-29 20:39:39 +01:00
adam closed this issue 2025-12-29 20:39:39 +01:00
adam commented 2025-12-29 20:39:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 25, 2023):

We're going to need more information than that if you're asking someone else to help troubleshoot this. Please revise your post above to include detailed instructions that someone else can follow to reproduce the observed behavior, and an accounting of the steps you've taken to rule out your specific deployment as a potential contributor to the poor performance.

@jeremystretch commented on GitHub (Sep 25, 2023): We're going to need more information than that if you're asking someone else to help troubleshoot this. Please revise your post above to include detailed instructions that someone else can follow to reproduce the observed behavior, and an accounting of the steps you've taken to rule out your specific deployment as a potential contributor to the poor performance.
adam commented 2025-12-29 20:39:40 +01:00
Author
Owner
Copy Link

@reduzent commented on GitHub (Sep 26, 2023):

I see. I'll try to recreate the issue in an new empty instance of netbox and will provide a backup of the database. Do you consider this approach sufficiently reproducible?

@reduzent commented on GitHub (Sep 26, 2023): I see. I'll try to recreate the issue in an new empty instance of netbox and will provide a backup of the database. Do you consider this approach sufficiently reproducible?
adam commented 2025-12-29 20:39:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 26, 2023):

That should work. Alternatively, you could share a script that can be used to populate the requisite number and types of objects. Whichever is easiest.

@jeremystretch commented on GitHub (Sep 26, 2023): That should work. Alternatively, you could share a script that can be used to populate the requisite number and types of objects. Whichever is easiest.
adam commented 2025-12-29 20:39:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 5, 2023):

@reduzent have you been able to make any further progress on this?

@jeremystretch commented on GitHub (Oct 5, 2023): @reduzent have you been able to make any further progress on this?
adam commented 2025-12-29 20:39:41 +01:00
Author
Owner
Copy Link

@reduzent commented on GitHub (Oct 9, 2023):

No, I hadn't found time yet to dedicate for this, but I plan to do so in the coming weeks.

@reduzent commented on GitHub (Oct 9, 2023): No, I hadn't found time yet to dedicate for this, but I plan to do so in the coming weeks.
adam commented 2025-12-29 20:39:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 12, 2023):

Ok, I'm going to close this out for now. Please follow up with reproduction steps when you're able, and I can re-open the issue.

@jeremystretch commented on GitHub (Oct 12, 2023): Ok, I'm going to close this out for now. Please follow up with reproduction steps when you're able, and I can re-open the issue.
adam commented 2025-12-29 20:39:42 +01:00
Author
Owner
Copy Link

@reduzent commented on GitHub (Dec 6, 2023):

Ok. I found some time to create a separate test environment where I could specifically create objects for testing the issue. My test system is a Debian 12 VM (VMware VM) with netbox 3.6.6. The system has two CPU cores and 4 GB Memory. Initial state is an empty database.

I can trigger the 504 Gateway Time-out (nginx error) when I create a prefix with 1000 child prefixes where each child prefix has one child range.

This is how I create the objects in nbshell:

mainpref = Prefix(prefix='10.128.0.0/11', status='active')
mainpref.full_clean
mainpref.save()

mainpref = Prefix.objects.filter(prefix='10.128.0.0/11')[0]

prefsize = 256
prefcount = 1000

for i in range(0, prefcount*prefsize, prefsize):
    newpref = Prefix(prefix=mainpref.prefix[i].format() + '/24', status='active')
    newpref.full_clean()
    newpref.save()

for cpref in mainpref.get_child_prefixes():
    newrange = IPRange(start_address=cpref.prefix[100].format() + '/24' , end_address=cpref.prefix[250].format() + '/24' , status='active')
    newrange.full_clean()
    newrange.save()

If you apply this to a new installation, this URL triggers the timeout:

/ipam/prefixes/1/

Or click the result of this search:

/ipam/prefixes/?q=10.128.0.0%2F11

I hope this is enough information for you to reproduce the issue.

@reduzent commented on GitHub (Dec 6, 2023): Ok. I found some time to create a separate test environment where I could specifically create objects for testing the issue. My test system is a Debian 12 VM (VMware VM) with netbox 3.6.6. The system has two CPU cores and 4 GB Memory. Initial state is an empty database. I can trigger the `504 Gateway Time-out` (nginx error) when I create a prefix with 1000 child prefixes where each child prefix has one child range. This is how I create the objects in nbshell: ``` mainpref = Prefix(prefix='10.128.0.0/11', status='active') mainpref.full_clean mainpref.save() mainpref = Prefix.objects.filter(prefix='10.128.0.0/11')[0] prefsize = 256 prefcount = 1000 for i in range(0, prefcount*prefsize, prefsize): newpref = Prefix(prefix=mainpref.prefix[i].format() + '/24', status='active') newpref.full_clean() newpref.save() for cpref in mainpref.get_child_prefixes(): newrange = IPRange(start_address=cpref.prefix[100].format() + '/24' , end_address=cpref.prefix[250].format() + '/24' , status='active') newrange.full_clean() newrange.save() ``` If you apply this to a new installation, this URL triggers the timeout: ``` /ipam/prefixes/1/ ``` Or click the result of this search: ``` /ipam/prefixes/?q=10.128.0.0%2F11 ```` I hope this is enough information for you to reproduce the issue.
adam commented 2025-12-29 20:39:42 +01:00
Author
Owner
Copy Link

@reduzent commented on GitHub (Dec 11, 2023):

@jeremystretch should I open a new issue about this? Or can you re-open this issue?

@reduzent commented on GitHub (Dec 11, 2023): @jeremystretch should I open a new issue about this? Or can you re-open this issue?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: revisions needed type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#8668
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?