Raise the memory ceiling again: 768M was still throttling - #53
Merged
Merged
Conversation
With the geo-IP database resident the working set settles near 700 MB. The cgroup recorded 65,912 `high` breaches against the 768M soft limit -- the kernel reclaiming hard, which is the 19 September stall in miniature. Nothing was killed; it just got slow. 2G/3G leaves real room: 477 MB in use afterwards, with high, max and oom all at zero. The host has 12 GB and two sibling services are uncapped. - Document reading memory.events in the unit, since a climbing `high` is the warning that arrives before an outage --- Pages affected: - [MCP Registry](https://ai.mcpharbor.dev/) — the directory this serves. - [Browse MCP servers](https://ai.mcpharbor.dev/servers) — the catalogue. - [MCP Server Optimization](https://ai.mcpharbor.dev/book) — verified healthy after the restart. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #52, which raised the cap from 300M/400M to 768M/1G.
768M was still too tight. With the geo-IP database resident the working set settles near 700 MB, and the cgroup recorded 65,912
highbreaches — the kernel reclaiming hard against the soft limit. That is the 19 September stall in miniature:oom_killstayed at 0, so nothing died, it just got slow.Now 2G/3G. After the restart: 477 MB used,
high 0 max 0 oom 0— no throttling at all, on a 12 GB host where two sibling services are already uncapped.The unit now documents the check, because this counter is the warning an outage gives you for free:
highshould sit at or near zero. A climbinghighmeans reclaim pressure;maxand an outage come next.Pages affected:
🤖 Generated with Claude Code