Learning Artix Linux - Performance & Tuning

#Introduction

A healthy system isn't enough — you want a system that works according to the characteristics of its workload. Episode 20 covers performance tuning on Artix: kernel parameters via sysctl, I/O scheduler selection, build optimization with makepkg, and monitoring tools to make sure your tuning pays off.

The main principle: measure first, then tune. Changing parameters without data only adds risk. That's why we always pair changes with monitoring tools.

#Kernel Params with sysctl

#Reading Parameters

sysctl lets you change kernel parameters at runtime and set them at boot. Read the current values:

sysctl vm.swappiness
sysctl net.ipv4.ip_forward

sysctl vm.swappiness shows how inclined the kernel is to use swap. The value 60 is the default; on desktops with plenty of RAM, 10 often feels more responsive.

#Setting Changes

Change a value temporarily for testing, then make it permanent in /etc/sysctl.d/:

sudo sysctl vm.swappiness=10
echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-tuning.conf
sudo sysctl --system

sysctl --system loads all files in /etc/sysctl.d/ and /etc/sysctl.conf. Files with a larger numeric prefix load later and win over earlier values.

#Parameters Worth Watching

For common workloads, watch vm.swappiness, net.core.somaxconn for the connection backlog, and vm.dirty_ratio for disk writes. Change one at a time and observe the impact — don't apply many changes at once.

#I/O Scheduler

#Choosing a Scheduler

The I/O scheduler decides how disk read/write requests are ordered. Modern kernels use mq-deadline for HDDs and none for SSDs/NVMe. View the active scheduler:

cat /sys/block/sda/queue/scheduler

The output of cat /sys/block/sda/queue/scheduler shows schedulers with square brackets around the active one. For modern SSDs, none is usually best because the SSD controller already manages its own queues.

#Setting via a Udev Rule

A scheduler can be set per device automatically with a udev rule in /etc/udev/rules.d/:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

This rule picks none for non-rotational disks. The ATTR{queue/scheduler}="none" assignment is applied by eudev each time a device is detected. After writing the rule, reload udev to test it.

#makepkg Optimization

#CFLAGS for Your Own Builds

When building packages (AUR, episode 15), makepkg uses the flags in /etc/makepkg.conf. CFLAGS optimized for your CPU improve the performance of locally built packages:

CFLAGS="-march=native -O2 -pipe"
CXXFLAGS="-march=native -O2 -pipe"

-march=native optimizes specifically for your CPU. Note: packages built with -march=native can't be moved to a machine with a different CPU.

#Speeding Up Builds

Parallel builds use all CPU cores. Adjust the MAKEFLAGS value in /etc/makepkg.conf:

MAKEFLAGS="-j$(nproc)"

-j$(nproc) makes makepkg use all cores. For builds that consume lots of RAM, lower the number so the system doesn't start thrashing.

#Monitoring with htop and btop

#htop: The Interactive Monitor

htop shows processes and CPU load in real time. Install and run it:

sudo pacman -S htop
htop

Inside htop, press F5 for tree view and F6 to sort. For a more modern view with GPU and disk information, try btop.

#btop: Modern and Informative

btop combines CPU, memory, disk, network, and processes on one screen:

sudo pacman -S btop
btop

btop shows real-time graphs and can sort processes. Use it as a daily tool to learn your system's load patterns.

#Sysstat and Service Logs

#Collecting Historical Data

sysstat collects system statistics periodically for trend analysis. Install and enable it:

sudo pacman -S sysstat sysstat-openrc
rc-update add sysstat default
rc-service sysstat start

Once running, data is collected into /var/log/sa/. View daily summaries with sar:

sar -u
sar -r

sar -u shows historical CPU usage, sar -r memory. This historical data is what separates good monitoring: you can see trends, not just the current state.

#Service Logs with rc-log

On OpenRC, rc-log records init script output to /var/log/rc.log. Enable it to trace boot and service problems:

rc-update add rc-log default
rc-service rc-log start
tail -f /var/log/rc.log

The output of tail -f /var/log/rc.log streams logs from started services. The combination of sysstat for trends and rc-log for services makes Artix monitoring complete.

#Conclusion

Episode 20 equipped you with tuning tools and habits: sysctl parameters, I/O schedulers for SSD/HDD, makepkg optimization with CFLAGS and MAKEFLAGS, and monitoring with htop, btop, sysstat, and rc-log.

Key takeaways:

• Measure first with monitoring, then tune.
• sysctl parameters are set in /etc/sysctl.d/ and loaded with sysctl --system.
• SSDs/NVMe use the none scheduler; HDDs use mq-deadline.
• -march=native optimizes builds for your CPU.
• htop and btop for interactive real-time monitoring.
• sysstat and rc-log provide historical data and service logs.

In the next episode, episode 21, we'll cover roadmap and community — the direction of init support and kernel development, the wiki, forums, and the IRC and Matrix channels as Artix's official learning resources.