Capacity planning is the process of predicting when your computer systems will run out of resources (like memory, disk space, or processing power) and deciding what to do about it before they fail. It matters for LPIC-2 because you must prove you can monitor systems, analyse trends, and plan upgrades so that a company’s critical services never slow down or crash.
Jump to a section
A simple way to picture Capacity Planning and System Resources
A restaurant kitchen is the heart of a busy bistro. It has a limited number of stoves, fridges, and counter space. The head chef must constantly monitor how many orders are coming in and whether the kitchen can handle the rush. This is capacity planning: knowing the maximum number of meals the kitchen can produce per hour (its capacity) without burning food or running out of ingredients.
If the bistro suddenly gets a flood of customers from a glowing review, the chef must decide: do we refuse orders (reject connections), ask customers to wait longer (increase queue depth), or hire another cook and add a portable stove (scale up resources)? The chef tracks the rate of orders per minute (throughput), the time a ticket sits before cooking starts (latency), and how often the fryer is empty (resource utilisation). Choosing to add a stove only for the weekend rush is elastic scaling — paying for extra capacity only when needed.
The restaurant’s owner regularly reviews the reservation book and past weekend data to predict how many stoves and cooks will be needed next month. This is forecasting: using historical trends to plan future capacity. Without this, the restaurant either wastes money on idle stoves or collapses under demand.
Capacity planning is the discipline of ensuring that a computer system has enough resources to handle its current and future workload without wasting money on resources it does not need. On the LPIC-2 exam, this objective covers three core activities: measuring current usage, predicting future usage, and deciding when and how to add more capacity.
First, you must understand the resources. The main resources on a Linux server are:
CPU (Central Processing Unit): the brain of the server that executes instructions. Measured as a percentage of utilisation or as load average (the number of processes waiting to run).
Memory (RAM): short-term storage for running programs. If you run out, the system uses swap space on the hard drive, which is extremely slow.
Disk space: permanent storage for files, logs, and databases. Running out can crash the entire system.
Disk I/O (Input/Output): the speed at which data can be read from or written to the disk. Slow I/O makes everything feel sluggish.
Network bandwidth: the amount of data that can be sent or received per second. Saturation leads to packet loss and timeouts.
Inodes: a finite number of file index entries on a filesystem. You can have free disk space but zero inodes left, which prevents creating any new file.
You measure these resources using standard Linux tools. The ‘top’ command shows real-time CPU and memory usage. The ‘free’ command shows used and available RAM. The ‘df’ command shows disk space, and the ‘df -i’ command shows inode usage. The ‘iostat’ tool reports disk I/O statistics. The ‘sar’ (System Activity Reporter) tool collects and reports historical data, which is crucial for spotting trends.
Why does this matter? Imagine a web server that normally serves 1,000 visitors per hour. Over six months, traffic grows to 5,000 visitors per hour. Without capacity planning, the server’s CPU hits 100%, response times soar to 30 seconds, and customers leave. With capacity planning, you notice the trend in ‘sar’ data, predict that in three months the CPU will be saturated, and add a second web server or upgrade the CPU before the problem occurs.
Forecasting is the next piece. You take historical data — for example, CPU usage recorded every hour for the past year — and project it forward. Simple methods include linear projection (draw a straight line through the trend) or using moving averages. The key metric is the growth rate: if disk usage grows 5% per month, disk will be full in 20 months. You calculate the “time to exhaustion” and set an alert for 90% usage so you have lead time to buy and install a new disk.
Elasticity is a modern twist. In cloud environments (like Amazon EC2 or Microsoft Azure), you can add or remove resources automatically based on demand. This is called elastic scaling. For example, you configure a rule: if CPU exceeds 80% for five minutes, launch a second server instance. This avoids over-paying for idle capacity while still handling spikes. However, the LPIC-2 exam also tests traditional on-premise planning where you must buy hardware in advance.
Finally, capacity planning is not a one-time task. It is a continuous cycle: measure, analyse, forecast, plan, implement, and then measure again. The output is a capacity plan document that lists current utilisation, growth trends, projected exhaustion dates, and recommended actions (e.g., “add 2 TB of disk by August”).
The exam expects you to know the tools, understand the metrics (utilisation, saturation, errors), and be able to interpret ‘sar’ output, ‘vmstat’, and ‘iostat’ reports. You must also understand the difference between scaling up (making a single server more powerful) and scaling out (adding more servers to a group).
Baseline Measurement
Install the sysstat package and configure sar to collect data every 10 minutes. Run the system for a week to capture normal usage patterns. Use commands like 'sar -u' to log CPU, 'sar -r' for memory, and 'sar -b' for disk I/O. This step gives you a baseline — the typical usage range for each resource.
Identify Critical Resources
Analyse the baseline data to find which resources are closest to their limits. For example, if disk I/O wait time (%iowait) is consistently above 10%, disk is a bottleneck. If CPU during peak hours is 80%, focus on that. Prioritising the most constrained resource ensures you spend effort where it matters most.
Calculate Growth Rate
Extract usage data for the critical resource over a period of at least three months. For disk space, collect 'df' output monthly. Calculate the average monthly increase (e.g., 5 GB per month). For CPU, compute the percentage increase in peak utilisation per month. This growth rate is the foundation for your forecast.
Forecast Exhaustion Date
Divide the remaining capacity by the monthly growth rate to find the number of months until the resource is depleted. For disk: if 100 GB is used and 50 GB remains, with 5 GB growth per month, exhaustion occurs in 10 months. Set an alert at 80% utilisation to give yourself a buffer (e.g., alert when 80% used, leaving 20% for unexpected spikes).
Develop and Implement a Plan
Write a capacity plan document stating the current state, growth trend, exhaustion date, and recommended action. Options include scaling up (upgrade hardware), scaling out (add servers), or reducing demand (compress logs, add cache). Schedule the implementation (e.g., during a maintenance window) and update the baseline afterwards.
Review and Repeat
After implementing the plan, continue monitoring with sar. Update your baseline and recalculate growth rates quarterly. Check that the new capacity is not being consumed faster than expected. If the problem recurs earlier than predicted, investigate unexpected growth (new application, changed user behaviour). This cycle never ends.
An IT professional uses capacity planning constantly to prevent system outages. Consider a medium-sized e-commerce company that runs its website on a single Linux server. The IT administrator, let us call her Priya, is responsible for keeping the site fast and available, especially during the Black Friday sale.
Priya starts by installing the ‘sysstat’ package to collect performance data with ‘sar’. She configures it to record CPU, memory, disk, and network utilisation every 10 minutes. After a week, she uses ‘sar -u’ to view CPU usage over time. She sees that CPU utilisation averages 30% during normal days but spikes to 90% during the lunch hour when employees browse the site. This is a baseline — the normal pattern.
Next, Priya looks at disk space using ‘df -h’. She notices that the log files in /var/log are growing by 2 GB per week. At that rate, the 100 GB partition will be full in 50 weeks. She sets up a log rotation job (logrotate) to compress and delete old logs, reducing the growth rate to 0.5 GB per week. This proactive step extends the disk’s life by nine months.
Priya then builds a forecast. She exports ‘sar’ data to a spreadsheet and graphs the monthly average CPU usage. The trend line shows a 5% increase per month. She calculates that in six months, the lunch-hour CPU usage will hit 100% and the site will slow down. She presents this to her manager with two options:
Scale up: upgrade the server to a more powerful CPU and add more RAM. Cost: $5,000 one-time, downtime of two hours for migration.
Scale out: add a second web server behind a load balancer. Cost: $2,000 per month ongoing plus additional software licensing.
They choose to scale up because it is simpler and they have room in the server chassis. Priya schedules the upgrade for a Sunday morning at 3 AM to minimise disruption. After the upgrade, she monitors ‘sar’ again to confirm that CPU utilisation during peak hours dropped to 40%. She updates her capacity plan document and sets a quarterly review.
During Black Friday, traffic spikes to three times normal. Priya watches ‘sar’ in real-time using ‘pidstat’. The CPU hits 80% but stays below critical. She knew from her capacity plan that the upgrade gave her a 150% headroom, so the site stays fast. If she had not planned, the server would have crashed, costing the company thousands in lost sales.
The tools Priya uses in this scenario are: - sar: for historical performance data collection and reporting - df and du: for disk space analysis - top and htop: for real-time monitoring - iostat: for disk I/O performance - vmstat: for virtual memory and process statistics - nload or iftop: for real-time network usage
This real-world workflow shows that capacity planning is not a one-off task but a continuous cycle of measuring, analysing, forecasting, and acting.
The LPIC-2 exam objective 200.1 (Capacity Planning) tests your ability to measure, analyse, and predict system resource usage. The exam will not ask you to diagnose a live system — it tests your knowledge of commands, metrics, and concepts through multiple-choice questions.
Key concepts the exam loves to test:
The difference between utilisation (how much of a resource is in use) and saturation (how much extra work is queued because the resource is full). For example, CPU utilisation at 90% is high, but a load average of 8 on a 4-core CPU indicates severe saturation.
The meaning of ‘sar’ output fields. You may see a sample ‘sar -u’ report and be asked what the ‘%idle’ column means (it is the percentage of time the CPU was idle with no I/O wait).
How to calculate growth rates. They may give you disk usage values over three months and ask you to project the exhaustion date. Practice linear interpolation: if usage grew 10 GB in 30 days, it will grow 10 GB every 30 days.
The difference between scaling up (vertical scaling: bigger CPU, more RAM) and scaling out (horizontal scaling: adding more servers). They may present a scenario and ask which approach is more appropriate.
Common exam traps:
Confusing ‘free’ memory with ‘available’ memory. The ‘free’ command shows ‘buff/cache’ memory as used, but that memory is reclaimable by applications. The true available memory includes that cache. The exam expects you to know that available memory = free + buff/cache (in most contexts).
Thinking that 100% CPU utilisation is always bad. It is normal if the system is doing productive work within limits. The problem is when utilisation stays at 100% and the load average exceeds the number of CPU cores.
Forgetting about inodes. A classic trick: a question describes a full filesystem, but ‘df -h’ shows free space. The answer is ‘df -i’ to check inodes.
Misreading ‘sar’ data headers. The columns ‘%user’, ‘%nice’, ‘%system’, ‘%iowait’, ‘%steal’ are each a specific type of CPU time. The exam may ask what ‘%iowait’ represents: time the CPU was idle while the system was waiting for a disk I/O operation to complete.
Exam topic areas you must memorise:
The complete list of commands for monitoring: sar, iostat, vmstat, pidstat, mpstat, free, df, du, top, nload
The ‘sysstat’ package: it provides ‘sar’, ‘sadc’ (data collector), and ‘sa1/sa2’ scripts. Know that historical data is stored in /var/log/sa/ directory as ‘saDD’ files (where DD is the day of the month).
How to generate a report from stored ‘sar’ data: ‘sar -f /var/log/sa/sa22’ to view data from the 22nd day of the month.
The concept of “capacity management” vs “performance tuning”: capacity management is about planning for future demand; performance tuning is about making the existing hardware run faster. The exam focuses on capacity management.
The four steps of capacity planning: measurement, analysis, forecasting, and implementation.
Expect 3-5 questions on this objective. They often combine ‘sar’ output interpretation with a growth rate calculation. For example: “January disk usage is 200 GB, June usage is 350 GB. At what month will disk usage exceed 500 GB?” You calculate the monthly growth rate (150 GB / 5 months = 30 GB per month) and project: 500 GB - 350 GB = 150 GB remaining, which will be consumed in 150 / 30 = 5 months after June, so November.
Capacity planning is the proactive process of monitoring resource usage, forecasting future demand, and scheduling upgrades before systems fail.
The four critical resources to monitor on a Linux system are CPU, memory, disk space, and disk I/O — plus inodes and network bandwidth as secondary but essential metrics.
The 'sar' command from the sysstat package is the primary tool for collecting and reviewing historical performance data, stored in /var/log/sa/saDD files.
A CPU utilisation of 100% is not a problem if the load average matches the number of CPU cores; saturation is indicated by a load average significantly exceeding core count.
The 'available' memory column in the 'free' command includes reclaimable cache and is a better indicator of true free memory than the 'free' column alone.
Scaling up (bigger single server) and scaling out (multiple servers) are two distinct strategies — scaling out provides redundancy and better fault tolerance but adds complexity.
To calculate when a resource will be exhausted, find the monthly growth rate from historical data, then divide the remaining capacity by that rate.
A capacity plan should be a living document that is reviewed quarterly and includes current utilisation, growth trends, and specific upgrade recommendations with dates.
The exam tests your ability to interpret 'sar' output fields like %user, %system, %iowait, and %idle — each has a specific meaning that you must memorise.
Inodes are a finite resource; always run 'df -i' alongside 'df -h' to check for inode exhaustion, which causes 'No space left on device' errors even when the disk has free space.
These come up on the exam all the time. Here's how to tell them apart.
Utilisation
Percentage of a resource being actively used (e.g., CPU at 75%)
Measured directly from sar -u or top
High utilisation alone may not indicate a problem
Saturation
Amount of work queued because the resource is fully busy (e.g., load average of 8 on 4 cores)
Measured via sar -q or load average
High saturation always indicates performance degradation
Scaling Up (Vertical Scaling)
Add more power to a single machine (more RAM, faster CPU, bigger disk)
Simpler to implement — no load balancer needed for a single server
Has a maximum physical limit — you cannot keep upgrading forever
Scaling Out (Horizontal Scaling)
Add more identical servers to share the workload
Requires a load balancer and often application changes for state management
Offers near-limitless capacity and provides redundancy
Free Memory (free command)
RAM not currently allocated to any process or cache
Often very low because Linux uses spare RAM for disk caching
A low free memory number does not mean the system is out of memory
Available Memory (free command)
Estimated amount of memory available for starting new applications, including reclaimable cache
A better indicator of true spare capacity
If available memory is low (e.g., < 10% of total), the system is genuinely memory-constrained
Mistake
If 'free' shows 0 MB of free RAM, the system has a memory problem.
Correct
Linux uses spare RAM for caching files and buffers. 'free' memory is often very low, but 'available' memory includes reclaimable cache. A low 'free' count by itself is not a problem; check the 'available' column or look for swapping activity.
This mistake is common because on Windows, low free memory usually means a problem. Linux memory management is different — it intentionally uses spare RAM to speed up file access.
Mistake
CPU utilisation at 100% always means the system is overloaded and should be upgraded.
Correct
100% CPU utilisation is fine if the system is doing useful work and the load average is equal to or less than the number of CPU cores. The problem is when utilisation is 100% and the load average is significantly higher, causing jobs to queue up and latency to increase.
Beginners see a high percentage and panic. They do not distinguish between productive work and saturation. A single-core CPU at 100% with load 1.0 is perfectly balanced.
Mistake
Capacity planning is only about adding more hardware when something breaks.
Correct
Capacity planning is proactive, not reactive. It involves continuous monitoring, trend analysis, and forecasting so that hardware is added before any performance degradation occurs. The goal is to prevent breaks, not fix them.
Many people come from a help-desk background where they only react to fires. The exam tests the discipline of anticipation — knowing when a resource will run out weeks or months in advance.
Mistake
You only need to monitor the CPU and RAM — disk space is not usually a problem.
Correct
Disk space, disk I/O, and network bandwidth are equally critical. A full disk can crash a database instantly. High disk I/O wait time can slow the entire system more than a busy CPU. Inodes can fill up even when there is free space, preventing all file creation.
New administrators often focus on CPU and RAM because those are visible in 'top'. They overlook 'df -i' and 'iostat' until a seemingly inexplicable failure occurs.
Mistake
Elastic scaling in the cloud means you never need to plan capacity.
Correct
Elastic scaling still requires planning. You must set correct thresholds (e.g., CPU at 70% for 5 minutes), ensure the load balancer can handle the maximum expected scale, and budget for cost spikes. Without planning, you can get a huge bill for unintended scaling.
The promise of 'auto-scaling' makes it seem automatic, but poor configuration leads to either no scaling when needed or runaway costs. The exam tests the fundamentals of planning even in dynamic environments.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
'sar -u' reports CPU utilisation (percentage of time spent in user, system, I/O wait, and idle). 'sar -q' reports the load average and the number of runnable and blocked processes. Use '-u' to see CPU busyness; use '-q' to check how many processes are waiting for the CPU.
Run 'iostat -x 1' and look at the '%util' column — if it is consistently near 100%, the disk is saturated. Also check 'await' (average time for I/O requests to complete). A high await with high %util means the disk is the bottleneck.
%iowait shows the percentage of time the CPU was idle but there was at least one outstanding disk I/O request. A high %iowait (above 10-15%) indicates the system is waiting for storage — disk is slower than the CPU can process data.
Collect disk usage data monthly using 'df -h'. Calculate the average growth per month (e.g., 10 GB/month). Divide the remaining free space by that growth rate. For example, 50 GB remaining / 10 GB per month = 5 months until full. Always add a buffer (plan to upgrade at 80% usage).
The load average shows the average number of processes waiting to run over 1, 5, and 15 minutes. On a 4-core CPU, a load of 4.0 means the CPU is perfectly utilised — each core works non-stop. Above 4.0 means processes are queuing; below 4.0 means the CPU has idle capacity.
Scale up (bigger server) is simpler, cheaper for small needs, and requires no application changes — but has a single point of failure and a limit on how big you can go. Scale out (multiple servers) gives redundancy, better fault tolerance, and virtually unlimited capacity, but requires a load balancer and often application changes. Choose scale out for high-availability or rapidly growing services.
You've finished Capacity Planning and System Resources. Continue through the LPIC-2 study guide to build a complete picture of the exam.
Done with this chapter?