Profili ottimizzati per l’ottimizzazione del carico di lavoro dei server Linux

Profili ottimizzati per l’ottimizzazione del carico di lavoro dei server

Le impostazioni predefinite di Linux sono ottimizzate per la compatibilità, non per le prestazioni. Il demone tuned fornisce profili predefiniti che regolano i regolatori della CPU, gli scheduler I/O, i parametri del kernel e i buffer di rete per adattarsi a un carico di lavoro specifico. Questo articolo spiega come funzionano i profili, quale scegliere per i ruoli server più comuni e come creare e distribuire profili personalizzati su un parco server.

Come funzionano i profili ottimizzati

Un profilo è una directory all’interno /usr/lib/tuned/profiles/ (sistema) o /etc/tuned/profiles/ (personalizzata) contenente un tuned.conf file. Il file di configurazione raggruppa i parametri per plugin: [cpu], [disk], [sysctl], [vm], [bootloader], e così via. Attivando un profilo, il demone di tuned applica tutti i parametri in un’unica operazione, anziché eseguire decine di sysctl e sysfs comandi manualmente.

I profili possono ereditare l'uno dall'altro tramite la include . Il throughput-performance , ad esempio, può fungere da base per un profilo di database personalizzato che sovrascriva solo vm.swappiness l’impostazione delle Transparent Huge Pages.

tuned funziona in due modalità. L’ottimizzazione statica applica il profilo una sola volta all’attivazione e non interviene più sul sistema, il che è l’ideale sui server di produzione dove la coerenza è più importante del risparmio energetico. L’ottimizzazione dinamica monitora in tempo reale l’utilizzo del disco, della rete e del carico e regola le impostazioni al volo. I profili di prestazioni disabilitano l’ottimizzazione dinamica per impostazione predefinita per evitare il sovraccarico dovuto al monitoraggio.

Scegliere il profilo giusto per il proprio carico di lavoro

tuned offre una dozzina di profili che coprono i carichi di lavoro più comuni. Scegli quello che corrisponde all’attività effettiva del server, anziché lasciare il balanced predefinito.

Per specifici motori di database, tuned viene fornito anche postgresql, mssqle oracle profili che vanno oltre throughput-performance ottimizzando i parametri della memoria condivisa e dello scheduler del kernel per tali motori.

Sui server multi-socket, la topologia NUMA è importante. L’accesso alla memoria dei nodi remoti può essere da due a tre volte più lento rispetto all’accesso locale. Per i carichi di lavoro in cui la latenza è critica su sistemi dual-socket, disabilitare il bilanciamento NUMA automatico nel profilo e associare manualmente i processi a nodi specifici.

Installazione e applicazione dei profili

Installare tuned su RHEL, Rocky, AlmaLinux o Fedora:

dnf install tuned
systemctl enable --now tuned

Su Debian e Ubuntu il pacchetto si chiama anch’esso tuned e si installa tramite apt. Se power-profiles-daemon è già in esecuzione, nascondilo per evitare conflitti:

systemctl mask --now power-profiles-daemon

Elencare i profili disponibili, chiedere a tuned quale profilo consiglia per l’hardware, applicare un profilo e verificarlo:

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

Il profilo attivo è memorizzato in /etc/tuned/active_profile e rimane attivo anche dopo il riavvio. Per rimuovere completamente le impostazioni di ottimizzazione e misurare il valore di riferimento, eseguire tuned-adm off.

Creazione di un profilo personalizzato per carichi di lavoro di IA, ML e a elevata larghezza di banda

Quando i profili predefiniti ti consentono di raggiungere il 90% dell’obiettivo, crea un profilo personalizzato che erediti le impostazioni dal profilo più simile e sovrascriva i parametri rimanenti. Inizia con una directory e un file di configurazione:

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

Le scelte chiave in questo caso:

• numa_balancing=0 impedisce al kernel di migrare la memoria tra i socket durante le sessioni di addestramento, una causa comune di rallentamenti sui sistemi GPU a doppio socket.
• Il rmem_max e tcp_rmem aumentano il limite massimo del buffer del socket a 256 MB. Su interconnessioni da 25G, 40G o 100G tra i nodi di addestramento, le dimensioni predefinite del buffer limitano la velocità di trasmissione ben al di sotto della velocità di linea.
• transparent_hugepages=never elimina il jitter di latenza causato da THP per framework come PyTorch e TensorFlow che allocano tensori di grandi dimensioni.
• iommu=pt imposta IOMMU in modalità passthrough, necessaria per il passthrough di GPU e NIC, e riduce l’overhead sul DMA bare-metal.

Qualsiasi operazione [bootloader] richiede un riavvio. Dopo aver attivato il profilo, eseguire tuned-adm verify per confermare che i parametri di runtime siano stati applicati e verificare journalctl -u tuned la presenza di eventuali errori. Eseguire un benchmark prima e dopo con iostat -xz, numastate lo strumento di carico di lavoro pertinente (iperf3, fio, oppure l’effettiva sessione di addestramento).

Un compromesso che vale la pena chiarire: la disabilitazione delle misure di sicurezza della CPU comporta un guadagno di circa il 3-8% sui carichi di lavoro della GPU, ma comporta una perdita del 15-30% sui carichi di lavoro con modelli di chiamate di sistema intensivi. Decidere in base al modello di minaccia del sistema. All’interno di un cluster di addestramento dedicato protetto da un firewall, i calcoli di solito favoriscono la loro disabilitazione. Su un host multi-tenant, lasciatele attive.

Gestione dei profili su un parco server

L’applicazione manuale di `tuned` non è più praticabile quando il numero di server supera una manciata. Ansible gestisce questa situazione in modo efficiente. Un unico playbook installa `tuned` e crea le directory dei profili personalizzati in /etc/tuned/ tramite il template modulo, e applica il profilo corretto per ciascun gruppo di inventario.

Mappare i profili ai ruoli nell’inventario:

• Nodi GPU e AI: accelerator-performance, oppure un profilo personalizzato che ne erediti le impostazioni
• Server di database: throughput-performance oppure il profilo specifico del motore
• Nodi CDN e edge che gestiscono traffico ad alta larghezza di banda: network-throughput
• Server API e web dietro un bilanciatore di carico: network-latency
• VPS e macchine guest KVM: virtual-guest
• Host di hypervisor: virtual-host

La deriva è il vero problema operativo. Le modifiche manuali sysctl , gli aggiornamenti dei pacchetti che introducono nuove impostazioni predefinite o l’intervento di un altro strumento di gestione della configurazione su Tuned causeranno tutti una divergenza delle impostazioni rispetto a quanto specificato nel profilo. Pianifica l’esecuzione di un processo Ansible tuned-adm active e tuned-adm verify tramite cron e invia un avviso in caso di errori. Controlla /var/log/tuned/tuned.log le righe "Verification failed".

Conclusione

tuned elimina gran parte delle incertezze dalla messa a punto del kernel e di sysctl. Le impostazioni predefinite sono sufficienti per un uso generico, mentre i profili specifici per il carico di lavoro, come accelerator-performance, throughput-performance, e network-throughput consentono di ottenere un'ottimizzazione quasi completa senza dover scrivere un singolo file di configurazione.

• Scegliete il profilo predefinito più simile alle vostre esigenze, eseguite tuned-adm verify, quindi esegui il benchmark
• Crea profili personalizzati ereditando da un profilo predefinito e sovrascrivendo solo ciò che ti serve
• Presta particolare attenzione al bilanciamento NUMA, alle pagine di grandi dimensioni e alle dimensioni dei buffer di rete su sistemi con GPU e a elevata larghezza di banda
• Esegui la distribuzione con Ansible ed effettua controlli periodici per individuare eventuali scostamenti

Hai bisogno di capacità bare-metal con margine di larghezza di banda sufficiente per utilizzare effettivamente queste impostazioni? Rivolgiti a FDC per server dedicati progettati per carichi di lavoro ad alta produttività e basati su GPU.