3d ago
RAM usage @ Frog - permanent 100%
Checking the Mikrus panel revealed a RAM usage graph from recent days showing that usage started climbing around July 21-22 and stayed pinned at 99-100% from July 22 onward, right up until the failure — a multi-day upward trend, not a momentary spike. This is a pattern closer to a memory leak or an accumulating process than a one-off overload.
After an emergency server restart (via the Mikrus panel, since SSH was unreachable):
free -h showed only ~36MB used out of 1GB — the server was practically empty memory-wise right after the restart.
docker stats showed WriteFreely (~12-15MB) and LinkStack (~60→283MB over the first hour) — LinkStack (specifically the httpd processes inside its container, running Apache in prefork mode) grew the most, but plateaued after about an hour at roughly 283MB / 12 worker processes, with no further growth observed over the following hour.
journalctl -k and dmesg provided no retrospective data from before the restart — kernel logs are volatile in this LXC environment, so it's no longer possible to establish with certainty what exactly caused the RAM to fill up between July 21 and 24.
Conclusion: The post-restart growth and plateau in RAM usage (up to ~324MB over 1.5 hours) looks like normal server startup behavior (Apache building up a pool of worker processes in response to traffic), not a repeat of the multi-day leak. However, given the short observation window (1.5h vs. the earlier ~3-day buildup), the matter cannot be considered definitively closed — hence the decision to roll out persistent monitoring and logging rather than a one-time fix.
In Progress