Posso eseguire un server Oracle senza swap?

Disattivare lo scambio è una buona idea se

• il tuo software può gestire con garbo condizioni di memoria insufficiente o limitarsi per evitare situazioni OOM
• avere prestazioni costanti è fondamentale (quando il tuo sistema sta scambiando la latenza aumenterà, il che può essere abbastanza grave da renderlo effettivamente inutile per molte applicazioni)

Questo genere di cose accade spesso con i database. Lo vedo di più con i database noSQL, ma i database relazionali possono affrontare la stessa sfida.

Non c'è nulla nel sistema operativo che richieda la presenza di swap. Linux si occupa di questo abbastanza con garbo uccidendo l'ultimo processo che ha richiesto memoria. Non vuoi arrivare a quel punto, quindi assicurati di ottimizzare Oracle per utilizzare solo il 90% circa della memoria, quindi ne rimane un po 'per i demoni di sistema e il margine di errore. La memoria "libera" viene utilizzata anche per il buffering dell'I/O del disco, il che è un enorme vantaggio in termini di prestazioni, quindi provare a consumare più memoria da parte del database stesso alla fine rallenterà le prestazioni complessive del sistema abbastanza da essere controproducente.

Anche con sistemi che hanno una frazione della memoria dalla domanda se l'applicazione è un database o una cache o un sistema simile, a questo punto di default non farei swap.

Autorità

In modo che non ti affidi solo alla mia parola:

Cassandra

Datastax spiega per Cassandra:

Devi disabilitare completamente lo scambio. In caso contrario, le prestazioni possono essere notevolmente ridotte. Poiché Cassandra ha più repliche e un failover trasparente, è preferibile che una replica venga interrotta immediatamente quando la memoria è bassa piuttosto che andare in swap. Ciò consente di reindirizzare immediatamente il traffico a una replica funzionante invece di continuare a colpire la replica che ha un'elevata latenza a causa dello scambio. Se il tuo sistema ha molta DRAM, lo scambio riduce ancora significativamente le prestazioni perché il sistema operativo scambia il codice eseguibile in modo che sia disponibile più DRAM per la memorizzazione nella cache dei dischi.

riak

Basho spiega a Riak che dovresti:

Idealmente, dovresti disabilitare lo scambio per assicurarti che le pagine del processo di Riak non vengano scambiate. La disabilitazione dello scambio consentirà a Riak di bloccarsi in situazioni in cui si esaurisce la memoria. Questo lascerà un file di crash dump, chiamato erl_crash.dump , nel /var/log/riak directory che può essere utilizzata per determinare la causa dell'utilizzo della memoria.

mysql

Percona è seduto sulla staccionata e fornisce utili avvertenze per entrambi i lati della questione. MariaDB non è d'accordo con la disabilitazione di swap:

Mentre alcuni disabilitano del tutto lo scambio, e sicuramente vuoi evitare che qualsiasi processo di database lo usi, può essere prudente lasciare un po' di spazio di scambio per consentire almeno al kernel di cadere con grazia se si verifica un picco. Avere a disposizione lo scambio di emergenza ti consente almeno di avere un certo margine per terminare qualsiasi processo in fuga.

Errore server

Una risposta ben accolta qui include:

Personalmente trovo un sistema swappy peggiore di un sistema in crash. Un sistema in crash attiverebbe un server di backup in standby per prendere il sopravvento molto prima. E in una configurazione attivo-attivo (o con bilanciamento del carico) un sistema in crash verrebbe messo fuori rotazione molto prima. Ancora una volta una vittoria per il sistema senza scambio.

Quella risposta ha 22 voti positivi oggi e ha 4 anni. Puoi anche vedere alcune altre risposte che esaltano il valore dello scambio, ma non c'è alcuna indicazione che stiano eseguendo database. Non hanno nemmeno tanti voti positivi. :)

calamari

Sebbene non raccomandino apertamente di disabilitare lo scambio, i ragazzi di squid dicono:

Squid tende ad essere un po' un divoratore di memoria. Usa la memoria per molte cose diverse, alcune delle quali sono più facili da controllare rispetto ad altre. L'utilizzo della memoria è importante perché se la dimensione del processo Squid supera la capacità della RAM del sistema, alcuni blocchi del processo devono essere temporaneamente scambiati su disco. Lo scambio può avvenire anche se sullo stesso sistema sono in esecuzione altre applicazioni affamate di memoria. Lo scambio causa un degrado molto rapido delle prestazioni di Squid.

Questo è ciò che non vuoi che accada al tuo database.

redis

Mentre redis raccomanda ufficialmente lo scambio, gli utenti non lo comprano:

Per prima cosa disabilita lo swap:Redis e swap non si mescolano facilmente e questo può certamente causare lentezza.

hadoop

Come si vede in questa risposta con il maggior numero di voti sulla community di hortonworks:

Per slave/worker/host di dati che hanno solo servizi distribuiti, è probabile che tu possa disabilitare lo scambio. Con i servizi distribuiti è preferibile lasciare che il processo/host venga ucciso piuttosto che scambiare. L'interruzione di tale processo o host non dovrebbe influire sulla disponibilità del cluster. Detto in un altro modo:vuoi "fallire velocemente" non "degradare lentamente".

[....]

Per maestri , anche lo scambio è spesso disabilitato sebbene non sia una regola fissa di Hortonworks e presumo che ci saranno discussioni/disaccordi. I master possono essere trattati in qualche modo come si tratterebbero i master in altri ambienti non Hadoop.

Il timore con la disabilitazione dello scambio sui master è che un evento OOM (memoria esaurita) possa influire sulla disponibilità del cluster. Ma ciò accadrà comunque anche con lo scambio configurato, ci vorrà solo un po' più di tempo. Le buone pratiche dell'amministratore/operatore sarebbero monitorare la disponibilità della RAM, quindi risolvere eventuali problemi prima di esaurire la memoria. Mantenendo così la disponibilità senza influire sulle prestazioni. Allora non è necessario alcuno scambio.

Mi piace perché parla di un'app Java, ma raggiunge molte delle stesse conclusioni sopra menzionate sui database. Inoltre, menziona il monitoraggio che è molto utile per ottimizzare le applicazioni ad alte prestazioni. Se non hai numeri per confrontare tutto si basa su sentimenti che sono più difficili da confrontare. Crea grafici per ogni metrica misurabile:latenza a livello di applicazione e throughput fino a CPU, disco, memoria e grafici di rete. Questi forniscono la maggior parte dei dati reali su cui devi prendere decisioni.