Justerade profiler för optimering av serverarbetsbelastning

Linux standardinställningar är anpassade för kompatibilitet, inte prestanda. Tuned-daemonen levereras med fördefinierade profiler som justerar CPU-regulatorer, I/O-schemaläggare, kärnparametrar och nätverksbuffertar för att passa en specifik arbetsbelastning. Det här inlägget behandlar hur profilerna fungerar, vilken man ska välja för vanliga serverroller och hur man skapar och distribuerar anpassade profiler över en hel flotta.

Hur anpassade profiler fungerar

En profil är en katalog under /usr/lib/tuned/profiles/ (system) eller /etc/tuned/profiles/ (anpassad) som innehåller en tuned.conf fil. Konfigurationsfilen grupperar parametrar efter plugin: [cpu], [disk], [sysctl], [vm], [bootloader], och så vidare. Aktivera en profil så tillämpar tuned-daemonen alla parametrar på en gång, istället för att köra dussintals sysctl och sysfs kommandon manuellt.

Profiler kan ärva från varandra med include direktivet. throughput-performance profilen kan till exempel fungera som bas för en anpassad databasprofil som endast åsidosätter vm.swappiness inställningen Transparent Huge Pages.

tuned körs i två lägen. Statisk inställning tillämpar profilen en gång vid aktivering och lämnar systemet ifred, vilket är vad du vill ha på produktionsservrar där konsistens är viktigare än energibesparingar. Dynamisk inställning övervakar disk-, nätverks- och belastningsanvändning i realtid och justerar inställningarna direkt. Prestandaprofilerna inaktiverar dynamisk inställning som standard för att undvika övervakningsöverbelastning.

Välja rätt profil för din arbetsbelastning

tuned levererar ett dussin profiler som täcker de vanligaste arbetsbelastningarna. Välj den som matchar vad servern faktiskt gör, istället för att lämna standard balanced .

För specifika databasmotorer levereras tuned även postgresql, mssql, och oracle profiler som går längre än throughput-performance genom att justera parametrarna för delat minne och kärnans schemaläggare för dessa motorer.

På servrar med flera socklar spelar NUMA-topologin roll. Minnesåtkomst till fjärrnoder kan vara två till tre gånger långsammare än lokal åtkomst. För latenskritiska arbetsbelastningar på datorer med dubbla socklar bör du inaktivera automatisk NUMA-balansering i profilen och manuellt koppla processer till specifika noder.

Installera och tillämpa profiler

Installera tuned på RHEL, Rocky, AlmaLinux eller Fedora:

dnf install tuned
systemctl enable --now tuned

På Debian och Ubuntu heter paketet också tuned och installeras via apt. Om power-profiles-daemon redan körs, maskera det för att undvika konflikter:

systemctl mask --now power-profiles-daemon

Visa tillgängliga profiler, fråga tuned vad det rekommenderar för hårdvaran, tillämpa en profil och verifiera den:

tuned-adm list
tuned-adm recommend
tuned-adm profile throughput-performance
tuned-adm verify

Den aktiva profilen lagras i /etc/tuned/active_profile och kvarstår även efter omstart. För att ta bort all inställning helt och mäta baslinjen, kör tuned-adm off.

Skapa en anpassad profil för AI, ML och arbetsbelastningar med hög bandbredd

När standardprofilerna tar dig 90 % av vägen, skapa en anpassad profil som ärver från den närmaste matchningen och åsidosätter de återstående parametrarna. Börja med en katalog och en conf-fil:

mkdir -p /etc/tuned/ai-gpu
cat > /etc/tuned/ai-gpu/tuned.conf <<'EOF'
[main]
summary=Custom profile for GPU training with high-bandwidth networking
include=accelerator-performance
 
[cpu]
governor=performance
 
[sysctl]
kernel.numa_balancing=0
net.core.rmem_max=268435456
net.core.wmem_max=268435456
net.ipv4.tcp_rmem=4096 87380 268435456
net.ipv4.tcp_wmem=4096 65536 268435456
 
[vm]
transparent_hugepages=never
 
[bootloader]
cmdline=hugepagesz=2M hugepages=16384 <a target="_blank" rel="noopener noreferrer" href="https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit">iommu</a>=pt
EOF
 
tuned-adm profile ai-gpu

De viktigaste valen här:

• numa_balancing=0 förhindrar att kärnan migrerar minne mellan socklar under träningskörningar, en vanlig orsak till avbrott på GPU-enheter med dubbla socklar.
• Den rmem_max och tcp_rmem höjer sockelbuffertens tak till 256 MB. På 25G-, 40G- eller 100G-förbindelser mellan träningsnoder begränsar standardbuffertstorlekarna genomströmningen till långt under linjehastigheten.
• transparent_hugepages=never tar bort den latensvariation som THP orsakar för ramverk som PyTorch och TensorFlow som allokerar stora tensorer.
• iommu=pt sätter IOMMU i passthrough-läge, vilket krävs för GPU- och NIC-passthrough och minskar overhead på bare-metal DMA.

Allt under [bootloader] kräver en omstart. Efter att ha aktiverat profilen, kör tuned-adm verify för att bekräfta att körningsparametrarna tillämpas och kontrollera journalctl -u tuned om det finns några fel. Gör en prestandatest före och efter med iostat -xz, numastatoch det relevanta arbetsbelastningsverktyget (iperf3, fioeller den faktiska träningskörningen).

En avvägning som är värd att nämna uttryckligen: att inaktivera CPU-säkerhetsåtgärder ger ungefär 3–8 % prestandavinst för GPU-arbetsbelastningar men kostar 15–30 % prestanda för arbetsbelastningar med tunga systemanropsmönster. Besluta utifrån hotbilden för servern. Inom ett dedikerat träningskluster bakom en brandvägg talar beräkningarna vanligtvis för att inaktivera dem. På en värd med flera användare ska du lämna dem aktiverade.

Hantera profiler över en serverpark

Att installera tuned manuellt är inte längre genomförbart när det gäller mer än ett fåtal servrar. Ansible hanterar detta smidigt. En enda playbook installerar tuned och lägger anpassade profilkataloger under /etc/tuned/ via template modulen och tillämpar rätt profil per inventeringsgrupp.

Mappa profiler till roller i inventeringen:

• GPU- och AI-noder: accelerator-performance, eller en anpassad profil som ärver från den
• Databasserver: throughput-performance eller den motorspecifika profilen
• CDN- och edge-noder som skickar trafik med hög bandbredd: network-throughput
• API- och webbservrar bakom en lastbalanserare: network-latency
• VPS- och KVM-gäster: virtual-guest
• Hypervisor-värdar: virtual-host

Avvikelser är det verkliga driftsproblemet. Manuella sysctl ändringar, paketuppgraderingar som levereras med nya standardinställningar eller ett annat konfigurationshanteringsverktyg som tränger sig på kommer alla att leda till att inställningarna avviker från vad profilen anger. Schemalägg ett Ansible-jobb som ska köras tuned-adm active och tuned-adm verify på cron och skicka en varning vid fel. Håll utkik /var/log/tuned/tuned.log efter rader med "Verifiering misslyckades".

Slutsats

tuned eliminerar det mesta av gissningsarbetet vid inställning av kärnan och sysctl. Standardinställningarna är tillräckligt bra för allmän användning, och de arbetsbelastningsspecifika profilerna som accelerator-performance, throughput-performance, och network-throughput tar dig nästan hela vägen till optimering utan att du behöver skriva en enda konfigurationsfil.

• Välj den standardprofil som ligger närmast, kör tuned-adm verify, och gör sedan en prestandatest
• Skapa anpassade profiler genom att ärva från en standardprofil och endast ändra det du behöver
• Var noggrann med NUMA-balansering, hugepages och nätverksbuffertstorlekar på GPU- och högbandbreddsmaskiner
• Distribuera med Ansible och granska enligt ett schema för att upptäcka avvikelser

Behöver du bare-metal-kapacitet med tillräcklig bandbredd för att faktiskt kunna använda dessa inställningar? Prata med FDC om dedikerade servrar byggda för hög genomströmning och GPU-arbetsbelastningar.