Purpose: Capture the architecture, basic operation, and recent statistics of my self‑hosted Mastodon setup.
Overview
I run a private Mastodon instance on a cloud based VM (2 CPU cores, 4 GB RAM). In attempt to assure that the service stays reliable, I’ve recently started collecting statistics for the first time.
What I measured
I'm collecting CPU, disk, memory and network data. The server has crashed a couple times on the initial launch. My thought process is that documenting will provide solid data that I can share with anyone interested in the project. As well as providing an idea whether or not to upgrade or downgrade to stay cost efficient.
Current Performance Snapshot of a 24hr window
- CPU is at approx. 12% average, peaked once going over 100% (full core saturation for a short burst).
- Disk I/O is at approx. 20 blocks/s average, peak approx. 320 blocks/s.
- Swap is near zero (not noteworthy to annotate).
- IPv4 traffic is at approx. 40 Mb/s IN average, approx. 66 KB/s OUT average; peak approx. 2.7Mb/s IN, approx. 2 KB/s OUT.
- IPv6 traffic is at approx. 70 KB/s IN average, approx. 2KB/s OUT average; peak approx. 5.5 Mb/s IN, approx. 170 KB/s OUT.
What the numbers tell us
- The instance is performing well overall. The average CPU and disk usage are low and swap is unused.
- The brief CPU spike above 100% indicates a short period of high background activity. Peak only lasted a few seconds and mitigated on its own. The extra headroom that I previously implemented after the last crash possibly helped avoid another accidental shutdown of the service.
- Disk activity remains decent. This suggests media uploads and background jobs are not stressing the storage.
- Inbound traffic is slowly increasing, especially on IPv6. Outbound traffic stayed low, as expected. It's a frontend service that primarily serves content rather than streams large amounts of data.
Why it matters
Reliability: The server never ran out of memory or CPU, so the user experience should have been zero to minimal lag. At least, no users have reported issues.
Scalability: Traffic is increasing, especially on IPv6. This shows that the service can attract new users without a major redesign.
Takeaway
The Mastodon server is operating well with the current build. Lessons learned from issues from my initial launch. The CPU peak is an anomaly that fixed itself. It did not impact the user experience.
What I did next
Added an alert: A simple setting now alerts me if CPU stays > 90% for more than an hour.
I’m hoping that documenting this data set will sharpen my documentation skills for future projects. If you have suggestions on additional metrics to track or ways to strengthen this writeup, please let me know.
Top comments (0)