CHAPTER 24

Performance Tuning and Optimization

5 sections · 14 min read · SimpleVM 10.1

Performance tuning is the discipline of changing one thing, measuring whether it helped, and being ready to undo it. On a SimpleVM host this matters more than on a single server, because one host carries many virtual machines: a change that helps one workload can starve another, and an aggressive optimization can quietly reduce your ability to migrate a VM later. The safe path is always the same — establish the symptom, confirm a baseline, change a single setting that directly relates to that symptom, verify, and revert if it did not help.

This chapter is the action half of the pair that begins with Chapter 23, Monitoring Your SimpleVM Host. Monitoring tells you where the pressure is; tuning decides what, if anything, to do about it. Most genuine performance problems are resolved not by tuning at all but by finding the workload, the capacity limit, or the recent change behind the symptom — so every section here starts by reading state before it touches a setting. When a symptom turns out not to be a resource problem at all, the next stop is Chapter 25, Troubleshooting.

24.1 Performance Tuning Overview

Overview

Performance tuning on a SimpleVM host must be deliberate and reversible. Before you change any CPU, memory, storage, network, or host-level setting, you need four things in hand: the symptom (what is actually slow or failing), the affected workload (which VM or which part of the host), the baseline (what normal looks like for that resource), and the single change you expect to improve it. Without a baseline you cannot tell whether a change helped; without a single change you cannot tell which change helped.

The performance profile the host ships with is already tuned for virtualization: SimpleVM sets the virtual-host performance profile by default, visible on the host Overview page under Configuration. That means most hosts do not need host-level tuning at all — the productive work is usually right-sizing individual VMs and removing whatever recent change or capacity limit caused the symptom.

Before you begin

• You need administrative access to the web console (see Chapter 6, Accessing the SimpleVM Management Interface, and Section 6.5, Sign In with Administrative Access).
• Confirm the host and the affected VMs are healthy, and that storage pools and virtual networks are active (see Chapter 23, Monitoring Your SimpleVM Host).
• Check for pending updates or a required reboot before tuning, so you are not chasing a symptom that an update already fixes (see Chapter 18, Software Updates).
• Record the current configuration of any VM you intend to change — its vCPU count, memory size, disks, and network — so you have an exact value to revert to.
• For production workloads, schedule changes during a maintenance window in case a change requires a guest shutdown or reboot.

The tuning workflow

Every tuning task in this chapter follows the same loop. When in doubt, slow down and complete the loop rather than stacking changes:

• Identify the symptom and the affected workload.
• Measure or observe current behavior, so you have a baseline to compare against.
• Change one setting that directly relates to the symptom.
• Restart or reboot only if the change requires it.
• Verify whether the symptom improved.
• Document the change and the result.
• Revert the change if it did not help or introduced a side effect.

Verification

You are ready to tune when you can state the symptom in one sentence, point to the affected workload, describe the normal baseline for that resource, and name the single change you intend to make. If you cannot, return to Chapter 23, Monitoring Your SimpleVM Host, and build the baseline first.

Revert this change

This section changes nothing on its own — it establishes the method. The reversibility requirement applies to every specific change in the sections that follow: before you alter a setting, write down its current value so the revert step has an exact target.

24.2 CPU Performance

Overview

CPU pressure usually shows up as slow guest response, sustained high host CPU usage, long application response times, or a VM that is fine when idle but slows under load. The first decision is scope: is the pressure inside one VM, spread across several VMs, or on the host itself? That single distinction determines whether you adjust a VM, rebalance workloads, or accept that the host is at capacity.

Before you begin

• Read the host CPU baseline on the host Overview page, shown as a percentage of total CPUs (see Section 23.2, Host Resource Monitoring).
• Identify the affected VM and note its current vCPU count from the VM detail page, so you can revert precisely.

What to check first

Procedure

1. Review host CPU usage on the host Overview page. If the host itself is saturated, no per-VM change will help — reduce or rebalance workload, or add capacity.
2. Open Virtual machines and select the affected VM. On the detail page, review the per-VM Usage panel and note the current CPU value beside CPU in the Overview panel (for example, 2 vCPUs, host passthrough).
3. Check whether other VMs are also showing high activity. If many VMs are busy at once, treat this as a host-capacity question, not a single-VM question.
4. If only one VM is affected, review the guest operating system for high-CPU services or applications before changing the allocation — the fix is often inside the guest.
5. If many VMs are affected, review host capacity, recent updates, migration activity, backup activity, and scheduled jobs for a shared cause.
6. Adjust the VM's CPU allocation only when the workload genuinely needs it and the host has capacity. On the VM detail page, select edit beside CPU and change the vCPU count.

Verification

After a change, return to the per-VM Usage panel and the host Overview to confirm the symptom improved without pushing the host into saturation. A vCPU increase that fixes one VM but drives host CPU to a sustained ceiling has simply moved the problem.

Revert this change

If a CPU allocation change does not improve performance, return the VM to its previous vCPU count using the same edit control beside CPU. For production VMs, perform the revert during a maintenance window if the guest operating system requires a shutdown or reboot to apply it.

Troubleshooting

If adding vCPUs does not help, the bottleneck is probably not CPU — look at memory pressure (Section 24.3), storage latency hidden behind normal throughput (Section 24.4), or a process inside the guest. Persistent host-wide CPU saturation with no single dominant VM is a capacity signal, not a tuning problem. For a structured diagnosis, see Chapter 25, Troubleshooting (and Section 25.1, Troubleshooting Methodology).

24.3 Memory Performance

Overview

Memory pressure can cause slow guests, application errors, excessive disk activity from paging, failed VM starts, and — at the host level — instability that affects every VM. Because memory is harder to overcommit safely than CPU, review usage at both the host and the VM level before adding or removing memory from any single VM.

Before you begin

• Read the host memory baseline on the host Overview page (used of total, for example 35 / 62 GiB).
• Note the affected VM's current memory size from the VM detail page so you can revert to it exactly.

What to check first

Procedure

1. Review host memory usage on the host Overview page. If the host is already near its limit, do not add memory to a VM — that makes host pressure worse.
2. Open the affected VM and review its Usage panel and the Memory value in the Overview panel (for example, 4 GiB).
3. Check the guest operating system for memory pressure — high paging or swap usage inside the guest points to an under-sized VM or a memory leak in the workload.
4. Confirm whether other VMs started recently or had their memory increased, since that can change the host's available headroom.
5. If the host has clear headroom, consider increasing the affected VM's memory. On the VM detail page, select edit beside Memory and set the new size.
6. If the host is under memory pressure, do the opposite: reduce workload, shut down unused VMs, or add physical memory before increasing any allocation.

Verification

Confirm two things after a change: that the guest now reports the expected memory and that paging or swap inside the guest has dropped, and that the host Overview still shows healthy available memory. A VM that stops paging only because the host started paging has not been fixed.

Revert this change

If a memory change does not help, return the VM to its previous memory size using the same edit control beside Memory. If the VM was changed while running, confirm whether the guest recognized the original value or whether a reboot is required to restore it.

Troubleshooting

If adding memory does not resolve the symptom, the cause may be a runaway process in the guest, storage latency, or CPU pressure rather than memory size. Repeated host-wide memory pressure across many VMs is a capacity signal — the host needs more RAM or fewer workloads, not per-VM tuning. See Chapter 25, Troubleshooting (and Section 25.5, Storage Issues, when paging points back at the disk).

24.4 Storage Performance

Overview

Storage performance problems show up as slow VM boot, slow application response, delayed file operations, backup delays, high disk latency, or snapshot operations that take longer than expected. The most important rule here comes first: start with capacity and activity, not tuning. A storage pool that is full or nearly full imitates a performance problem almost perfectly, and the fix for that is space, not optimization.

Before you begin

• Review storage pool capacity on the Storage pools page and host disk activity on the host Storage page (see Section 23.4, Storage Monitoring).
• Have a current backup before you consider any change that touches a disk, pool, snapshot, or volume (see Chapter 20, Backup and Recovery).

What to check first

Procedure

1. Review storage pool capacity first. If a pool is full or nearly full, treat that as the cause and address space before anything else.
2. Review host storage read and write activity on the host Storage page. The graphs report throughput in MiB/s, which tells you how much data is moving but not how long each operation waits.
3. Check whether backups, migrations, uploads, updates, or snapshot operations are running — any of these can raise disk load temporarily.
4. Review the affected VM's disks and confirm the VM is using the intended storage pool (see Chapter 9, Managing VM Disks).
5. If the issue began after a storage change, revert or isolate that change before applying any new tuning.

Verification

After addressing capacity or isolating a heavy operation, confirm the symptom improved by watching the read and write graphs settle and by re-testing the slow operation inside the guest. If capacity was the cause, the improvement is usually immediate once space is recovered.

Revert this change

Most storage performance work is non-destructive — reading graphs, confirming capacity, or pausing a backup — and needs nothing reverted. If you moved a VM to a different storage pool or changed a disk to test a hypothesis, return it to the original pool or disk, confirm from the VM's Disks section, and restore from backup only if a change caused damage.

Troubleshooting

If capacity is healthy and no heavy operation is running but storage still feels slow, suspect latency behind normal throughput, a degraded RAID array or failing disk, or a controller or path problem — none of which a configuration change inside SimpleVM will fix. See Chapter 25, Troubleshooting (and Section 25.5, Storage Issues).

24.5 Network Performance

Overview

Network performance problems appear as slow file transfers, poor application response, failed name resolution, intermittent VM connectivity, or migration delays. Because a VM's connectivity depends on several layers stacked together, the first move is always to narrow the scope: is the problem in one VM, one virtual network, the SimpleVM host, or the wider physical network? Each answer points at a different layer and prevents you from tuning the wrong one.

Before you begin

• Review host networking graphs and interface status on the host Networking page (see Section 23.5, Network Monitoring).
• Confirm which virtual network the affected VM is attached to (see Chapter 10, Managing VM Network Interfaces, and Chapter 14, Managing Virtual Networks).

What to check first

Procedure

1. Review host networking graphs and interface status on the host Networking page. The Transmitting and Receiving graphs report throughput in Mbps for each interface.
2. Confirm the affected VM is using the expected virtual network, and check whether other VMs on the same virtual network are affected. If they are, the problem is the network, not the VM.
3. If traffic appears blocked rather than slow, review firewall zones and allowed services (see Chapter 16, Firewall and Security Settings).
4. Test name resolution and gateway reachability from inside the affected guest, to separate a routing or DNS problem from a throughput problem.
5. If the host uses bridge networking, confirm the host bridge, the physical interface, the VLAN, and the upstream switch configuration.

Verification

After narrowing and addressing the layer at fault, confirm the improvement at that same layer: re-test the slow transfer from the affected guest, watch the interface graphs respond, and confirm name resolution and gateway reachability now succeed. If host and virtual networking both look correct but a VM still cannot connect, the problem has moved to the guest or the physical network.

Revert this change

The checks in this section are read-only and need nothing reverted. If you changed a VM's virtual network, a firewall rule, or a host bridge or VLAN to test a hypothesis, restore the original setting from its home chapter — virtual network attachment in Chapter 14, Managing Virtual Networks, firewall rules in Chapter 16, Firewall and Security Settings, and host bridges, bonds, and VLANs in Chapter 15, Managing Host Networking — and verify connectivity returns before moving on.

Troubleshooting

If every SimpleVM layer is healthy but traffic is still slow or intermittent, the cause is likely beyond the host: the physical switch, a VLAN mismatch, an upstream firewall, or the remote endpoint. For a layer-by-layer diagnosis, see Chapter 25, Troubleshooting (and Section 25.6, Network Issues, and Section 25.7, Firewall Issues).