Impossibile modificare vm.max_map_count per elasticsearch


14

Preistoria

Ho elasticsearch e SugarCRM7 in esecuzione su CentOS 6.5. Ogni giorno incontro lo stesso problema: errore java outOfMemory. Ciò accade a causa del piccolo valore vm.max_map_count, 65530 solo quando si consiglia 262144.

Problema

Il problema è che vm.max_map_count sembra immutabile:

  1. Cambiando sotto root

    sudo sysctl -w vm.max_map_count=262144
    

    ritorna

    errore: autorizzazione negata sulla chiave "vm.max_map_count"

    Mentre

    ps aux | grep java
    

    Restituisce solo il processo grep

  2. Modifica all'avvio di elasticsearch

    sudo service elasticsearch start
    

    Restituisce anche l'errore

    errore: autorizzazione negata sulla chiave "vm.max_map_count"

    Avvio di elasticsearch: [OK]

  3. Modifiche manuali tramite file (hack sporco):

    sudo vi /proc/sys/vm/max_map_count
    

    Non funziona neanche:

    "/ proc / sys / vm / max_map_count" [sola lettura] 1L, 6C

    - INSERT - W10: Avviso: modifica di un file di sola lettura

    E45: l'opzione 'sola lettura' è impostata (aggiungi! Per sovrascrivere)

    "/ proc / sys / vm / max_map_count" E212: Impossibile aprire il file per la scrittura

    Mentre

    ls -la /proc/sys/vm/ | grep max_map_count
    

    ritorna

    -rw-r - r-- 1 radice radice 0 Apr 10 09:36 max_map_count

    (Ma suppongo che questo possa essere normale per Linux parlando della directory / proc)

Quindi, come posso modificare il valore di questa variabile? Riavviare elasticsearch ogni notte non è una buona idea ... O almeno qualcuno potrebbe sapere perché si verifica questo errore?


3
Che tipo di macchina è? Virtuale? In caso affermativo, che tipo di virtualizzazione viene utilizzata? Si noti che alcune virtualizzazioni, ad esempio i contenitori OpenVZ, impongono limitazioni al proprio contenitore e non consentono di "modificare" il kernel e altre cose di basso livello.
Miroslav Koškár,

@MiroslavKoskar, purtroppo, non lo so. Come posso scoprirlo?
Valentina,

@MiroslavKoskar Ho dimenticato di menzionare - la macchina è virtuale, ovviamente
Valentina

1
Come scoprirlo? Bene, dove è ospitato? Dovrebbe essere piuttosto ovvio perché di solito fa parte del tuo contratto con il tuo provider di hosting. Se sei ancora in dubbio, contatta il supporto del tuo provider di hosting, IMHO è il posto migliore per iniziare (poiché di solito fa parte dell'accordo e qualcosa che probabilmente stai pagando).
Miroslav Koškár,

@MiroslavKoskar bene, il provider ha risposto senza menzionare la tecnologia che non possono aiutarmi con questo problema (che è piuttosto ragionevole). Grazie per l'aiuto
Valentina,

Risposte:


13

ci sei quasi, non importa se si tratta di una macchina virtuale o fisica, tali impostazioni sono sempre modificabili.

Mostrerò 3 metodi.

Alcune pre-informazioni:

1) È meglio eseguire come root, se possibile.

2) / proc su unix non è un vero filesystem, è un file system del kernel in memoria, ma sembra essere come un normale file system del disco. Puoi chiamarlo "filesystem falso" o "filesystem speciale", non puoi modificare quei file falsi con vi o con qualsiasi altro editor, perché non sono file, sembrano solo file. Ho bloccato con lo stesso problema anni fa.

Ma è semplice cambiare i loro valori, basta solo un altro tipo di "meccanica" per modificarli.

Spiegherò: in primo luogo, è necessario essere root: (sudo funziona in alcune distro, ma non in altre distro come hai provato, questo primo metodo è universale e funziona su qualsiasi Linux, macOS o basato su Unix Spero che tu abbia accesso alla password di root.

Procedere al prompt:

    $ su root

Inserisci la password di root.

Ora sei root, controlliamo il valore corrente di: / proc / sys / vm / max_map_count

    $ cat /proc/sys/vm/max_map_count  
    65536

Cambiamolo:

    echo 262144 > /proc/sys/vm/max_map_count

Verifica:

    cat /proc/sys/vm/max_map_count
    262144

E 'fatto! Ed è già applicato e funzionale. Modificando i valori di qualsiasi pseudo-file in / proc, le impostazioni diventano immediatamente attive. Ma non persistono dopo un riavvio. Puoi giocare con i valori e misurare i cambiamenti delle prestazioni su elasticsearh o qualsiasi altra metrica dell'applicazione o del sistema. Vai a sintonizzare il tuo sistema, scrivendo i valori su alcuni fogli, mantieni i valori migliori. In caso di errore, riavviare e tutti torneranno ai valori originali e ricominciare fino a quando tutti i valori desiderati sono ottimali. Ci sono molti parametri sintonizzabili su disco e memoria in / proc. E fanno un'enorme differenza e aumentano le prestazioni se li sintonizzi bene (e hai tempo per farlo). Sei sulla buona strada.

Se soddisfatti, rendiamoli permanenti:

Primo metodo:

usando /etc/rc.local

    vi /etc/rc.local 

inserisci tutti i parametri nel file rc.local, ad esempio:

    echo 220000000 > /proc/sys/vm/dirty_background_bytes
    echo 320000000 > /proc/sys/vm/dirty_bytes
    echo 0 > /proc/sys/vm/dirty_background_ratio
    echo 0 > /proc/sys/vm/dirty_ratio
    echo 500 > /proc/sys/vm/dirty_writeback_centisecs
    echo 4500 > /proc/sys/vm/dirty_expire_centisecs
    echo 1 > /proc/sys/net/ipv4/tcp_rfc1337
    echo 10 > /proc/sys/vm/swappiness
    echo never > /sys/kernel/mm/transparent_hugepage/enabled
    echo never > /sys/kernel/mm/transparent_hugepage/defrag
    echo 120 > /proc/sys/net/ipv4/tcp_keepalive_time
    echo 0 > /proc/sys/vm/zone_reclaim_mode
    echo deadline > /sys/block/sda/queue/scheduler
    echo 8 > /sys/class/block/sda/queue/read_ahead_kb
    echo 1048575 > /proc/sys/vm/max_map_count

uscire dall'editor vi salvando il file.

Tali parametri verranno impostati ad ogni riavvio, DOPO che tutti i servizi di init sono stati avviati, poco prima che venga visualizzato il prompt di accesso.

(Il file /etc/rc.local viene eseguito dopo tutti i servizi di avvio di Linux, potrebbe non funzionare se elasticsearch si avvia prima di esso come servizio, ma questo metodo può essere utile su un'altra installazione se è necessario in futuro, oppure è possibile utilizzare in questo modo inserendoli nel tuo script init elasticsearch, perché lo script init viene eseguito come root, quindi è la stessa sintassi sopra per usare gli script interni)

Puoi anche copiarli ora e incollarli per modifiche istantanee. I parametri sopra riportati sono validi, ottimizzati e in esecuzione sul mio server Cassandra Apache. Se lo desideri, provali come punto di partenza per ottimizzare il tuo.

Secondo metodo per renderli permanenti:

I parametri ora verranno impostati PRIMA di qualsiasi servizio di avvio su Linux.

Modifica /etc/sysctl.conf , inserisci i parametri all'interno

 vm.max_map_count=1048575
 vm.zone_reclaim_mode=0
 vm.dirty_background_bytes=220000000
 vm.dirty_background_ratio=0
 vm.dirty_bytes=320000000
 vm.dirty_ratio=0
 vm.swappiness=10

andare avanti con gli altri, salvare /etc/sysctl.conf , riavviare il server per applicare le modifiche o eseguire: sysctl -p per applicare le modifiche senza riavviare. Saranno permanenti durante i riavvii.

Due metodi sopra sono i più comuni. Ce n'è un altro, e potrebbe funzionare per te, è usando sudo , quasi come stavi facendo:

invece di:

  sudo sysctl -w vm.max_map_count=262144

provare:

  echo 262144 | sudo tee /proc/sys/vm/max_map_count

Funziona su Ubuntu.

Verificare:

   user@naos:~$ cat /proc/sys/vm/max_map_count
   262144

Spero di aver aiutato in qualche modo, almeno dando le 3 diverse opzioni per affrontare il problema, dal momento che ha quasi un anno la tua domanda;)

Saluti, Rafael Prado


3
Lo hanno già fatto e non è riuscito.
Michael Hampton

1
Ciao Michael, sì, hai ragione. In un primo momento ho capito che il problema era legato al sistema operativo CentOS e alle autorizzazioni utente unix, quindi ho seguito quella riga sulla mia risposta. Ma le informazioni più recenti mettono il focus del problema sul "host" OpenVZ, che limita alcune impostazioni. La mia conoscenza è su Centos e VmWare, ma non su OpenVZ.
user62739

4

Penso che la tua "macchina virtuale" sia in realtà un contenitore OpenVZ (che puoi verificare eseguendo virt-what).

In questo caso, non è possibile modificare vm.max_map_countsysctl o molti altri. I valori sono fissi

Questo è un problema ben noto con elasticsearch ( numero 4978 ). Non è solo Elasticsearch. È noto che le app Java funzionano male su vari provider OpenVZ, principalmente perché gli host sono spesso mal regolati e non c'è nulla che tu possa fare al riguardo. Un commentatore su tale questione ha fatto eco a quella che sarebbe esattamente la mia raccomandazione:

joshuajonah ha commentato il 20 ott 2015
Questo è pazzo. Immagino che passerò a un VPS KVM.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.