Learn FreeBSD - Performance Tuning & Optimization

#Introduction

In the previous episode 17, you understood FreeBSD 15 and upgrade strategies. Now we enter the art of performance tuning — optimizing the system to use the resources available as efficiently as possible.

Tuning isn't about changing every parameter blindly. Good tuning starts from measurement — understanding where the bottleneck is — then changing the right parameter, and measuring again. This episode maps the measurement tools and the parameters you'll touch most often, including ZFS storage tuning.

#The Basic Principles of Tuning

Before touching any parameter, remember three principles:

Measure first, change later. Don't change sysctl without data.
Change one at a time. Parallel changes make evaluation impossible.
Make persistent only after testing. Parameters proven to work get written to sysctl.conf.

Melihat semua parameter sysctl

sysctl -a | wc -l
sysctl kern.maxfiles

FreeBSD exposes hundreds of runtime parameters. Knowing which ones are relevant is part of the craft.

#Tuning with sysctl

#Kernel and Memory Parameters

A few parameters often changed in the kern and vm categories:

Parameter kernel dan memori

sysctl kern.maxfiles=100000
sysctl kern.maxfilesperproc=50000
sysctl vm.swap_idle_enabled=1

kern.maxfiles raises the file descriptor limit — important for servers with many connections. vm.swap_idle_enabled slows the migration of idle processes to swap.

#TCP Tuning

The TCP stack can be adjusted for network workloads:

Parameter TCP

sysctl net.inet.tcp.sendbuf_max=16777216
sysctl net.inet.tcp.recvbuf_max=16777216
sysctl net.inet.tcp.mssdflt=1460

The buffer parameters determine how much data can be in transit before acknowledgement — a common bottleneck for large file transfers and many connections.

Info

Change TCP parameters only if measurements show a problem (for example, low throughput on high-latency connections). Changing buffers without data can actually waste kernel memory.

#Persisting with sysctl.conf

Parameters proven to work are written to /etc/sysctl.conf so they survive a reboot:

Membuat sysctl persisten

sysrc -f /etc/sysctl.conf kern.maxfiles=100000
sysrc -f /etc/sysctl.conf net.inet.tcp.sendbuf_max=16777216

#Tuning with loader.conf

Kernel parameters that need to be set before boot (for example, those used while the kernel starts) are configured in /boot/loader.conf:

Tuning di loader.conf

kern.maxfiles="100000"
kern.ipc.shmall="131072"

Warning

Parameters in loader.conf are applied when the kernel boots — a reboot is required to apply them. This differs from sysctl, which can be changed at runtime. Good practice: test with sysctl first, then move to loader.conf or sysctl.conf once proven.

#Monitoring: Watching the System Work

#top and systat

top shows processes and resource usage in real time, while systat provides statistics with a full-screen display:

Monitoring dengan top dan systat

top -o cpu
systat -vmstat
systat -ifstat

top -o cpu sorts by CPU usage, systat -vmstat shows virtual memory, and systat -ifstat shows interface throughput.

#vmstat and iostat

Classic tools for measuring memory and I/O:

Mengukur memori dan I/O

vmstat 1
iostat -w 1

vmstat shows memory, swap, and CPU statistics. iostat shows throughput and disk utilization per device — important for detecting storage bottlenecks.

Success

A baseline routine: vmstat 1 for memory and CPU, iostat -w 1 for disks, systat -ifstat for the network. Collect a baseline before tuning — without one, you can't judge whether a change actually helped.

#ZFS Storage Tuning

#ARC: ZFS's Memory Cache

ARC is ZFS's cache in RAM. By default, ARC uses up to half of system memory. For machines with limited memory or large application needs, cap it:

Membatasi ARC cache

sysctl vfs.zfs.arc_max=2147483648

The value above caps ARC at 2 GB. Write it to sysctl.conf to make it persistent.

Warning

Reducing ARC too drastically will hurt repeated read performance. Start with a conservative limit and monitor with zpool iostat and arcstat to find the balance between ZFS cache and application memory.

#recordsize: The Block Size

recordsize controls ZFS's logical block size — affecting performance based on your I/O pattern:

Mengatur recordsize

zfs set recordsize=16k tank/data/db
zfs set recordsize=1M tank/data/media

Databases with small random access (like PostgreSQL) suit 16k or 8k. Large streaming media data suits big blocks like 1M — verify with zfs get recordsize.

#Compression and Dedup

lz4 and zstd compression (episodes 8-9) reduce actual I/O. Make sure it stays enabled for workloads that can be compressed.

#The I/O Scheduler

FreeBSD uses a kernel-based I/O scheduler. For SSDs, make sure trim runs so long-term performance is preserved:

Memeriksa trim

zpool get autotrim

#The Right Tuning Flow

Follow a disciplined measurement cycle:

Measure a baseline with vmstat, iostat, systat.
Identify the bottleneck (CPU, memory, disk, network).
Change one relevant parameter.
Measure again and compare.
Persist what's proven to help.

Contoh siklus tuning

iostat -w 1
sysctl vfs.zfs.arc_max=2147483648
iostat -w 1
sysrc -f /etc/sysctl.conf vfs.zfs.arc_max=2147483648

#Closing

In this episode 18, you learned FreeBSD performance tuning: kernel tuning with sysctl and loader.conf, TCP and memory parameters, monitoring with top, systat, vmstat, and iostat, and ZFS storage tuning with ARC and recordsize.

Key takeaways:

Measure first with vmstat, iostat, and systat before changing parameters.
kern.maxfiles and TCP buffers are common tuning points.
Boot parameters go in loader.conf; runtime parameters in sysctl.conf.
ZFS ARC uses a lot of memory — cap it when needed with vfs.zfs.arc_max.
recordsize follows the I/O pattern: small for databases, large for streaming media.

In the next episode, episode 19, we'll cover FreeBSD as a router, firewall & network appliance — the OPNsense and NAS use cases, running the Nginx, MySQL, PostgreSQL, and Redis stack, and reliable production web server deployment on top of FreeBSD.