-
Notifications
You must be signed in to change notification settings - Fork 844
software/versions endpoint is RAM-heavy #23679
Copy link
Copy link
Closed
Labels
#g-endpoint-opsEndpoint ops product groupEndpoint ops product group:releaseReady to write code. Scheduled in a release. See "Making changes" in handbook.Ready to write code. Scheduled in a release. See "Making changes" in handbook.bugSomething isn't working as documentedSomething isn't working as documented~backendBackend-related issue.Backend-related issue.~released bugThis bug was found in a stable release.This bug was found in a stable release.
Milestone
Metadata
Metadata
Assignees
Labels
#g-endpoint-opsEndpoint ops product groupEndpoint ops product group:releaseReady to write code. Scheduled in a release. See "Making changes" in handbook.Ready to write code. Scheduled in a release. See "Making changes" in handbook.bugSomething isn't working as documentedSomething isn't working as documented~backendBackend-related issue.Backend-related issue.~released bugThis bug was found in a stable release.This bug was found in a stable release.
Fleet version: 4.58.0
💥 Actual behavior
Running
software/versionswith a large number of hosts (e.g. 10k) with a typical amont of software per host is a heavy operation on RAM usage, spiking customer pod RAM usage and potentially causing the environment to OOM.🧑💻 Steps to reproduce
software/versionsendpoint🕯️ More info
Split from #23078, referenced in #22291. This is a lower priority than the hosts list with software listings enabled as the customer's use case can get by with using just that endpoint per current understanding. This endpoint doesn't appear to be DB-heavy, but generates a large response that we need to store and serialize more efficiently if possible.
🛠️ To fix
TBD, but probably involves deduplicating data structures.