About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
When a business application moves to a hosted server, the size can be chosen from the vendor's minimum requirements, or by copying the old server. Neither tells you what the application actually uses. The old server may be oversized, or it may have been short of memory without it being noticed.
A better starting point is a few weeks of measurements from the server you already run. Windows has the tools built in. This article covers what to collect, how to read it, and how to turn it into a size.
Why it matters
An undersized server makes the application slow at the busiest times. An oversized one costs money every month, and on hosted servers with per-core licensing for Windows Server or SQL Server, extra processor cores can cost more in licences than in hosting. Measured sizes put both risks on evidence.
How it works
Collecting the data
Windows Performance Monitor records performance counters to a log file through a data collector set. Microsoft's troubleshooting guide shows a collector set created with the logman tool, logging every 15 seconds into a circular file capped at 800 MB. Microsoft states that at this setup the impact on the system should be less than 1% and that, after a restart, the collector must be started again.
Microsoft explains the graph limit: Performance Monitor shows at most 1,000 points, then combines points. A 15-second interval does not avoid that aggregation over weeks. Use raw timestamped samples, exported with relog where appropriate, for percentile analysis and inspect shorter time windows for peaks.
An 800 MB circular log retains a bounded recent window and overwrites older samples; it does not guarantee a full month-end or multiweek history. Agree bounded rotation and archive/export before wrap, with total retention capped. Measure actual file growth to size the retained window. Before analysis, verify earliest/latest timestamps, sample counts, time zones and restart gaps, and preserve the relevant business-peak files. Treat missing coverage as a limitation, not as quiet workload.
Collect across a full business cycle: at least one month-end, payroll run, or whatever the business's peak is. A quiet fortnight measures a quiet fortnight.
What to collect
Microsoft's guide lists 18 counters as the most important, grouped by resource, with healthy, warning and critical ranges. The ones most useful for sizing are:
| Resource | Counter | Microsoft's healthy range |
|---|---|---|
| Disk latency | LogicalDisk Avg. Disk sec/Read and sec/Write | below 15 ms |
| Memory | Memory\Available MBytes | above 10%, or at least 4 GB free |
| Memory | Memory\% Committed Bytes In Use | 0–50% |
| Processor | Processor Information\% Idle Time | above 20% |
| Processor | Processor Information\% User Time and % Privileged Time | below 50% and below 30% |
| Network | Network Interface\Bytes Total/sec | below 50% of the adapter's speed |
Microsoft adds that Short spikes can be tolerated. You should investigate longer latency periods (over one minute or longer). The same applies to the processor ranges.
For sizing disks you also need volume, not just latency: record the LogicalDisk counters for reads and writes per second and bytes per second on each volume. The process counters (Process\% User Time, Process\Working Set, Process\IO Read and Write Operations/sec) show which program uses the resource, which matters when several applications share the server.
Turning measurements into a size
These steps are a method, not a Microsoft formula.
- Describe demand across a complete business cycle. Calculate percentiles from verified raw samples, but also identify business-critical peaks and simultaneous CPU, memory, storage and network pressure. Independent 95th percentiles can hide the busiest five per cent and do not describe one combined workload. Include response times and batch completion deadlines.
- Processor. As a preliminary observation only, aggregate busy fraction (percentage divided by 100) multiplied by the logical processors visible to the workload gives equivalent busy logical processors. For example, 50% across eight visible vCPUs is four equivalent busy vCPUs, not proof that a four-vCPU target will perform adequately. Keep logical/vCPU units consistent, inspect individual-core saturation and queues/waits, and account for single-thread performance, concurrency and host scheduling. Do not equate a vCPU to a physical core or assume linear scaling across processor generations.
- Memory. Use committed memory, working sets and pressure indicators, with room for the operating system and growth. SQL Server intentionally uses memory up to its configured cap, so free memory alone is a poor guide. Preserve application and SQL configuration context.
- Disk. Size capacity from used space and growth. For performance, record IOPS and throughput together with block sizes, read/write mix, latency, queueing and coincident application load. A saturated source reports delivered work, not the demand it could not serve. Check the candidate storage under that workload; the generic 15 ms troubleshooting guide is not every application's acceptable latency.
- Validate the candidate. Keep vendor minima and support requirements as prerequisites. On an authorised isolated test system, replay a representative concurrent workload including critical peaks and verify response and completion targets. Add and record headroom for growth, users and upgrades. Confirm those targets again after the move.
What to choose and why
- Measure on the current server whenever it exists. The vendor's minimum is a floor for support, not a size.
- Size each resource separately. A server can be short of memory and oversized on processors at the same time.
- Check disk latency first if users complain. High latency on the current server may mean the old storage was the bottleneck; more processors will not fix it.
- Repeat the measurement after the move. The new server's numbers confirm the size or show where to adjust.
Risks and limits
- A virtual machine's own counters are not the whole story. Inside a VM, processor counters do not show time the VM waited for the physical host. See the companion article on hypervisor and in-guest metrics.
- The thresholds are troubleshooting guidance. They are investigation signals, not universal sizing targets. The application's measured response and completion requirements determine acceptance.
- Collecting on production. Agree scope, interval, overhead and capped total retention with the owner. Use bounded rotation/export and restart handling; verify coverage before analysis. The published example's low overhead is not a measurement of your system.
- Personal data. Process names and counter logs can reveal what users run; store and share them accordingly.
- No commands are given here. Microsoft's guide includes the full logman example, and the logman and relog reference pages list the options.
Sources
Opened 14 November 2026.
- Microsoft Learn: Troubleshoot performance problems in Windows, source updated 2026-02-12.
- Microsoft Learn: logman create counter, source updated 2024-11-01.
- Microsoft Learn: relog, source updated 2024-11-01.
Related service: Cloud hosting.
Related future topics
- Reading a storage specification: IOPS, throughput, latency and block size.
- Why the provider's dashboard and your server disagree.
- SQL Server memory on a hosted VM.
Learning notes
- Retain and verify raw measurements across the business cycle; circular logs can overwrite the evidence.
- Generic latency thresholds are investigation signals, not application acceptance criteria.
- Use percentiles alongside coincident critical peaks, queues and response targets; validate the candidate under representative load.
- On SQL Server, free memory alone is a poor guide.
- Record the headroom you add and why.
This article was originally published on .