tencent cloud

TencentOS Server

DocumentaçãoTencentOS ServerUser GuidePerformance TuningPerformance Tuning Overview

Performance Tuning Overview

Baixar
Modo Foco
Tamanho da Fonte
Última atualização: 2026-10-19 17:22:51
Traduzido por IA

Overview

Performance tuning is not about "setting all parameters to recommended values". Instead, it involves adjusting relevant parameters in a targeted manner based on the bottleneck characteristics of the business scenario. Blindly applying parameters may lead to performance degradation or even system instability.
This document is organized by common business scenarios and provides the following for each scenario:
Scenario characteristics (what types of businesses fall into this scenario)
Tuning essentials (what to tune and how to tune it)
Effect verification (what tools to use to confirm that tuning is effective)
Precautions (when not to tune)
Applicable version: TencentOS Server 4 (kernel 6.6 series)

Prerequisites for Tuning

Establish a performance baseline before adjusting any parameters:
dnf install -y unixbench lmbench sysbench iperf3
dnf install -y tuned && systemctl enable --now tuned     # Use tuned-adm to switch profiles in the scenarios described later.
unixbench: a comprehensive benchmark that weights 12 subtests into an Index score, suitable for evaluating overall changes before and after tuning.
unixbench                                   # Standard run: 1 copy + nproc copies
unixbench -c 1 -i 3 execl spawn shell8      # Run a single subtest only
unixbench --print-workdir                   # View the directory where results are stored
lmbench: a microbenchmark that measures individual operations such as system calls, context switches, process creation, and memory latency, making it suitable for evaluating latency-sensitive workloads. In TencentOS Server 4, it must be invoked through lmbench <program name>.
lmbench lat_ctx -s 0 2                # Context switch latency (in microseconds)
lmbench lat_tcp -s; lmbench lat_tcp localhost; lmbench lat_tcp -S localhost   # TCP loopback latency (in microseconds)
lmbench lat_proc exec                 # Process creation latency (in microseconds)
lmbench bw_mem 1g rd                  # Memory read bandwidth (MB/s)
sysbench: a multithreaded stress testing tool that can apply CPU, memory, and file I/O loads based on the number of threads, and includes built-in OLTP test scripts with support for MySQL and PostgreSQL (--db-driver=pgsql).
sysbench cpu --threads=$(nproc) run
sysbench memory --memory-block-size=1M --memory-total-size=10G run
sysbench fileio --file-total-size=4G --file-test-mode=rndrw prepare
sysbench fileio --file-total-size=4G --file-test-mode=rndrw --time=60 run
sysbench fileio --file-total-size=4G cleanup
iperf3: a network bandwidth testing tool.
iperf3 -s                       # Server
iperf3 -c <server IP> -t 60      # Client
Retest after each tuning iteration and compare against the baseline to determine whether the change is effective. Change only one variable per tuning iteration to avoid being unable to identify which parameter made a difference. Run each set of tests multiple times and use the median value. If the improvement is smaller than the test variance, consider the tuning ineffective.

Scenario 1: Databases (MySQL/PostgreSQL/Redis)

Scenario Characteristics

Large memory footprint, relying on file system cache or direct I/O.
Sensitive to latency, especially in OLTP scenarios.
Typically write-intensive or mixed read/write.
Cross-node access under the NUMA architecture can significantly impact performance.

Tuning Key Points

1. Set Transparent Huge Pages (THP) to madvise or never.
Databases are dominated by random access, and the always mode of THP may increase memory compaction overhead. TencentOS Server 4 already defaults to madvise. Verify this first:
cat /sys/kernel/mm/transparent_hugepage/enabled
The official documentation for some databases (such as Redis and MongoDB) recommends setting it directly to never. For persistence, see the "Persisting Tuning Results" section. Writing it in rc.local is not recommended.
2. Reduce swappiness and dirty page thresholds.
cat > /etc/sysctl.d/99-database-perf.conf << 'EOF'
vm.swappiness = 5
vm.dirty_ratio = 10
vm.dirty_background_ratio = 3
EOF
sysctl -p /etc/sysctl.d/99-database-perf.conf
3. NUMA binding (for multi-NUMA-node servers)
When a process is scheduled across NUMA nodes, cross-node memory access can cause significant performance fluctuations. Bind the database process to a single NUMA node:
dnf install -y numactl
numactl --hardware
numactl --cpunodebind=0 --membind=0 /usr/sbin/mysqld
If the memory required by the database exceeds the capacity of a single node, interleave memory allocation across all nodes instead to prevent memory exhaustion on a single node:
numactl --interleave=all /usr/sbin/mysqld
4. Use static huge pages (for shared-memory databases such as PostgreSQL and Oracle).
Reserve huge pages based on the database shared memory size. For example, if PostgreSQL shared_buffers = 16GB, approximately 8192 huge pages are required when 2MB huge pages are used. Leave a small margin:
grep Hugepagesize /proc/meminfo
echo "vm.nr_hugepages = 8400" > /etc/sysctl.d/99-hugepages.conf
sysctl -p /etc/sysctl.d/99-hugepages.conf
grep HugePages_ /proc/meminfo           # Verify that HugePages_Total reaches the expected value
Then enable huge pages in the database: set huge_pages = on for PostgreSQL and USE_LARGE_PAGES = ONLY for Oracle.
I/O scheduler: Use none for NVMe/SSD and mq-deadline for HDDs.
Protect database memory and lower the I/O priority of background tasks in colocation scenarios.
# Reclaim memory from other processes first when memory is tight, and preserve the database cache
systemctl set-property mysqld.service MemoryLow=32G

# Use the lowest I/O priority for background tasks such as backup and export
ionice -c3 <backup command>

Effect Verification

# MySQL OLTP mixed read/write (the script is located in /usr/share/sysbench/, and you need to create the test database first)
mysql -u<user> -p -e "CREATE DATABASE sbtest"
sysbench oltp_read_write --mysql-user=<user> --mysql-password=<password> \\
    --tables=10 --table-size=100000 prepare
sysbench oltp_read_write --mysql-user=<user> --mysql-password=<password> \\
    --tables=10 --table-size=100000 --threads=$(nproc) --time=60 run

# Redis (redis-benchmark is installed with the redis package)
redis-benchmark -n 100000 -c 50 -t set,get

# PostgreSQL (pgbench is provided by the postgresql-contrib package)
pgbench -i -s 100 <database name>
pgbench -c $(nproc) -j $(nproc) -T 60 <database name>
Focus on TPS/QPS and 95% latency. After NUMA binding, also check whether the variance between multiple test runs decreases.

Must-Knows

For databases that use O_DIRECT (bypassing the page cache), tuning dirty_ratio has limited effect.
After NUMA binding, if a single node has insufficient memory, more swap will be triggered. Ensure that the node has sufficient memory.
Statically reserved huge pages cannot be used by other processes, and over-reservation consumes system memory. Runtime allocation may fail due to memory fragmentation, in which case you need to restart and allocate as early as possible.
ionice takes effect only with the bfq and mq-deadline schedulers, and has no effect with none.
Do not set vm.zone_reclaim_mode = 1. When this parameter is enabled and the local node runs out of memory, the kernel reclaims page cache from the local node first instead of allocating from other nodes, causing the cache to be cleared frequently, which is typically detrimental to databases.

Scenario 2: Web Servers/API Services (Nginx/Tomcat/Self-Developed Frameworks)

Scenario Characteristics

High-concurrency short-lived connections or long-lived connections
Network transmission and reception are the primary bottleneck.
High throughput is required, and per-request latency in milliseconds is acceptable.
It is typically a multi-core, multi-threaded model.

Tuning Key Points

1. Increase the TCP buffer size and connection queue length.
cat > /etc/sysctl.d/99-web-perf.conf << 'EOF'
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
EOF
sysctl -p /etc/sysctl.d/99-web-perf.conf
somaxconn must be used together with the listen backlog of Nginx/Tomcat, and the smaller of the two values takes effect.
2. File descriptor limit
The system-level limit fs.file-max is already large enough by default on TencentOS Server 4 and does not need to be adjusted. What needs to be adjusted is the process-level limit. Services managed by systemd are configured through unit files, and /etc/security/limits.conf does not take effect for systemd services:
mkdir -p /etc/systemd/system/nginx.service.d
cat > /etc/systemd/system/nginx.service.d/limits.conf << 'EOF'
[Service]
LimitNOFILE=1048576
EOF
systemctl daemon-reload && systemctl restart nginx
3. Bind NIC interrupts to CPU cores
dnf install -y irqbalance
systemctl enable --now irqbalance
When manual interrupt binding is required (for example, pinning interrupts to non-business cores):
systemctl stop irqbalance    # Otherwise, irqbalance will overwrite manual settings.
grep eth0 /proc/interrupts
echo 0-3 > /proc/irq/<IRQ number>/smp_affinity_list
4. NIC queues and packet reception
# Increase the NIC send and receive ring buffer size (do not exceed the maximum value shown by ethtool -g)
ethtool -g eth0
ethtool -G eth0 rx 4096 tx 4096

# Each line in /proc/net/softnet_stat corresponds to a CPU. If the second column (hexadecimal) keeps increasing, packets are dropped because softirqs cannot be processed in time. In this case, increase the receive queue size.
cat /proc/net/softnet_stat
sysctl -w net.core.netdev_max_backlog=16384
When the number of NIC queues is less than the number of CPUs (common in virtual machines), you can enable RPS/RFS to distribute packet reception across more CPUs:
ethtool -l eth0                                              # View the number of queues
echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus         # Set this for every rx queue, and calculate the mask based on the actual number of CPUs.
sysctl -w net.core.rps_sock_flow_entries=32768
echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt     # rps_sock_flow_entries / number of queues
5. Expand the local port range when there are many outbound connections (such as reverse proxies, gateways, or calling a large number of backend services)
cat > /etc/sysctl.d/99-web-ports.conf << 'EOF'
net.ipv4.ip_local_port_range = 10000 65000
# Reserve the local listening service ports to prevent them from being occupied by outbound connections (replace with the actual ports).
net.ipv4.ip_local_reserved_ports = 8080,9000-9100
EOF
sysctl -p /etc/sysctl.d/99-web-ports.conf
6. Keepalive for long-lived connections: For long-lived connections that pass through load balancers or NAT, the idle timeout is often shorter than the kernel default of 2 hours. You can shorten the keepalive probe interval to detect invalid connections in a timely manner:
cat > /etc/sysctl.d/99-web-keepalive.conf << 'EOF'
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3
EOF
sysctl -p /etc/sysctl.d/99-web-keepalive.conf
This takes effect only for connections with SO_KEEPALIVE set.
7. CPU frequency: tuned-adm profile throughput-performance.

Effect Verification

# HTTP stress test (run on another machine)
dnf install -y httpd-tools
ab -n 1000000 -c 1000 -k http://<server IP>/

# Single-node multi-core throughput (focus on multi-copy Index)
unixbench -c $(nproc) -i 3 syscall context1 pipe

Must-Knows

tcp_tw_reuse = 1 is effective only for reusing outbound connections and does not affect inbound connections.
Increasing the buffer size does not take effect automatically. The application must set it through setsockopt(SO_RCVBUF/SO_SNDBUF) or rely on automatic system tuning.
tcp_tw_recycle was removed in Linux 4.12 because it can cause packet loss in NAT environments, and this parameter does not exist on TencentOS Server 4.
Do not enable NIC LRO on machines that perform forwarding or bridging, as this can cause forwarding exceptions. Keep GRO enabled by default.

Scenario 3: High-Throughput Network Transfer (Cross-Region File Synchronization/Data Backup/Large File Transfer)

Scenario Characteristics

For single-connection large file transfer, the goal is to fully saturate the bandwidth.
Typically across regions, the RTT is high (20ms-200ms).
Bandwidth utilization is the core metric.

Tuning Key Points

1. Adjust the TCP window based on the bandwidth-delay product (BDP).
BDP = bandwidth (bps) × RTT (s)
Required window size = BDP / 8
For example, with 1 Gbps bandwidth and 50ms RTT, the required window size = 1000000000 × 0.05 / 8 ≈ 6.25 MB.
cat > /etc/sysctl.d/99-wan-perf.conf << 'EOF'
# Set the buffer upper limit to more than twice the BDP.
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 131072 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_window_scaling = 1
# After a long-lived connection becomes idle, slow start is not re-initiated, allowing faster recovery to full speed during intermittent transmission.
net.ipv4.tcp_slow_start_after_idle = 0
EOF
sysctl -p /etc/sysctl.d/99-wan-perf.conf
Congestion control algorithm
Private network or low-latency link: cubic (default) is sufficient.
Cross-region/high-latency link: try BBR.
cat > /etc/sysctl.d/99-bbr.conf << 'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sysctl -p /etc/sysctl.d/99-bbr.conf
sysctl net.ipv4.tcp_congestion_control       # Confirm that the algorithm has been switched to bbr.
The tcp_bbr module is not loaded by default, so it is normal that bbr is not listed in tcp_available_congestion_control. The kernel automatically loads this module when it is configured.
BBR delivers significant performance gains on high-latency links with packet loss. On a private network with low latency and no packet loss, its performance is similar to that of cubic, so testing is required before a decision is made.
2. Enable MTU probing (for links traversing tunnels/VPNs).
When a segment of the link has a smaller MTU and ICMP is filtered, large packets are silently dropped, resulting in normal connection establishment but stalled data transfer. After MTU probing is enabled, the kernel automatically reduces the packet size when a black hole is detected:
sysctl -w net.ipv4.tcp_mtu_probing=1

Effect Verification

iperf3 -c <peer IP> -t 60          # Single-stream bandwidth
iperf3 -c <peer IP> -t 60 -R       # Reverse direction
ss -ti dst <peer IP>               # View the proportion of rwnd_limited / sndbuf_limited (not displayed when not limited)

Must-Knows

After the buffer is adjusted, the proportions of rwnd_limited and sndbuf_limited should decrease significantly. Otherwise, the bottleneck is not related to the window.
The buffer size limit described above applies to a single connection. When there are many connections, the total memory used by all TCP connections is also limited by net.ipv4.tcp_mem (in pages). You can check whether the limit is nearly reached by viewing the TCP mem value in cat /proc/net/sockstat.
For detailed diagnostic methods, see TCP Transfer Rate and Performance Analysis.

Scenario 4: Real-Time/Low-Latency Applications (Financial Trading/Gaming/Media Streaming)

Scenario Characteristics

Extremely latency-sensitive (at the microsecond level).
Low throughput requirements.
Requires predictable response time and rejects latency spikes.

Tuning Key Points

1. CPU isolation
dnf install -y tuned-profiles-cpu-partitioning
vi /etc/tuned/cpu-partitioning-variables.conf
# isolated_cores=2-15
tuned-adm profile cpu-partitioning
reboot
cpu-partitioning automatically sets the nohz_full and rcu_nocbs boot parameters and prevents irqbalance from assigning interrupts to isolated cores. If you do not use this profile and manually isolate CPUs, you need to exclude the isolated cores in /etc/sysconfig/irqbalance:
# /etc/sysconfig/irqbalance
IRQBALANCE_BANNED_CPULIST=2-15
After making the modification, run systemctl restart irqbalance.
When binding a business process to isolated cores, you need to bind all threads (-a). Otherwise, only the main thread takes effect:
taskset -a -cp 2-15 <PID>
2. The business process and the NIC are on the same NUMA node.
cat /sys/class/net/eth0/device/numa_node        # The node where the NIC resides. -1 indicates no NUMA information.
numactl --cpunodebind=<node> --membind=<node> <business command>
NIC interrupts should also be bound to CPUs on the same node.
3. Reduce NIC interrupt coalescing.
By default, the NIC coalesces multiple packets before generating an interrupt to reduce CPU usage, but this increases packet reception latency. Latency-sensitive workloads can reduce the coalescing time:
ethtool -c eth0                                  # View current settings
ethtool -C eth0 adaptive-rx off rx-usecs 0
Some virtual NICs do not support modification. Refer to the output of ethtool -c.
Disable THP: echo never > /sys/kernel/mm/transparent_hugepage/enabled (For persistence, see the "Persisting Tuning Results" section).
Limit C-states and fix the frequency.
For physical machines, use the latency-performance or network-latency profile. In KVM virtual machines, the cpuidle driver is typically none, which causes slow wake-up after vCPUs become idle. You can enable haltpoll, which is built into the TencentOS Server 4 kernel. This increases CPU usage on the host and is suitable for instances with dedicated physical cores:
cat /sys/devices/system/cpu/cpuidle/current_driver     # none indicates that it is not enabled
grubby --update-kernel=ALL --args="cpuidle_haltpoll.force=1"
reboot
4. Real-time scheduling policy
chrt -f -p 50 <PID>        # SCHED_FIFO priority 50
Do not set kernel.sched_rt_runtime_us to -1. By default, 5% of CPU time is reserved for normal tasks to prevent real-time tasks from freezing the system.

Effect Verification

taskset -c 2,3 lmbench lat_ctx -s 0 2      # Context switch latency
lmbench lat_tcp -s; taskset -c 2 lmbench lat_tcp localhost; lmbench lat_tcp -S localhost
In addition to the average value, pay more attention to whether the P99/P999 latency of the service itself decreases.

Must-Knows

After CPU isolation, the isolated cores do not participate in system scheduling. Ensure that system services are not assigned to the isolated cores.
Low-latency tuning typically comes at the cost of throughput and power consumption, and it is not suitable for use in high-throughput scenarios.
Reducing interrupt coalescing significantly increases the number of interrupts and CPU usage. Use it only on latency-sensitive machines.

Scenario 5: Batch Processing/Build Tasks (Compilation, CI/CD, Script-Intensive Tasks)

Scenario Characteristics

A large number of short-lived processes with frequent fork/exec operations.
CPU-intensive, with a focus on overall completion time.
Insensitive to individual latency.

Tuning Key Points

CPU frequency: tuned-adm profile throughput-performance.
Place the build directory on tmpfs (when memory is sufficient).
mkdir -p /build
mount -t tmpfs -o size=32G tmpfs /build
1. Control resource allocation.
When colocating with online services, lower the priority of build tasks and set an upper limit to avoid affecting the online services.
# CPUWeight defaults to 100. Lower it to yield resources during CPU contention. TasksMax prevents uncontrolled process growth. MemoryHigh starts throttling after the limit is exceeded.
systemd-run --scope -p CPUWeight=20 -p TasksMax=8192 -p MemoryHigh=16G -- make -j$(nproc)

# Or use nice/ionice to lower CPU and I/O priority.
nice -n 10 ionice -c3 make -j$(nproc)
On dedicated build machines, do the opposite: set CPUQuota/CPUWeight limits for other services to reserve resources for build tasks.

Effect Verification

unixbench -c 1 -c $(nproc) -i 3 execl spawn shell1 shell8
lmbench lat_proc exec
The final result is based on the total duration of actual builds/tasks.

Must-Knows

Data in tmpfs is lost after a restart, so tmpfs is only suitable for storing intermediate artifacts.

Scenario 6: Virtualization Hosts (KVM)

Scenario Characteristics

Run multiple KVM virtual machines on the host.
Pay attention to whether VM performance is stable and whether VMs interfere with each other.
You need to strike a balance between performance and deployment density.

Tuning Key Points

1. Use the host profile.
tuned-adm profile virtual-host
2. Bind vCPUs to physical cores and align them with NUMA nodes.
Pin the VM's vCPUs to physical cores on the same NUMA node, and allocate memory from that node as well:
dnf install -y libvirt numactl
numactl --hardware                                       # View the CPU and memory of each node
virsh vcpupin <virtual_machine> <vCPU_ID> <physical_CPU> --config
virsh emulatorpin <virtual_machine> <physical_CPU_list> --config         # QEMU's own threads
virsh numatune <virtual_machine> --mode strict --nodeset 0 --config
3. Use huge pages for VM memory.
Reserve huge pages on the host (with the quantity calculated based on the total VM memory, using the same method as in Scenario 1), and enable them in the VM XML:
<memoryBacking>
  <hugepages/>
</memoryBacking>
4. The NIC uses virtio multi-queue.
For VMs with multiple vCPUs, using multi-queue on the NIC can distribute packet transmission and reception across multiple vCPUs:
<interface type='network'>
  <model type='virtio'/>
  <driver name='vhost' queues='4'/>
</interface>
Run ethtool -L eth0 combined 4 in the VM to enable all queues.
5. Disable KSM as needed.
KSM merges identical memory pages across multiple VMs to improve deployment density, but scanning and merging consume CPU resources and increase memory access latency. Disable KSM when performance is a priority:
cat /sys/kernel/mm/ksm/run            # 0 indicates that it is not running, and no action is required
echo 2 > /sys/kernel/mm/ksm/run       # Stop KSM and split the merged pages
After the merged pages are split, memory usage will increase. Before performing this operation, ensure that the host has sufficient memory.

Effect Verification

Run unixbench or sysbench in the VM and compare the results before and after tuning. Then run stress tests on multiple VMs simultaneously and observe whether the result variance of each VM decreases.
unixbench -c 1 -c $(nproc) -i 3
sysbench cpu --threads=$(nproc) run

Must-Knows

After vCPUs are pinned to physical cores, scheduling flexibility is lost. CPU overcommitment (where the total number of vCPUs is greater than the number of physical cores) is not suitable for CPU pinning.
After huge pages are reserved on the host, this portion of memory can no longer be used by host processes.

Scenario 7: General-Purpose Servers (Unspecified Business Workloads)

If the business type is not yet identified, you can first check the pressure information (PSI) during peak business hours to determine whether the main bottleneck is CPU, memory, or I/O, and then tune the system according to the corresponding scenario:
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
some indicates the percentage of time that at least one task is stalled while waiting for the resource. full indicates the percentage of time that all non-idle tasks are stalled simultaneously. Note that the CPU full value is always 0 at the system level, so only some is relevant. avg10, avg60, and avg300 are the average values over the last 10 seconds, 60 seconds, and 300 seconds, respectively. If a metric remains consistently high, the bottleneck lies in the corresponding type of resource.
If the server runs multiple mixed workloads, use the general-purpose tuned profile:
dnf install -y tuned
systemctl enable --now tuned
tuned-adm recommend
tuned-adm profile $(tuned-adm recommend)
tuned-adm active
tuned-adm verify
The main settings of the built-in tuned profile in TencentOS Server 4 are as follows:
Profile
Main Settings
Scenario
throughput-performance
governor=performance,readahead≥4096,dirty_ratio=40,swappiness=10
General high throughput for physical machines
virtual-guest
Inherits throughput-performance, dirty_ratio=30, swappiness=30.
General-purpose for virtual machines
latency-performance
governor=performance, limit C-state, dirty_ratio=10, swappiness=10.
Low latency
network-latency
Inherits latency-performance, disables THP and NUMA auto-balancing, busy_poll=50.
Low-latency network
hpc-compute
Inherits latency-performance, THP=always, disables NUMA auto-balancing.
HPC computing
In general scenarios, keep the following parameters at their default values. Do not adjust them blindly:
Parameter
TencentOS Server 4 Default Value
Recommendation
vm.swappiness
60
Keep the default value unless swap usage needs to be reduced.
vm.dirty_ratio
20
Keep the default value.
net.ipv4.tcp_congestion_control
cubic
Keep the default value unless cross-region transfer is required.
THP
madvise
Keep the default value unless never is required for database or low-latency scenarios.
The table above lists the kernel default values, which may have been modified by images or other software. Before making adjustments, run sysctl <parameter_name> to check the current values.

Effect Verification

unixbench          # Compare the single-copy and multi-copy Index values before and after switching profiles

Persisting Tuning Results

Write all validated parameters to a custom tuned profile to prevent configurations in sysctl.d, rc.local, and tuned from overwriting each other:
mkdir -p /etc/tuned/my-db
cat > /etc/tuned/my-db/tuned.conf << 'EOF'
[main]
summary=Database workload tuning
include=throughput-performance

[vm]
transparent_hugepages=never

[sysctl]
vm.swappiness=5
vm.dirty_ratio=10
vm.dirty_background_ratio=3
EOF

tuned-adm profile my-db
tuned-adm verify
Parameters with the same name in the parent profile inherited through include are overwritten by the child profile.
In TencentOS Server 4, tuned enables reapply_sysctl by default (see /etc/tuned/tuned-main.conf). After a profile is applied, the configurations in /etc/sysctl.d/ are reloaded, and for parameters with the same name, the values in sysctl.d take precedence. After switching to tuned for management, delete the sysctl.d files with the same names that were created for the preceding scenarios to avoid configuration inconsistencies.

Applicability of Common Tuning Suggestions on TencentOS Server 4

The following common tuning recommendations are based on older kernels or other distributions and are ineffective or risky on TencentOS Server 4 (kernel 6.6):
Common Recommendations
Status on TencentOS Server 4
Recommended Practice
Adjust kernel.sched_latency_ns and kernel.sched_min_granularity_ns through sysctl.
Since 5.13, these parameters have been moved from sysctl to debugfs and are for debugging purposes only. The 6.6 kernel uses the EEVDF scheduler, and min_granularity has been replaced by base_slice_ns.
No adjustment is required during service tuning.
Set net.ipv4.tcp_tw_recycle
Removed in Linux 4.12.
Use only tcp_tw_reuse.
Set the I/O scheduler to noop, or use the boot parameter elevator=
Under blk-mq, the corresponding scheduler is none; the elevator= boot parameter is no longer effective.
Configure through udev rules.
vm.dirty_ratio=40
On machines with large memory, excessive dirty page accumulation can easily cause I/O stalls during writeback.
Configure based on the scenario.
Modify /etc/pam.d/common-session to enable pam_limits
Debian-specific path. In TencentOS Server 4, system-auth is already enabled.
Use LimitNOFILE in the systemd service.
intel_idle.max_cstate=1
Ineffective on AMD machines.
Use the tuned latency-performance profile.
vm.panic_on_oom=1
Directly restarts the entire machine upon OOM.
Use only when a high availability failover mechanism is available.

General Disk I/O Optimization

Disk Scheduler

Disk Type
Recommended Scheduler
Reason
NVMe
none
NVMe has built-in multi-queue capabilities and does not require additional scheduling.
SSD
none or mq-deadline
Fast random access, scheduling overhead yields no benefit.
Mechanical disk (database/throughput-oriented)
mq-deadline
Ensures request latency upper limit with low overhead.
Mechanical disk (multi-user mixed workload)
bfq
Allocate bandwidth fairly to prevent starvation.
cat /sys/block/sda/queue/scheduler

cat > /etc/udev/rules.d/60-scheduler.rules << 'EOF'
ACTION=="add|change", KERNEL=="sd[a-z]*|nvme[0-9]*n[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"
EOF
udevadm control --reload && udevadm trigger --type=devices --action=change
The virtio disks of a CVM (vda, vdb, and so on) are usually reported as mechanical disks (rotational is 1), but the backend is mostly cloud storage. Keep the default none and do not treat them as mechanical disks.

Read-Ahead Optimization

Effective only for sequential read-intensive scenarios (such as log analysis and large file reads):
blockdev --getra /dev/sda          # Unit: 512-byte sectors
blockdev --setra 8192 /dev/sda
Do not increase read-ahead for random read scenarios (such as databases), as it will only add unnecessary I/O.

Periodic SSD TRIM

SSDs need to periodically report which blocks are no longer in use to maintain write performance. Enable scheduled TRIM instead of using the discard mount option, which performs TRIM synchronously on every file deletion and slows down both deletion and write operations:
systemctl enable --now fstrim.timer      # Runs once a week by default

RAID Stripe Alignment

When creating a file system on software RAID or hardware RAID, align it with the stripe parameters to prevent a single write from spanning two stripes:
# su is the stripe unit size, and sw is the number of data disks (for example, 4 for a 4+1 RAID 5 configuration)
mkfs.xfs -d su=256k,sw=4 /dev/md0
XFS on software RAID (/dev/md*) usually detects stripe parameters automatically, while hardware RAID requires manual configuration.

Performance Detection Tools Overview

Tool
Purpose
Installation Command
unixbench
Comprehensive performance benchmark test
dnf install -y unixbench
lmbench
Microbenchmark testing (latency/bandwidth)
dnf install -y lmbench
sysbench
CPU/memory/I/O/database stress testing
dnf install -y sysbench
iperf3
Network bandwidth test
dnf install -y iperf3
fio
Fine-grained storage I/O testing
dnf install -y fio
perf
CPU performance analysis (function-level)
dnf install -y perf
Anterior: Rust Development GuidePróximo: perf Performance Analysis

Ajuda e Suporte

Esta página foi útil?

comentários

Search
    Enter keywords to search documentation