Swap-Linux e Memoria Virtuale-Windows

SALVE FORUM…Un problema legato all’utilizzo intensivo dello swap…
ho riscontrato una sensibile differenza tra lo swap di Linux e la Virtual-Memory di Windows…in dual-boot Windows 7 e Fedora 23.su un PC fisso con processore Athlon X2 e 8 GB di RAM .facendo girare sui due sistemi operativi uno stesso programma C che legge da un file un numero molto grande 5 Miliardi di interi per separarli in intervalli , e quindi ristamparli su un secondo file…è necessario un uso intensivo (circa 12.5 GB) dello swap su LINUX e della Memoria Virtuale su Windows.
Ho questo strano problema…quando il programma ha gia’ separato tutti e 5 i miliardi negli intervalli prefissati inizia la stampa sequenziale su file del vettore di circa 1000000 di interi che contiene l’intervallo da stampare, e che si ripete 5000 volte, perche’ ho 5000 intervalli da stampare. per rendermi conto da subito della velocità con cui procede la stampa ogni 50 vettori stampati mando su schermo un messaggio di notifica …allora:

SU WINDOWS 7 : OGNI 10 secondi sono stampati 50 vettori - in 1000 secondi il programma termina
SU LINUX :in 3minuti e 30 secondi sono stampati 50 vettori ->INACCETTABILE…TROPPA DIFFERENZA NELLA VELOCITA’ DI STAMPA!

da tenere presente che il problema è intrinsecamente legato all’uso intensivo dello swap…perche se faccio stampare prima che la RAM si riempie e si procede sullo swap-Linux o Memoria Virtuale-WINDOWS i tempi di stampa sono gli stessi!..il codice dove Linux rallenta è un banale ciclo for che riporto di seguito

        for(k=0;k<5000;k++){fwrite(V[k], sizeof(int), N[k], ind_file);free(V[k]);}

i V[k] sono indirizzi di vettori di tipo int…allocati dinamicamente e successivamente riempiti con gli interi (5 Miliardi) letti da un file di input…dopo il caricamento dei primi 2.5 Miliardi sui suddetti vettori, la RAM è piena e inizia a crescere lo swap utilizzato …precisamente 8.5 GB di swap…quando inizia quel ciclo for di stampa e rilascio della memoria su V[k]…la differenza tra Windows e Linux mi pare importante…al punto da sensibilizzare i progettisti del Kernel Linux sul problema…se trovate anche voi del FORUM lo stesso risultato sui vostri PC…
P.S Ho postato lo stesso problema anche sul forum di UBUNTU…un tizio mi ha risposto che potrebbe dipendere dal fatto che le API di Windows sono velocissime…mentre lo swap Linux è lento perche’ usa la segmentazione …non potrebbe essere qualche parametro nella directory /proc/sys/vm…che non è impostato correttamente per stampare dati che sono contenuti nella partizione di swap?

Tanto per cominciare potresti controllare come viene utilizzata la swap

cat /proc/sys/vm/swappiness

Di default dovrebbe restituirti un valore pari a 60, il che vuol dire che il sistema utilizza la swap quando la RAM risulta occupata al 40% della sua capacità.
Magari, diminuendo l’utilizzo della swap, dovresti incorrere meno in questo tipo di problemi… tentar non nuoce.

Prova ad editare, con un qualsisi editor testuale, il file /etc/sysctl.conf (ovviamente per apportare le modifiche al file, deve essere modificato con i privilegi di amministratore) ed aggiungendo alla fine del file la seguente linea

vm.swappiness = 10

Salva le modifiche al file e riavvia il PC.

Questa modifica serve ad informare il sistema che deve utilizzare la swap solo nel caso in cui la RAM sia utilizzata per il 90%

Ricordo brevemente che /etc/sysctl.conf oggi è più che altro un placeholder ove si ricordano i nuovi percorsi accettati da systemd. Non è più il luogo raccomandato ove scrivere modifiche; il servizio systemd-sysctl.service (man 5 sysctl.d) legge solo dalle seguenti posizioni:

  • /etc/sysctl.d/*.conf
  • /run/sysctl.d/*.conf
  • /usr/lib/sysctl.d/*.conf
    le configurazioni presenti sotto /etc/sysctl.d/ prevarranno su eventuali configurazioni confliggenti in /run/susctl.d/ e /usr/lib/sysctl.d/, configurazioni in /run/sysctl.d/ prevarranno su quelle sotto /usr/lib/systctl.d/

Un’eventuale configurazione posta direttamente sotto /etc/sysctl.conf non sarà considerata da systemd ma solo da un manuale

# sysctl --system

Per ora, Fedora piazza un symlink in /etc/sysctl.d/99-sysctl.conf in modo da caricare sempre e comunque quanto ancora definito in /etc/sysctl.conf, ma tale symlink non è garantito ci sarà sempre.

Detto questo, ci sono vari valori che possono incidere sulla performance di questo codice, non è così scontato credo determinare quale valore nello specifico abbia il maggiore impatto senza vedere l’intero codice. Comunque, tutti i valori del sottosistema “virtual memory” possono essere esaminati con # sysctl -a 2>/dev/null| grep ^vm
Gli approcci possibili sono molteplici e a volte confliggenti. Una spiegazione dei possibile valori è disponibile direttamente su https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Caro tempus…si capisce subito dalle tue conoscenze sull’argomento che devi essere un grande professionista Informatico…e di Linux in particolare…

-…se il problema esiste come problema del S.O: Linux io credo debba essere evidenziato non su un caso particolare di codice (il mio)…ma deve essere invece verificato su varie macchine e vari casi di altro codice (che deve comunque portare al riempimento della RAM con conseguente utilizzo intensivo dello swap)…in modo da poter concludere che si tratta di un problema di carattere generale …su una iterazione di chiamate di sistema per la stampa su FILE di strutture dati …nel momento in cui lo swap utilizzato dalla macchina per contenere le strutture stesse da stampare supera una decina di GB …ovviamente il problema è tanto piu’ evidente nel confronto con Windows quanto maggiore è la dimensione dello swap utilizzato quando inizia il ciclo for di stampa…per rendere agli interessati piu’ semplice comprendere il senso di questa discussione, voglio aggiungere una descrizione riassuntiva piu’ ordinata dell’algoritmo in questione…che sicuramente voi del FORUM non avrete difficolta’ a implementare …sui vostri PC…

.il programma consiste essenzialmente di due funzioni:
-Funzione 1…legge 5 miliardi di dati casuali da un file di input (formato binario) e li distribuisce su 5000 intervalli di interi (implementati per mezzo di altrettanti vettori allocati dinamicamente); ciascun intervallo ha un’ampiezza costante di 2 Milioni di dati;quindi l’intervallo 0 contiene tutti i dati letti dal file di input di valore compreso tra [1-2000000],
l’intervallo 1 tutti i dati i cui valori sono compresi tra [2000001-4000000] e cosi via…

-Funzione 2- stampa sequenzialmente su file i 5000 vettori contenenti i suddetti intervalli ed è implementata dal ciclo for riportato nel primo post, dove ho omesso solo un messaggio di notitfica su schermo che appare ogni 50 vettori stampati essendo inessenziale per la soluzione del problema posto da questa discussione.
Terminata la stampa dei vettori con la Funzione 2 il programma chiude regolarmente…
I tempi di esecuzione per la Funzione 1 (caso 5 Miliardi-su un PC molto vecchio) sono circa 12 minuti su Linux…mentre Windows è un po’ piu’ lenta circa 4 minuti…
Sulla Funzione 2 come ho gia’ scritto i tempi tra i due S:O. non sono piu’ confrontabili…e vorrei tanto capire da cosa possa dipendere…
Su Windows è questione di una decina di minuti sul notebook— 20 minuti sul PC vecchio—su Linux anche col notebook ci vogliono 2 ore e30 minuti

i…ho rifatto il test…il fatto che mi lascia piu’ sconcertato…è che in conseguenza dell’istruzione free che ho incluso nel ciclo for riportato nel mio primo post, dopo i primi 1500 verrori stampati (in tutto da stampare sono 5000) si ottiene un notevole incremento di RAM libera (la RAM disponibile aumenta durante l’esecuzione del ciclo for e si puo’ vederlo direttamente aprendo Monitor di sistema) …in altre parole ho la meta’ della RAM libera e disponibile…ma il tempo per stampare i 50 vettori rimane lo stesso come per i primi 50 vettori stampati con la RAM del tutto piena…secondo me’ è questa la chiave del mistero…perche’ mentre Windows includendo nel ciclo for di stampa l’istruzione free accelera impetuosamente…LINUX non ne trova alcun giovamento …quando deve usare lo swap perché la RAM è piena…la stampa rallenta vistosamente (tanto di piu’ quanto piu’ è la dimensione dello swap utilizzato)…dopodiche’ anche rilasciando la memoria allocata…non cambia piu’ niente.

Jeeg2
Prode Principiante

Messaggi: 21
Iscrizione: ottobre 2015
Sesso: Maschile

…questa discussione sembra non destare particolare interesse …posso chiedervi a voi del forum e in particolare a tempus che è intervenuto (e al quale ho anche inviato un messaggio privato per informarlo su alcuni importanti sviluppi) , se pensate che il problema sia poco importante oppure al contrario sia opportuno informare direttamente gli sviluppatori del KERNEL_LINUX su questo fatto?
TANTI AUGURI DI BUONA PASQUA!!!

Mah … a me invece interessa molto difatti senza aver fatto prove così “scientifiche”, purtroppo ho avuto da lamentarmi delle performances della swap rispetto al file di paging di “finestre”.
Purtroppo non ho risposte ma anche io domande; le uniche varianti che posso notare a livello di menuconfig di kernel son le voci riguardanti appunto la swap.

A parte che ora ho 16 GiB ram qindi non mi capita mai di swappare, le mie impostazioni in menuconfig riguardo swap son le seguenti:

CONFIG_SWAP=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_FRONTSWAP=y
CONFIG_ZSWAP=y
CONFIG_MTD_SWAP=m
CONFIG_NFS_SWAP=y
CONFIG_SUNRPC_SWAP=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
# CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set

In pratica le “pagine” così dovrebbero richieder meno tempo in quanto “compresse antescrittura” (se non ho compreso male).

Riguardo altre possibili migliorie/raffinatezze, … son tutt’orecchie anche io.

Anche provando ad usare un file di swap nel filesystem root al posto dell’area di swap non vi è beneficio (anzi forse leggermente peggio).

PS: Augurissimi anche a te :slight_smile:

Scusate …se mi intrometto…dove posso trovare una guida aggiornata per la ricompilazione del Kernel su Fedora 23?

Grazie Sandro…in altre parole devo seguire tutta la procedura di ricompilazione del Kernel…impostare quelle modifiche con make menuconfig e lanciare il nuovo kernel modificato…ho trovato in rete questa guida…https://fedoraproject.org/wiki/Building_a_custom_kernel#Dependencies_for_building_kernels
posso seguire questa oppure tu ne conosci una meno sofisticata…? :slight_smile:

P.S…il messaggio che ho inviato a tempus…era per informarlo che sono riuscito a stampare su Linux quei 5000 vettori con una velocita’ superiore a quella di ‘finestre’…ma a caro prezzo …perche’ ho dovuto cambiare il codice per l’allocazione dinamica…passando da una allocazione dinamica di vettori…ad una allocazione di intero singolo ripetuta 5 miliardi di vollte+allocazione dinamica dei 5000 indirizzi corrispondenti al primo elemento per ciascun vettore …col primo metodo (vettoriale) sono sufficienti 5o 6 GB di swap per allocare 5 miliardi di interi…col secondo (allocazione singola+allocazione degli indirizzi vettoriali) ci vogliono piu’ di 100 GB di swap-…paradossalmente con oltre 100GB di swap utilizzato (ma allocando gli elementi dei vettori di tipo int singolarmente uno dopo l’altro dopo aver preventivamente allocato gli indirizzi dei vettori di output) la stampa dei 5000 vettori di output dell’algoritmo è velocissima…pagando il seguente prezzo in termini temporali

  1. allocazione dinamica di 5000 vettori di interi ->tempo complessivo per ottenere i 5000 intervalli separati 10 minuti—ma stampa su file lentissima oltre le 2 ore
  2. allocazione dinamica di 5000 indirizzi vettoriali + allocazione singola di 5 Miliardi di elementi int ->tempo complessivo per ottenere i 5000 intervalli separati 40 minuti—ma stampa su file velocissima, bastano circa 4 minuti

Purtroppo questa configurazione è relativa ad un custom kernel non rpm-izzato (il 4.1.15).
E purtroppo ora sono col laptop che usa mio padre in quanto il PC con F23 è “dal meccanico” :frowning:
Peccato che in Fedora sia occultata la visione del kernel-config tramite

$ zgrep -i swap /proc/config.gz

Comunque installando kernel-devel si dovrebbe poter accedere al .config; quindi vedere se sono magari già attive o meno le suddette voci, od anche guardando con make menuconfig le impostazioni per un determinato kernel. Purtroppo penso che riavrò il mio PC con F23 dopodomani (spero) in modo da poter dar più responsi riguardo questa discussione.
L’indirizzo della guida che hai postato è corretto anzi molto dettagliato; (io mi rifaccio ancora al metodo spiegato nel libro di Fedora 9 con le eventuali modifiche del caso ovvero dnf al posto di yum ecc).

Se provi a ricompilare il kernel (nel caso le impostanzioni dovessero differire), tienici aggiornati riprovando col tuo test (magari lo proverò anche io).
Tra l’altro avendo un SSD 120 + HDD da 1 TiB ho messo la swap in SSD.

E… scusate questa “indesiderata latenza” :frowning:

Non è detto perché in uno scenario estremo un software abbia cattive performance, il software sia cattivo. Probabilmente impostare swappiness ad un valore diverso, magari più basso (ad esempio 10) potrebbe migliorare la situazione.
Anche utilizzare hugetlbfs potrebbe aiutare, ma anche in questo caso è tutto da provare.
Forse avere una scrittura più asincrona potrebbe ridurre il carico sul disco (vedasi parametri dirty*).

Non conosco abbastanza il funzionamento interno della gestione della swap in Linux per fare commenti.

Riferimenti:
https://lwn.net/Articles/374424/
https://lwn.net/Articles/375096/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-tunables.html
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

Approfondimenti:
https://lwn.net/Articles/253361/

Per info, Fedora 23 (ho installato la “Server” anche se il mio in realtà è un uso prettamente desktop, notavo:

[root@localhost ~]# grep -i SWap /usr/src/kernels/4.4.5-300.fc23.x86_64+debug/.config 
CONFIG_SWAP=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_FRONTSWAP=y
CONFIG_ZSWAP=y
# CONFIG_MTD_SWAP is not set
CONFIG_NFS_SWAP=y
CONFIG_SUNRPC_SWAP=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
# CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set

Quindi quasi tutte riguardo lo swapping son già “attive” nello standard kernel ; senza dover ricompilarlo :slight_smile:

Beh anche se ricompilare kernel ottenendo un rpm è sempre un buon esercizietto di “ripasso” :smiley:

Ciao e grazie a frafra con le informazioni che ci mette a disposizione :slight_smile:

…mi pare di capire dall’ultimo post di Sandro 1972 che da soli abbiamo pochissime chances di ottenere nella stampa su swapping, le stesse performance di Windows…non sarebbe dunque il caso di contattare il KerneleTeam?

Beh … credo che sia un’ottima idea la tua :slight_smile:
Fammi sapere; e se vuoi che faccia qualche test … dimmi pure… qui o in PM :slight_smile:

Ciao :slight_smile: