Większość z nas szuka łatwych do wdrożenia optymalizacji, które przynoszą szybkie i korzystne rezultaty. Poniżej znajduje się zestaw optymalizacji, które można wdrożyć w weekendy i które przyniosą natychmiastowe korzyści użytkownikom Proxmox w domowych laboratoriach. Mogą one poprawić wydajność, stabilność, a nawet wydłużyć żywotność sprzętu.
Zanim zaczniesz, mała przestroga
Przed wprowadzeniem jakichkolwiek poważniejszych zmian, pamiętaj o wykonaniu co najmniej następujących czynności:
- Utwórz kopię zapasową pliku konfiguracyjnego przed jego edycją.
- Zastosuj zmiany najpierw na jednym węźle, jeśli jest to klaster.
- Uruchom ponownie system tylko podczas przerwy konserwacyjnej.
- Po każdej zmianie w pliku sysctl sprawdź, czy plik został faktycznie załadowany.
Oto lista poleceń „punktów kontrolnych”, które pomogą Ci zapisać kilka ważnych ustawień konfiguracyjnych.
|
1 2 3 4 5 6 7 8 |
# Snapshot aktualnego stanu konfiguracji (backup z datą) cp -a /etc/sysctl.d /etc/sysctl.d.bak.$(date +%F) cp -a /etc/apt/apt.conf.d /etc/apt/apt.conf.d.bak.$(date +%F) cp -a /etc/logrotate.conf /etc/logrotate.conf.bak.$(date +%F) # Wyświetlenie ostatnich 50 linii z aktywnych ustawień sysctl sysctl --system | tail -n 50 |
Pomiń pobieranie dodatkowych języków APT
To ulepszenie przyspiesza aktualizacje i oszczędza trochę miejsca na dysku. Na serwerach zazwyczaj nie są potrzebne indeksy tłumaczeń dla wielu różnych języków.
|
1 |
echo 'Acquire::Languages "none";' | tee /etc/apt/apt.conf.d/99-disable-translations |
Sprawdź, czy zostało to zastosowane:
|
1 |
cat /etc/apt/apt.conf.d/99-disable-translations |
Wymuś użycie APT w IPv4 (gdy protokół IPv6 powoduje powolne lub niestabilne aktualizacje)
Powiedzmy sobie szczerze, większość z nas nie ma w domowych laboratoriach implementacji protokołu IPv6. Jeśli konfiguracja dostawcy usług internetowych, routera lub serwera DNS sprawia, że IPv6 jest zawodne, może to powodować problemy lub spowalniać działanie. Możemy jednak temu zaradzić, wymuszając IPv4, co natychmiast przywróci spójność aktualizacji.
|
1 |
echo 'Acquire::ForceIPv4 "true";' | tee /etc/apt/apt.conf.d/99force-ipv4 |
Sprawdź, czy zostało zastosowane:
|
1 |
cat /etc/apt/apt.conf.d/99force-ipv4 |
Aby cofnąć:
|
1 |
sudo rm -f /etc/apt/apt.conf.d/99force-ipv4 |
Skonfiguruj automatyczne ponowne uruchomienie kernel panic
Kernel panic zdarza się raczej rzadko. Ale zdarza się. Host z kernel panic i utknięciem w nim to jedna z najgorszych rzeczy, jakie mogą się zdarzyć, zwłaszcza gdy jesteś poza domem i nie możesz zareagować.
To pozwala skonfigurować go tak, aby automatycznie się restartował:
|
1 2 3 4 5 |
echo "kernel.panic = 10" | tee /etc/sysctl.d/99-kernelpanic.conf echo "kernel.panic_on_oops = 1" | tee -a /etc/sysctl.d/99-kernelpanic.conf sysctl -p /etc/sysctl.d/99-kernelpanic.conf |
Sprawdź, czy zostało to zastosowane:
|
1 |
sysctl kernel.panic kernel.panic_on_oops |
Zwiększ limity systemowe
To praktyczne ulepszenie dla hostów obsługujących wiele kontenerów, narzędzi monitorujących lub innych urządzeń, które utrzymują wiele otwartych plików. Może to również pomóc uniknąć nietypowych awarii w skrajnych przypadkach.
|
1 2 3 |
echo "fs.inotify.max_user_watches = 1048576" | tee /etc/sysctl.d/99-maxwatches.conf echo "* soft nofile 1048576" | tee /etc/security/limits.d/99-limits.conf sysctl --system |
fs.inotify.max_user_watches – maksymalna liczba watchy inotify na użytkownika.
Zapobiega błędom typu:
|
1 |
ENOSPC: System limit for number of file watchers reached |
- Bardzo często wymagane przez:
- Docker / Kubernetes
- Node.js / webpack / Vite
- VS Code
- Elasticsearch
- Zabbix / Prometheus
- Systemy CI/CD
echo „* soft nofile 1048576” – ustawia miękki limit otwartych plików:
Wjaśnienie składowych polecenia:
*– dla wszystkich użytkownikówsoft– miękki limit (może być podniesiony dohard)nofile– maksymalna liczba otwartych deskryptorów plików1048576– do 1 miliona plików/socketów
Zapobiega błędom:
|
1 |
Too many open files |
- Krytyczne dla:
- serwerów aplikacyjnych
- baz danych
- proxy (nginx, HAProxy)
- systemów monitoringu
- dużych środowisk produkcyjnych
Weryfikacja dodania konfiguracji:
|
1 2 |
sysctl fs.inotify.max_user_watches ulimit -n |
Popraw generowanie entropii za pomocą haveged
Serwery typu headless oraz środowiska zwirtualizowane bardzo często zmagają się z problemem niskiej entropii. Choć brzmi to dość enigmatycznie, w praktyce jest to jeden z częstszych powodów dziwnych opóźnień i „zawieszeń” w systemach serwerowych.
W systemach Linux, takich jak Proxmox VE, entropia oznacza ilość dostępnej losowości, czyli zdolność systemu do generowania nieprzewidywalnych danych. Jest ona wykorzystywana zawsze wtedy, gdy system musi stworzyć coś, co z definicji nie może być przewidywalne: klucze szyfrujące, certyfikaty TLS, klucze SSH, bezpieczne połączenia sieciowe, tokeny sesji czy inne elementy kryptograficzne. Bez odpowiedniej ilości entropii system nie jest w stanie wykonać tych operacji w bezpieczny sposób.
System operacyjny stale próbuje uzupełniać pulę entropii, obserwując różnego rodzaju nieprzewidywalne zdarzenia. Na typowym komputerze desktopowym są to między innymi ruchy myszy, naciśnięcia klawiszy, opóźnienia operacji dyskowych czy przerwania sprzętowe. Problem pojawia się wtedy, gdy tych zdarzeń praktycznie nie ma.
Właśnie dlatego serwery headless oraz maszyny wirtualne są szczególnie narażone na niski poziom entropii. Nie ma tam klawiatury ani myszy, interakcja użytkownika jest minimalna, a sprzęt często działa w bardzo powtarzalny sposób. W efekcie pula entropii szybko się wyczerpuje, a system zaczyna czekać na nowe źródła losowości. Objawia się to długim generowaniem kluczy SSH, opóźnionym startem usług TLS, wolnym uruchamianiem maszyn wirtualnych lub pozornie losowymi lagami przy operacjach kryptograficznych.
Jednym z najczęściej stosowanych i najszybszych rozwiązań tego problemu jest instalacja haveged. Jest to demon, który generuje dodatkową entropię, wykorzystując niestabilności czasowe i zachowanie procesora. Dzięki temu system nie musi blokować się w oczekiwaniu na losowość pochodzącą z fizycznych zdarzeń, których na serwerze headless po prostu nie ma. W praktyce haveged bardzo często „odblokowuje” system i eliminuje problemy z długim oczekiwaniem na operacje kryptograficzne.
Zainstalowanie haveged to klasyczne rozwiązanie „zapobiegające zawieszaniu się”:
|
1 2 3 4 5 6 7 8 9 10 11 |
apt-get install -y haveged tee /etc/default/haveged >/dev/null <<'EOF' DAEMON_ARGS="-w 1024" EOF systemctl daemon-reload systemctl enable haveged systemctl start haveged |
Sprawdź, czy jest zainstalowany:
|
1 2 3 |
cat /proc/sys/kernel/random/entropy_avail systemctl status haveged --no-pager |
Zoptymalizuj zarządzanie pamięcią (może być teraz ważniejsze niż kiedykolwiek)
Nawet w dzisiejszych komputerach wprowadzono pewne poprawki, które pomagają złagodzić zdarzenia związane z obciążeniem pamięci. W węzłach z małą ilością pamięci RAM te konfiguracje pomagają utrzymać responsywność komputera nawet przy bardzo małej ilości pamięci:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
tee /etc/sysctl.d/99-memory.conf >/dev/null <<'EOF' # Balanced Memory Optimization vm.swappiness = 10 vm.dirty_ratio = 15 vm.dirty_background_ratio = 5 vm.overcommit_memory = 1 vm.max_map_count = 65530 EOF # Enable memory compaction if supported by the system if [ -f /proc/sys/vm/compaction_proactiveness ]; then echo "vm.compaction_proactiveness = 20" | tee -a /etc/sysctl.d/99-memory.conf fi sysctl -p /etc/sysctl.d/99-memory.conf |
Weryfikacja ustawień:
|
1 |
sysctl vm.swappiness vm.dirty_ratio vm.dirty_background_ratio vm.overcommit_memory vm.max_map_count |
Zastosuj optymalizacje sieciowe sysctl
Jeśli masz duży ruch sieciowy, w tym duże sieci pamięci masowej, duży ruch między maszynami wirtualnymi w obrębie centrum danych lub chcesz mieć ściślejszą sieć, zapoznaj się z tymi poprawkami:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
tee /etc/sysctl.d/99-network-performance.conf >/dev/null <<'EOF' # Proxmox-safe network performance tuning # Core network buffers net.core.netdev_max_backlog = 8192 net.core.optmem_max = 8192 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.core.somaxconn = 8151 # IPv4 hardening net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.log_martians = 0 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.log_martians = 0 net.ipv4.conf.default.rp_filter = 1 # ICMP sanity net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 # Ephemeral port range net.ipv4.ip_local_port_range = 1024 65535 # TCP behavior tuning net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_keepalive_time = 240 net.ipv4.tcp_keepalive_intvl = 30 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_limit_output_bytes = 65536 net.ipv4.tcp_mtu_probing = 1 net.ipv4.tcp_rfc1337 = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_syn_retries = 3 net.ipv4.tcp_synack_retries = 2 # TCP memory buffers net.ipv4.tcp_rmem = 8192 87380 16777216 net.ipv4.tcp_wmem = 8192 65536 16777216 # UNIX socket queue depth net.unix.max_dgram_qlen = 4096 EOF # Apply all sysctl settings cleanly sysctl --system |
Włącz TCP BBR i szybkie otwieranie
Poniżej znajduje się poprawka, która może pomóc w zmniejszeniu przepustowości i opóźnień w określonych warunkach. Może to być pomocne w przypadku dłuższych łączy RTT i przeciążonych ścieżek sieciowych.
|
1 2 3 4 5 6 7 8 9 |
echo "net.core.default_qdisc = fq" | tee -a /etc/sysctl.d/99-tcp-bbr.conf echo "net.ipv4.tcp_congestion_control = bbr" | tee -a /etc/sysctl.d/99-tcp-bbr.conf echo "net.ipv4.tcp_fastopen = 3" | tee -a /etc/sysctl.d/99-tcp-fastopen.conf modprobe tcp_bbr sysctl -p /etc/sysctl.d/99-tcp-bbr.conf sysctl -p /etc/sysctl.d/99-tcp-fastopen.conf |
Weryfikacja zmian w konfiguracji:
|
1 2 3 |
sysctl net.ipv4.tcp_congestion_control lsmod | grep bbr || true |
Zoptymalizuj długość kolejki kart sieciowych i uczyń ją trwałą
To przydatna drobna poprawka, gdy zauważysz wzrosty lub spadki obciążenia lub po prostu chcesz zwiększyć głębokość kolejki dla zajętego interfejsu.
Znajdź swój interfejs za pomocą następującego polecenia:
|
1 |
ip link show |
Następnie uruchom poniższy kod, używając interfejsu znalezionego w powyższym poleceniu. W tym przypadku używam ens192.
|
1 2 3 4 5 6 |
ip link set ens192 txqueuelen 10000 echo 'ACTION=="add", SUBSYSTEM=="net", KERNEL=="ens192", RUN+="/sbin/ip link set ens192 txqueuelen 10000"' | tee /etc/udev/rules.d/60-net-txqueue.rules echo 'net.ipv4.tcp_timestamps = 1' | tee -a /etc/sysctl.d/99-network-performance.conf sysctl -p /etc/sysctl.d/99-network-performance.conf |
Weryfikacja ustawień:
|
1 2 3 |
ip -s link show ens192 | head -n 20 cat /etc/udev/rules.d/60-net-txqueue.rules |
Zmodyfikuj funkcję logrotate, aby logi nie pochłaniały powoli dysku głównego
To moim zdaniem jedno z najbardziej niedocenianych rozwiązań typu „ustaw i zapomnij”. Poniżej znajduje się kopia zapasowa konfiguracji i zastąpienie jej czystą, dzienną zasadą rotacji.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
#!/usr/bin/env bash # Configure logrotate for Proxmox set -euo pipefail ROTATE_DAYS="${ROTATE_DAYS:-14}" if [[ "${EUID:-$(id -u)}" -ne 0 ]]; then echo "ERROR: Please run as root (use sudo)." >&2 exit 1 fi # Backup existing config cp /etc/logrotate.conf "/etc/logrotate.conf.bak.$(date +%F_%H%M%S)" # Create new config cat > /etc/logrotate.conf <<EOF # Proxmox logrotate configuration daily rotate ${ROTATE_DAYS} create compress delaycompress dateext missingok notifempty sharedscripts include /etc/logrotate.d /var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 } /var/log/btmp { missingok monthly create 0660 root utmp rotate 1 } EOF # Validate if ! logrotate -d /etc/logrotate.conf >/dev/null 2>&1; then echo "ERROR: Config validation failed!" logrotate -d /etc/logrotate.conf exit 1 fi echo " Logrotate configured: ${ROTATE_DAYS} days retention" echo " To test: logrotate -f /etc/logrotate.conf" |
Uruchom test:
|
1 |
logrotate -f /etc/logrotate.conf |
Log2RAM (dla dysków SSD dla konsumentów)
Wielu z nas korzysta z konsumenckich dysków SSD w domowych laboratoriach. Możemy ograniczyć częste zapisy logów z tych dysków, zapisując je w pamięci RAM i okresowo synchronizując z dyskiem. Pomaga to wydłużyć żywotność tych dysków SSD, zatrzymując większość zapisów.
Sprawdź poniższy skrypt BASH, który zainstaluje Log2RAM i skonfiguruje go dla Proxmox. Przetestuj w swoim laboratorium lub węźle testowym przed zastosowaniem w środowisku produkcyjnym.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
#!/usr/bin/env bash # Install and configure Log2RAM on Proxmox set -euo pipefail LOG2RAM_SIZE="${LOG2RAM_SIZE:-256M}" JOURNAL_MAX_USE="${JOURNAL_MAX_USE:-50M}" if [[ "${EUID:-$(id -u)}" -ne 0 ]]; then echo "ERROR: Please run as root (use sudo)." >&2 exit 1 fi # Validate size formats if ! [[ "$LOG2RAM_SIZE" =~ ^[0-9]+[KMG]$ ]] || ! [[ "$JOURNAL_MAX_USE" =~ ^[0-9]+[KMG]$ ]]; then echo "ERROR: Invalid size format. Use format like 256M, 512M, 1G" >&2 exit 1 fi TMPDIR="$(mktemp -d)" trap "rm -rf $TMPDIR" EXIT # Install dependencies echo "[log2ram] Installing dependencies..." export DEBIAN_FRONTEND=noninteractive apt-get update -y apt-get install -y rsync curl ca-certificates # Check if already installed if command -v log2ram >/dev/null 2>&1 || systemctl list-unit-files | grep -q "^log2ram\.service"; then echo "[log2ram] Already installed, skipping download" else echo "[log2ram] Downloading and installing..." curl -fsSL -o "$TMPDIR/log2ram.tar.gz" \ "https://github.com/azlux/log2ram/archive/refs/heads/master.tar.gz" tar -xzf "$TMPDIR/log2ram.tar.gz" -C "$TMPDIR" cd "$TMPDIR"/log2ram-* && bash ./install.sh </dev/null fi # Configure log2ram if [[ -f /etc/log2ram.conf ]]; then cp /etc/log2ram.conf "/etc/log2ram.conf.bak.$(date +%F_%H%M%S)" sed -i -E "s|^[#[:space:]]*SIZE=.*|SIZE=${LOG2RAM_SIZE}|" /etc/log2ram.conf sed -i -E "s|^[#[:space:]]*USE_RSYNC=.*|USE_RSYNC=true|" /etc/log2ram.conf echo "[log2ram] Configured: SIZE=${LOG2RAM_SIZE}, USE_RSYNC=true" fi # Configure journald limits cp /etc/systemd/journald.conf "/etc/systemd/journald.conf.bak.$(date +%F_%H%M%S)" sed -i -E "s|^[#[:space:]]*SystemMaxUse=.*|SystemMaxUse=${JOURNAL_MAX_USE}|" /etc/systemd/journald.conf sed -i -E "s|^[#[:space:]]*RuntimeMaxUse=.*|RuntimeMaxUse=${JOURNAL_MAX_USE}|" /etc/systemd/journald.conf # Enable and start systemctl daemon-reload systemctl enable log2ram systemctl start log2ram systemctl restart systemd-journald echo " Log2RAM installed and configured" echo " SIZE=${LOG2RAM_SIZE}, JOURNAL_MAX_USE=${JOURNAL_MAX_USE}" echo " Reboot to fully activate tmpfs mount for /var/log" |
Trwałe nazewnictwo interfejsów sieciowych (zapobieganie zmianie nazw interfejsów)
Oto proste i czytelne podejście polegające na utworzeniu pliku łącza systemd, który pasuje do adresu MAC karty sieciowej i ustawia stabilną nazwę.
Przykładowy przepływ pracy:
Najpierw zidentyfikuj adres MAC:
|
1 |
ip link |
Następnie utwórz plik systemd .link (zamień adres MAC i żądaną nazwę):
|
1 2 3 4 5 6 7 |
tee /etc/systemd/network/10-lan.link >/dev/null <<'EOF' [Match] MACAddress=AA:BB:CC:DD:EE:FF [Link] Name=lan0 EOF |
Na koniec należy ponownie uruchomić komputer, aby zastosować wprowadzone zmiany:
|
1 |
reboot |
Następnie zaktualizuj /etc/network/interfaces (lub konfigurację sieciową Proxmox), aby użyć lan0.
Podsumowanie
Oto kilka poprawek, które warto wprowadzić w ten weekend na swoim hoście Proxmox. Szczególnie w domowym laboratorium, znajdziesz tu przydatne elementy, takie jak modyfikacja Log2RAM, która pomaga zapobiegać przedwczesnemu zużyciu dysków SSD klasy konsumenckiej. Wiele poprawek sieciowych również jest przydatnych.
Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.
Link do formularza tutaj: https://beitadmin.pl/pomysly
Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).
Swietny artykul, wiecej tresci o Proxmoxie byloby super 🙂
Podczas optymalizacji Log2RAM dostałem komunikat :
Job for log2ram.service failed because the control process exited with error code.
See „systemctl status log2ram.service” and „journalctl -xeu log2ram.service” for details.
w analizie pomogła komenda
journalctl -u log2ram.service –no-pager | tail -n 20
dająca wynik
ERROR: RAM disk for „/var/hdd.log/” too small. Can’t sync.
Po zmniejszeniu logu
journalctl –vacuum-time=2d
wszystko ruszyło.
Dzięki Pomocny Skrypt.