Dovresti disabilitare il file di paging con SSD?

Ho letto questa domanda e contiene molte informazioni interessanti.

Ma supponendo che tu abbia RAM più che sufficiente, penso che il file di paging dovrebbe essere disabilitato su SSD per prolungare la durata. So che perderesti la discarica principale in caso di crash, ma non molte persone hanno bisogno di tali informazioni.

Da quanto ho capito, senza un file di paging, quando si raggiunge il limite della RAM, ciò potrebbe causare il thrashing su disco. Ma per gli SSD non esiste il concetto di thrashing, le letture sono veloci.

Che cosa ne pensate?

Ma supponendo che tu abbia RAM più che sufficiente, penso che il file di paging dovrebbe essere disabilitato su SSD per prolungare la durata. So che perderesti la discarica principale in caso di crash, ma non molte persone hanno bisogno di tali informazioni

Sembra piuttosto un'ottimizzazione prematura. Non hai discusso su quali SSD intendi utilizzare e senza effettivamente esaminare il carico di lavoro del server e il foglio dati SSD pianificato, non puoi avere idea di quale effetto avrà un file di pagina sulla durata del tuo SSD.

C'è anche un grande volume di disinformazione, sia su Internet più grande che qui su Server Fault, su SSD che soffrono di scarse vite. I primi SSD del modello potrebbero aver avuto problemi e le unità flash USB iniziano sicuramente a degradarsi, ma gli SSD di classe enterprise hanno algoritmi di livellamento dell'usura molto migliori e alcuni fanno uso di flash di riserva per migliorare le prestazioni e l'usura.

Le unità Intel X25-E , ad esempio, richiedono una durata di scrittura di 1 petabyte di scritture casuali per l'unità da 32 GB. Se stai saturando l'interfaccia di scrittura (200 MB / sec) senza sosta, con sovrascrittura, la mia stima è che ti durerà circa 58 giorni. Ma questo sta scrivendo qualcosa come 17 TB di dati al giorno su quell'unità.

Il carico di lavoro tipico del server sull'unità del sistema operativo sarà molto, molto meno, anche se si dispone di un file di paging. Chiamalo 50 GB al giorno. Se la cifra di 1 PB è accurata (e so che potrebbe essere considerata una cifra media, più discussioni in seguito), è ancora da qualche parte a nord di 50 anni.

Quelle cifre sembrano assurdamente alte, ovviamente, quindi diamo un'occhiata alle cifre effettive citate da Intel per la longevità prevista delle unità . Intel era felice di qualificare le unità MLC (non aziendali) per scrivere 100 GB di dati, ogni giorno, per cinque anni. La comprensione standard del flash SLC vs. MLC afferma che il flash SLC dura circa 10 volte più a lungo dell'MLC (il link sopra mostra anche questo su un grafico).

La verità sarà confermata dal tempo, ovviamente - o inizieremo a vedere le unità guastare presto o non lo faremo. Ma i numeri dietro le unità aggiungere fino a unità longevità non essere un problema con gli SSD di qualità decente a tutti .

Se stai usando un SSD MLC, allora forse hai ragione a preoccuparti. Ma tieni presente che se Intel è felice di valutare l'unità a 100 GB / giorno per cinque anni, ciò equivale sostanzialmente a 50 GB / giorno per 10 anni. E, tornando al mio punto originale, devi ancora sapere che tipo di carico di lavoro effettivo farai sul disco.

Personalmente, direi vivamente di non utilizzare un SSD MLC in un ambiente server di produzione. Se un SSD SLC decente è troppo costoso, attenersi ai dischi rotanti per ora.

(A parte questo, se fai i numeri, diciamo 100 GB al giorno per 50 anni, che è la valutazione "SLC dura 10 volte più a lungo di MLC", sembra che Intel stia dicendo che il loro disco da 32 GB ha effettivamente una durata di scrittura totale più vicino a 2 PB di dati, non a 1 PB citato nelle specifiche del prodotto. Anche se mi fido solo del più piccolo di questi due valori per essere felice che i miei drive X25-E dovrebbero durare ben a nord di 10 anni.)

Oltre alla longevità probabilmente non è un problema, come menziona Daniel Lawson, e il feedback del team MS stesso (sotto), considera

1. Il file di paging verrà comunque utilizzato solo quando necessario
2. Se si utilizza il file di paging , averlo sul SSD vs un disco rigido rotante farà un'enorme differenza

Il file di paging deve essere posizionato su SSD?

Sì. La maggior parte delle operazioni sui file di paging sono piccole letture casuali o scritture sequenziali più grandi, che sono entrambi tipi di operazioni che gli SSD gestiscono bene.

Osservando i dati di telemetria provenienti da migliaia di tracce e concentrandoci su letture e scritture di file di paging, lo troviamo

• Pagefile.sys legge un numero in eccesso di pagefile.sys che scrive di circa 40 a 1
• Le dimensioni di lettura di Pagefile.sys sono in genere piuttosto ridotte, con il 67% in meno o uguale a 4 KB e l'88% in meno di 16 KB.
• Le scritture di Pagefile.sys sono relativamente grandi, con il 62% maggiore o uguale a 128 KB e il 45% ha esattamente 1 MB di dimensione. In effetti, dati i tipici schemi di riferimento del file di paging e le caratteristiche di prestazione favorevoli che gli SSD hanno su tali schemi, ci sono pochi file migliori del file di paging da posizionare su un SSD.

Supporto e domande e risposte per unità a stato solido (MSDN)

Invece di disabilitare del tutto il file di paging, può essere utile dire al sistema operativo di non usarlo (ad esempio sysctl vm.swappiness=0).

Il sistema operativo eviterà di usarlo a meno che non sia necessario, salvando le scritture inutili SSD.

Lascerei sempre abilitato il file di paging; alcune parti del tuo sistema operativo o delle tue app potrebbero essere scritte per aspettarsi che ci sia, e come tale potrebbero comportarsi in modo errato se non ce n'è una.

Detto questo, ho eseguito Windows (XP) senza un file di paging in passato, ed è stato perfettamente soddisfatto di tutto ciò che ho lanciato. C'era sempre il dubbio assurdo, tuttavia, che sarebbe successo qualcosa che non gli sarebbe piaciuto.

Un'opzione potrebbe essere quella di impostarla davvero piccola.

Ciò non risponde direttamente al PO, ma volevo correggere un'impressione errata nella risposta / nei commenti sopra di Ronald e Daniel. (Sono nuovo, quindi non ho abbastanza punti per commentare.)

TRIM è in effetti la cosa più grande che puoi fare per prolungare la vita di un SSD. Ecco perché: SSD periodicamente "garbage collection" - copia i dati (frammentati) da blocchi di cancellazione parzialmente vuoti e li scrive contigui in un blocco appena cancellato.

Gli indirizzi vengono rimappati in modo che l'host non debba esserne consapevole. Questa attività di scrittura aggiuntiva, non direttamente associata alle scritture host, è chiamata "amplificazione della scrittura". Nel peggiore dei casi di un SSD completamente completo con una piccola quantità di spazio sottoposto a provisioning eccessivo (riserva nascosta), l'amplificazione della scrittura può essere facilmente compresa tra il 500% e il 700% della velocità di scrittura dell'host!

Durante la garbage collection, l'SSD non si preoccupa di copiare e riscrivere le pagine che sono state invalidate (sovrascritte o TRIMmed), risparmiando potenzialmente una grande quantità di lavoro e attività di scrittura. Se il filesystem cancella un file di grandi dimensioni, ma non informa l'unità tramite TRIM, l'unità continuerà a copiare i dati cancellati, sprecando scritture, a tempo indeterminato (o fino a quando quegli indirizzi di blocco non vengono assegnati a qualche altro file, che potrebbe essere molto tempo).

In sintesi, TRIM è davvero importante sia per la longevità che per le prestazioni.

L'ho detto sull'altro post che hai collegato, ma eseguiamo un server di linea principale senza un file di paging e tutto qui sembra a posto. In effetti sembra più veloce senza di essa. Abbiamo 8 GB di RAM e direi che dovresti decidere se hai molta RAM, non se il tuo disco rigido è un SSD o meno. Anche se riesco a capire il desiderio di salvarne la vita non facendo scritture inutili.

Basta usare un secondo disco rigido per la memoria virtuale.

Gestisco un laptop con 8 GB di RAM, unità SSD singola e nessun file di paging, da più di un anno, nessun problema. Mi sono imbattuto in un gioco che richiedeva il file di paging, sono andato sul sito Web del software e ho ottenuto il comando run per disabilitarlo, problema risolto.

Il mio laptop ha quattro anni. Vecchio, ma funziona più velocemente di alcuni desktop più recenti. Le perdite di memoria, alias file SWAP, sono state il problema con il sistema operativo Windows sin dalla creazione della tecnica. Sfortunatamente, gli sviluppatori Linux hanno seguito il suo passo. Meno software si esegue in background, meglio è (soprattutto se si tratta di Microsoft).

Direi di non usare lo swap, se riesci a cavartela. O forse abbassare lo swappiness. Mentre è difficile usarne uno (quanto tempo ci vorrebbe per scrivere su tutto il disco 100.000 volte, alla massima larghezza di banda che hai?), Se non ti serve.

Quindi di nuovo, l'ibernazione (sospensione su disco) non funziona senza una sorta di scambio.

C'era un comportamento strano senza swap (come in un disco RAM da 50 MB su cui scambiare sarebbe una vittoria), ma quello è stato riparato l'estate scorsa (o era il 2007?), Quindi un sistema operativo attuale dovrebbe andare bene.

Ora tutto ciò di cui abbiamo bisogno è l'hardware che supporti il ​​comando di cancellazione (Linux lo supporta da mesi) e la vita su SSD sarà semplicemente dandy.

Ho avuto due SSD di classe enterprise bruciati su di me molto prematuramente (cioè entro il periodo di garanzia). Penso che il motivo sia stato lo scambio pesante a causa del thrashing. Spesso mi rendevo conto di avere processi non necessari in esecuzione / daemon con errori con perdite di memoria, in modo tale che l'attività di scambio fosse intensa quasi continuamente. Di tanto in tanto corro iostat -n9 -w 10in background e noto che spesso c'è un'attività continua di disco pesante. Anche l'attività del processo kernel (swap) è stata registrata come sorgente della maggior parte degli I / O. Ricordo un demone che aveva una perdita di memoria per mesi e aveva bisogno di uccisioni periodiche. Spesso non risolvo i problemi a meno che il sistema non sia fastidiosamente lento, quindi spesso il thrashing è andato avanti per molto tempo prima che mi prendessi il tempo di riavviare il demone. E più a lungo per correggere la perdita.

Mentre disabilitare lo scambio attirerebbe la mia attenzione sul thrashing, quindi il problema verrebbe affrontato prima che si verificasse un'usura maggiore sull'SSD, è ben lungi dall'essere il modo migliore per prevenire tali danni; qualsiasi strumento di monitoraggio / allarme decente sarebbe migliore.

Un avvertimento che molte delle risposte non riescono a riconoscere è che se un server STA schiacciando continuamente un SSD, si esaurirà rapidamente in un anno in questa situazione . Il thrashing classico si verifica in genere quando lo scambio di memoria virtuale è abbastanza pesante da mantenere l'unità (di swap) per lo più occupata, ben all'interno di un ordine di grandezza della sua larghezza di banda I / O massima e c'è almeno un processo in attesa di un I / swap relativo O per completare il più delle volte che il sistema si trova in quello stato. Le altre risposte presuppongono che il sistema non lo siathrashing, almeno non nel modo classico; o fare affidamento su un fraintendimento di cosa sia il thrashing. E quel falso presupposto, nonostante altri dati accurati, porta a risposte errate sul PERCHÉ il paging, anche quando un SSD è l'unica posizione possibile per il file di scambio, è meglio lasciarlo abilitato.

Disabilita il file di paging sul disco quando hai molta memoria inutilizzata. Alcuni vecchi programmi richiedono una funzionalità di file di paging e per questi Windows creerà una piccola funzionalità di file di paging in memoria.