Capacity planning is deciding what you need before you need it. On a server that means knowing which resource you will run out of first, roughly when, and what you will do about it, rather than discovering all three during your busiest week.
Find your current ceiling
Not the specification. The point at which performance degrades.
Those are different numbers. A server with 32 GB of memory does not perform well at 31 GB used, and CPU at 90% is already producing waiting.
Load-test at a quiet time and find where response times start climbing. That figure is your real capacity, and it is usually well below the specification.
Then check which resource hit its limit first. It is rarely the one people watch. For the commands, see Monitoring Performance and Server Health.
Establish a baseline while things are normal
You cannot tell that usage has changed without knowing what it was.
Record a normal week: CPU, memory, disk usage and growth, and concurrent requests at peak. Keep it somewhere you will find it.
Then the question "is this unusual?" has an answer, and a gradual change is visible as a trend rather than as a surprise. Most capacity problems announce themselves for weeks before they arrive.
Disk is the predictable one, and it stops everything
Disk fills at a rate you can measure and project, which makes it the easiest to plan for and the most embarrassing to be caught by.
It is also the one that fails hardest: a full disk breaks mail, uploads, database writes and sessions at once, and none of the errors mention disk. For the usual cause, see managing logs.
Measure the growth per week, divide the free space by it, and you have a date. Set an alert at 80% and act at the alert rather than at the date.
Memory does not degrade gracefully
CPU pressure makes things slower. Memory exhaustion makes the kernel kill a process, and it chooses the largest, which is the database.
So a server at 95% memory is not "nearly at capacity" in the way a server at 95% CPU is. It is one traffic increase away from an outage.
Plan more headroom on memory than on anything else, and make sure swap exists so the failure is slowness rather than a killed database. Configuring swap and memory goes into it.
Concurrency is usually the real limit
Averages hide it. A server averaging 20% CPU can be at its limit during the busiest ten minutes of the day, and monthly graphs will never show that.
The number that matters is how many requests you can serve simultaneously before they queue. The symptom of exceeding it is a site that hangs and then loads, not one that errors, which is why it gets misdiagnosed as slow code. Handling a traffic spike walks through the distinction.
Look at peaks, not means. Graph at a resolution that shows a busy hour.
Optimise before you scale, and know when to stop
Caching typically multiplies the traffic a server handles, at no recurring cost. Sizing images properly removes bandwidth and time. Both beat a bigger server on value.
What matters is knowing when that argument stops applying. When caching is working, the database has indexes, and the server is still at its ceiling during ordinary traffic. That is a genuine capacity limit, and continuing to optimise is effort spent on the wrong thing.
The test is whether measurements are still moving. Several changes with no measurable effect means the limit is elsewhere. There is more on the sequence in speeding up a website in the right order.
Up or out
Scaling up: a bigger server, is simpler and has a ceiling. It means a migration and some downtime, and it is the right answer for most single-site growth.
Scaling out (more servers) has no ceiling and changes the architecture. Sessions must be shared, uploads must live somewhere both servers see, and the database becomes a separate concern.
Most businesses never need to scale out. What is worth doing early is not making it impossible: keep sessions and uploads out of assumptions about a single machine, so the option exists later.
Know how long a change takes
The part that turns a plan into something usable.
Adding memory is a reboot in a scheduled window. Adding disks depends on free bays, worth checking before you need to know. A new server is procurement, provisioning and a migration, and that is weeks rather than hours.
Work backwards from the lead time. If a new server takes three weeks, your decision point is three weeks before the ceiling, not at it. Choosing server hardware walks through specifying the replacement.
Plan for what you know is coming
Seasonal peaks, campaigns, launches, a client whose site is growing.
Those are the capacity events you can predict, and they are the ones people prepare for last. A shop's busiest fortnight is on the calendar all year. For the shop side, see preparing for a sales peak.
Review it quarterly
Open the baseline, compare it to now, and update the projection.
Fifteen minutes, four times a year, and it converts capacity from something you react to into something you decide. The alternative is an upgrade under pressure, chosen badly, during the week it was needed.
Work out which limit you reach first
Capacity planning fails when it treats the machine as one number, because only one resource runs out first and it is rarely the one people watch.
free -m | awk '/Mem:/ {printf "bellek %d%%\n", $3*100/$2}'
df -h / | awk 'NR==2 {print "disk", $5}'
uptime | grep -o 'load average.*'
ss -tn state established | wc -l
Record all four weekly and look at which one is approaching its ceiling fastest. That is the constraint, and it is the only one worth spending money on.
Growth is rarely linear across them. Storage grows steadily, memory grows in steps as software is added, and concurrency jumps with traffic. A plan based on the average of the four buys the wrong thing.
Know what a change costs in time, not only money
The decision to scale is usually made under pressure, and the useful preparation is knowing in advance how long each option takes.
Adding memory to a virtual machine may be minutes with a reboot. Moving to a larger machine is a migration measured in hours. Splitting an application across two machines is a project measured in weeks, because the application has to be ready for it.
du -sh /home 2>/dev/null; find /home -xdev 2>/dev/null | wc -l
The file count is what determines how long a copy takes, and it is the figure nobody has when the decision is being made. Measuring it while everything is calm turns the eventual choice into a comparison rather than a guess.