Kernel tuning: sysctl, tuned, ulimit and systemd LimitNOFILE

Steps 1 to 4 run on both VMs, step 5 on rocky01, and steps 6 to 10 on rocky01 only, because they use the appsvc account from Lesson 15. Make a folder for the files you’ll keep: mkdir -p ~/lab51. The values in step 4 are the ones Kafka needs, and step 10 saves copies of them for kafka01 in Lesson 58.

1Read a few kernel parameters on both VMs

Run this:

sysctl vm.swappiness vm.max_map_count net.core.somaxconn fs.file-max fs.nr_open
cat /proc/sys/vm/swappiness

You should see something like this on rocky01:

vm.swappiness = 30
vm.max_map_count = 65530
net.core.somaxconn = 4096
fs.file-max = 9223372036854775807
fs.nr_open = 1073741816
30

And on ubu01:

vm.swappiness = 60
vm.max_map_count = 1048576
net.core.somaxconn = 4096
fs.file-max = 9223372036854775807
fs.nr_open = 1073741816
60

The cat proves sysctl is only reading a file. swappiness differs because tuned set 30 on rocky01, and max_map_count differs because Ubuntu ships a higher default. The two huge fs values are systemd’s doing; on a server they mean “no practical system-wide limit”, and the per-process limit is what you’ll tune instead.

✅ Checkpoint: You can explain why swappiness and max_map_count differ between the two VMs.

2Find where the values come from

On ubu01, run this:

grep -r max_map_count /usr/lib/sysctl.d /etc/sysctl.d
ls /etc/sysctl.d/

You should see something like this:

/usr/lib/sysctl.d/50-default.conf:vm.max_map_count = 1048576
/usr/lib/sysctl.d/55-map-count.conf:vm.max_map_count=1048576
README.sysctl

Two package files set the same value, and /etc/sysctl.d holds only a README: Ubuntu 26.04 keeps vendor settings in /usr/lib and leaves /etc to you. On rocky01, ls -l /etc/sysctl.d/ shows the link that still makes /etc/sysctl.conf work there:

lrwxrwxrwx. 1 root root 14 Oct 20 18:31 99-sysctl.conf -> ../sysctl.conf

✅ Checkpoint: You found the package file that sets vm.max_map_count on ubu01.

3Change a value now, without saving it

Run this on both VMs:

sudo sysctl -w vm.swappiness=10
cat /proc/sys/vm/swappiness

You should see this:

vm.swappiness = 10
10

The kernel uses 10 from this moment, and no file anywhere knows about it, so a reboot brings back 30 or 60. sysctl -w is how you test a value, never how you keep one. Note there are no spaces around the = sign.

✅ Checkpoint: /proc/sys/vm/swappiness shows 10 on both VMs.

4Write the Kafka-style drop-in

Paste this whole block on both VMs:

sudo tee /etc/sysctl.d/90-kafka.conf >/dev/null <<'EOF'
# Kafka-style settings (Lesson 51). Kafka docs: swap as little as possible,
# and more memory map areas for its index files.
vm.swappiness = 1
vm.max_map_count = 262144
EOF
sudo sysctl -p /etc/sysctl.d/90-kafka.conf
sudo sysctl --system | grep -E 'kafka|map-count|swappiness|max_map_count'

You should see this on ubu01:

vm.swappiness = 1
vm.max_map_count = 262144
* Applying /usr/lib/sysctl.d/55-map-count.conf ...
* Applying /etc/sysctl.d/90-kafka.conf ...
vm.max_map_count = 1048576
vm.max_map_count = 1048576
vm.swappiness = 1
vm.max_map_count = 262144

sysctl -p FILE loads one file. sysctl --system loads every file in boot order, which is the real test, because it shows whether something later overrides you. Read the last four lines: max_map_count is set to 1048576 twice by package files and then to 262144 by yours, because 90-kafka.conf sorts last. On rocky01 the list of files is different, but your two values come last there too.

Ubuntu’s 1048576 is already higher than Kafka needs, so on ubu01 the max_map_count line lowers it. That’s harmless here, but at work you’d leave that line out on Ubuntu. Read the current value before you copy a tuning file between distributions.

Try it yourself: build a sysctl drop-in for any parameter in the Command Builder.

✅ Checkpoint: sysctl vm.swappiness vm.max_map_count prints 1 and 262144 on both VMs.

5Reboot rocky01 and see what tuned does

Reboot rocky01, log in again and run:

sysctl vm.swappiness vm.max_map_count
tuned-adm active
tuned-adm recommend
grep -B4 reapply_sysctl /etc/tuned/tuned-main.conf

You should see something like this:

vm.swappiness = 1
vm.max_map_count = 262144
Current active profile: virtual-guest
virtual-guest
# Whether to reapply sysctl from /run/sysctl.d/, /etc/sysctl.d/ and
# /etc/sysctl.conf. If enabled, these sysctls will be reappliead
# after TuneD sysctls are applied, i.e. TuneD sysctls will not
# override user-provided system sysctls.
reapply_sysctl = 1

Your values survived the reboot, even though tuned’s virtual-guest profile asks for swappiness 30, and the comment in tuned-main.conf explains why. tuned-adm recommend says which profile tuned would choose for this machine. To see the others, run tuned-adm list:

Available profiles:
- accelerator-performance     - Throughput performance based tuning with disabled higher latency STOP states
- balanced                    - General non-specialized TuneD profile
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
- virtual-guest               - Optimize for running inside a virtual guest
- virtual-host                - Optimize for running KVM guests
Current active profile: virtual-guest

The list above is shortened. On a database or Kafka server, sudo tuned-adm profile throughput-performance is a common choice, and you switch back with sudo tuned-adm profile virtual-guest. Leave rocky01 on virtual-guest for this course.

✅ Checkpoint: After the reboot rocky01 shows swappiness 1, and tuned-adm active shows virtual-guest.

6See somaxconn cap a listen queue

On rocky01, start a listener that asks for a huge backlog, then look at it:

python3 -c 'import socket,time; s=socket.socket(); s.bind(("0.0.0.0",9092)); s.listen(65535); time.sleep(30)' &
sleep 1
ss -ltn 'sport = :9092'

You should see this:

State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      4096         0.0.0.0:9092      0.0.0.0:*

For a listening socket, ss shows the backlog in the Send-Q column. The program asked for 65535 and got 4096, the value of net.core.somaxconn. Raising somaxconn helps only when the application asks for more and is restarted afterwards; Nginx, for example, asks for 511 unless you set backlog= on its listen line.

The listener stops on its own after 30 seconds.

✅ Checkpoint: Send-Q shows 4096 for port 9092.

7Read and change your own open-files limit

On rocky01, in your SSH session, run this:

ulimit -Sn
ulimit -Hn
grep 'open files' /proc/$$/limits
ulimit -Sn 4096
ulimit -Sn
ulimit -Hn
ulimit -Sn 600000

You should see something like this:

1024
524288
Max open files            1024                 524288               files
4096
524288
-bash: ulimit: open files: cannot modify limit: Invalid argument

$$ is your shell’s PID, so /proc/$$/limits shows its limits with both columns. You raised the soft value to 4096 without root, because it stayed under the hard value. Asking for more than the hard value is refused.

Use -Sn and -Hn on purpose: plain ulimit -n 2048 sets both, lowering your hard limit for the rest of the session.

✅ Checkpoint: Your soft limit is 4096 and your hard limit is still 524288.

8Create a test service and read its limits

Paste this whole block on rocky01:

sudo tee /usr/local/bin/saat-fdtest.py >/dev/null <<'EOF'
#!/usr/bin/python3
# saat-fdtest.py: opens N files and keeps them open, like a busy broker (Lesson 51)
import resource
import sys
import time

want = int(sys.argv[1]) if len(sys.argv) > 1 else 500
soft, hard = resource.getrlimit(resource.RLIMIT_NOFILE)
print(f"open-files limit: soft={soft} hard={hard}, opening {want} files", flush=True)
held = [open("/dev/null") for _ in range(want)]
print(f"holding {len(held)} open files", flush=True)
time.sleep(86400)
EOF
sudo chmod 755 /usr/local/bin/saat-fdtest.py
echo 'FILES=500' | sudo tee /etc/saat-fdtest.env
sudo tee /etc/systemd/system/saat-fdtest.service >/dev/null <<'EOF'
[Unit]
Description=Open-files test service (Lesson 51)

[Service]
User=appsvc
EnvironmentFile=/etc/saat-fdtest.env
ExecStart=/usr/local/bin/saat-fdtest.py $FILES

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl start saat-fdtest
sleep 2; sudo journalctl -u saat-fdtest -n 2 -o cat --no-pager

You should see this:

FILES=500
open-files limit: soft=1024 hard=524288, opening 500 files
holding 500 open files

Now ask systemd and the kernel what limit the service got:

systemctl show saat-fdtest -p LimitNOFILE -p LimitNOFILESoft
grep 'open files' /proc/$(systemctl show -p MainPID --value saat-fdtest)/limits
systemctl show -p DefaultLimitNOFILE -p DefaultLimitNOFILESoft

You should see something like this:

LimitNOFILE=524288
LimitNOFILESoft=1024
Max open files            1024                 524288               files
DefaultLimitNOFILE=524288
DefaultLimitNOFILESoft=1024

The service got 1024 soft and 524288 hard, systemd’s defaults, shown by the last command. Your shell’s 4096 from step 7 made no difference, because systemd started this process, not your shell. 500 files fit under 1024, so it runs.

✅ Checkpoint: The service holds 500 files and its /proc limits line shows 1024 and 524288.

9Give the service its own limit with a drop-in

Paste this whole block:

sudo mkdir -p /etc/systemd/system/saat-fdtest.service.d
sudo tee /etc/systemd/system/saat-fdtest.service.d/limits.conf >/dev/null <<'EOF'
[Service]
LimitNOFILE=100000
EOF
sudo systemctl daemon-reload
sudo systemctl restart saat-fdtest
systemctl show saat-fdtest -p LimitNOFILE -p LimitNOFILESoft
grep 'open files' /proc/$(systemctl show -p MainPID --value saat-fdtest)/limits

You should see this:

LimitNOFILE=100000
LimitNOFILESoft=100000
Max open files            100000               100000               files     

One value sets both soft and hard; write LimitNOFILE=65536:100000 if you want them different. The drop-in sits next to the unit, so a package update that replaces the unit file keeps your change. sudo systemctl edit saat-fdtest opens an editor on a drop-in called override.conf in the same folder and runs daemon-reload for you when you save.

Try it yourself: build the LimitNOFILE drop-in for any service in the Command Builder.

✅ Checkpoint: /proc/PID/limits for the service shows 100000 in both columns.

10Save the Kafka files for Lesson 58 and tidy up

On rocky01:

cp /etc/sysctl.d/90-kafka.conf ~/lab51/
cp /etc/systemd/system/saat-fdtest.service.d/limits.conf ~/lab51/kafka-limits.conf
sudo rm /etc/sysctl.d/90-kafka.conf
sudo sysctl -w vm.swappiness=30 vm.max_map_count=65530
ls ~/lab51

On ubu01:

sudo rm /etc/sysctl.d/90-kafka.conf
sudo sysctl -w vm.swappiness=60 vm.max_map_count=1048576

Deleting a drop-in doesn’t change the running value; the kernel keeps whatever was written last until you set it again or reboot. That’s why each VM gets an explicit sysctl -w back to its own default. Leave the test service running, the Break-It part uses it.

✅ Checkpoint: ~/lab51 on rocky01 holds 90-kafka.conf and kafka-limits.conf, and swappiness is back to 30 on rocky01 and 60 on ubu01.