Impossible de modifier vm.max_map_count pour elasticsearch

14

Préhistoire

J'ai elasticsearch et SugarCRM7 fonctionnant sur CentOS 6.5. Chaque jour, je suis confronté au même problème: erreur java outOfMemory. Cela se produit en raison de la petite valeur vm.max_map_count, 65530 uniquement lorsque 262144 est recommandé.

Problème

Le problème est que vm.max_map_count semble immuable:

  1. Changement sous root

    sudo sysctl -w vm.max_map_count=262144
    

    Retour

    erreur: autorisation refusée sur la clé 'vm.max_map_count'

    Tandis que

    ps aux | grep java
    

    Renvoie uniquement le processus grep

  2. Changer au démarrage d'Elasticsearch

    sudo service elasticsearch start
    

    Renvoie également une erreur

    erreur: autorisation refusée sur la clé 'vm.max_map_count'

    Démarrage d'elasticsearch: [OK]

  3. Modifications manuelles via fichier (hack sale-sale):

    sudo vi /proc/sys/vm/max_map_count
    

    Ne fonctionne pas non plus:

    "/ proc / sys / vm / max_map_count" [lecture seule] 1L, 6C

    - INSERER - W10: Avertissement: modification d'un fichier en lecture seule

    E45: L'option 'lecture seule' est définie (ajoutez! Pour remplacer)

    "/ proc / sys / vm / max_map_count" E212: impossible d'ouvrir le fichier pour l'écriture

    Tandis que

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

    Retour

    -rw-r - r-- 1 racine root 0 10 avril 09:36 max_map_count

    (Mais je suppose que cela peut être normal pour Linux de parler du répertoire / proc)

Alors, comment puis-je changer la valeur de cette variable? Redémarrer elasticsearch tous les soirs n'est pas une bonne idée ... Ou peut-être que quelqu'un sait pourquoi cette erreur se produit?

Valentina
la source
3
De quel type de machine s'agit-il? Virtuel? Si oui, quel type de virtualisation est utilisé? Notez que certaines virtualisations, par exemple, les conteneurs OpenVZ imposent des limitations sur votre conteneur et ne vous permettent pas de "modifier" le noyau et d'autres éléments de bas niveau.
Miroslav Koškár
@MiroslavKoskar, je ne sais pas, malheureusement. Comment le découvrir?
Valentina
@MiroslavKoskar Oublié de mentionner - la machine est virtuelle, bien sûr
Valentina
1
Comment le découvrir? Eh bien, où est-il hébergé? Cela devrait être assez évident car cela fait généralement partie de votre contrat avec votre hébergeur. En cas de doute, contactez le support de votre fournisseur d'hébergement, à mon humble avis, c'est le meilleur endroit pour commencer (car cela fait généralement partie de l'accord et que vous payez probablement).
Miroslav Koškár
@MiroslavKoskar bien, le fournisseur a répondu sans mentionner la technologie qu'il ne pouvait pas m'aider avec ce problème (c'est plutôt raisonnable). Merci pour votre aide
Valentina

Réponses:

13

vous y êtes presque, peu importe qu'il s'agisse d'une machine virtuelle ou physique, ces paramètres sont toujours modifiables.

Je vais montrer 3 méthodes.

Quelques pré-informations:

1) Il est préférable d'exécuter en tant que root, si possible.

2) / proc sur unix n'est pas un vrai système de fichiers, c'est un système de fichiers noyau en mémoire, mais il semble être comme un système de fichiers disque normal. Vous pouvez l'appeler 'faux système de fichiers' ou 'système de fichiers spécial', vous ne pouvez pas éditer ces faux fichiers avec vi ou tout autre éditeur, car ce ne sont pas des fichiers, ils ressemblent simplement à des fichiers. Je suis resté avec le même problème il y a des années.

Mais il est simple de changer leurs valeurs, il suffit de recourir à un autre type de «mécanique» pour les modifier.

Je vais vous expliquer: Tout d'abord, vous devez être root: (sudo fonctionne dans certaines distributions, mais pas sur d'autres distributions comme vous l'avez essayé, cette première méthode est universelle et fonctionne sur n'importe quel Linux, macOS ou tout Unix. J'espère que vous avez accès au mot de passe root.

Procédez à l'invite:

    $ su root

Saisissez le mot de passe root.

Maintenant que vous êtes root, vérifions la valeur actuelle de: / proc / sys / vm / max_map_count

    $ cat /proc/sys/vm/max_map_count  
    65536

Changeons-le:

    echo 262144 > /proc/sys/vm/max_map_count

Vérifions:

    cat /proc/sys/vm/max_map_count
    262144

C'est fait! Et c'est déjà appliqué et fonctionnel. En modifiant les valeurs de n'importe quel pseudo-fichier sous / proc, les paramètres deviennent instantanément actifs. Mais ils ne persistent pas après un redémarrage. Vous pouvez jouer avec les valeurs et mesurer les changements de performances sur elasticsearh ou toute autre métrique d'application ou de système. Allez régler votre système, écrivez les valeurs sur du papier, gardez les meilleures valeurs. En cas d'erreur, redémarrez et ils reviendront tous aux valeurs d'origine, et recommencent jusqu'à ce que toutes les valeurs souhaitées soient optimales. Il y a beaucoup de paramètres réglables sur le disque et la mémoire sous / proc. Et ils font une énorme différence et un gain de performances si vous les ajustez bien (et que vous en avez le temps). Tu es sur le bon chemin.

Une fois satisfait, rendons-les permanents:

Première méthode:

en utilisant /etc/rc.local

    vi /etc/rc.local 

placez tous les paramètres dans le fichier rc.local, par exemple:

    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

quitter l'éditeur vi en enregistrant le fichier.

Ces paramètres seront définis à chaque redémarrage, APRÈS le démarrage de tous les services d'initialisation, juste avant l'affichage de l'invite de connexion.

(Le fichier /etc/rc.local est exécuté après tous les services Linux de démarrage, il peut ne pas fonctionner si elasticsearch démarre avant lui en tant que service, mais cette méthode peut être utile sur une autre configuration si vous en avez besoin à l'avenir, ou vous pouvez utiliser comme ceci en les mettant dans votre script d'initialisation elasticsearch, car le script d'initialisation s'exécute en tant que root, il s'agit donc de la même syntaxe ci-dessus que celle utilisée dans les scripts d'initialisation)

Vous pouvez également les copier maintenant et les coller pour des modifications instantanées. Les paramètres ci-dessus sont valides, réglés et exécutés sur mon serveur apache cassandra. Si vous le souhaitez, essayez-les comme point de départ pour régler le vôtre.

Deuxième méthode pour les rendre permanents:

Les paramètres seront désormais définis AVANT tout service de démarrage sur Linux.

Editez /etc/sysctl.conf , placez les paramètres à l'intérieur

 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

continuez avec les autres, enregistrez /etc/sysctl.conf , redémarrez votre serveur pour appliquer les modifications ou exécutez: sysctl -p pour appliquer les modifications sans redémarrer. Ils seront permanents à chaque redémarrage.

Les deux méthodes ci-dessus sont les plus courantes. Il y en a un autre, et ça peut marcher pour vous, c'est en utilisant sudo , presque comme vous le faisiez:

au lieu de:

  sudo sysctl -w vm.max_map_count=262144

essayer:

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

Cela fonctionne sur ubuntu.

Vérifier:

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

J'espère que j'ai aidé d'une façon ou d'une autre, au moins en donnant les 3 options différentes pour résoudre le problème, car votre question a presque un an;)

Cordialement, Rafael Prado

user62739
la source
3
Ils l'ont déjà fait et cela a échoué.
Michael Hampton
1
Salut Michael, oui tu as raison. J'ai d'abord compris que le problème était lié aux autorisations utilisateur du système d'exploitation CentOS et Unix, j'ai donc suivi cette ligne dans ma réponse. Mais des informations plus récentes mettent le problème au centre de l'OpenVZ «hôte», ce qui limite certains paramètres. Ma connaissance porte sur Centos et VmWare, mais pas sur OpenVZ.
user62739
4

Je pense que votre "machine virtuelle" est en fait un conteneur OpenVZ (que vous pouvez vérifier en exécutant virt-what ).

Dans ce cas, vous ne pouvez pas modifier vm.max_map_countsysctl ou bien d'autres. Les valeurs sont fixes.

Il s'agit d'un problème bien connu avec elasticsearch ( problème n ° 4978 ). Ce n'est pas seulement Elasticsearch. Les applications Java sont bien connues pour mal fonctionner sur divers fournisseurs OpenVZ, principalement parce que les hôtes sont souvent mal réglés et que vous ne pouvez rien y faire. Un intervenant sur cette question a fait écho à ce que serait exactement ma recommandation:

joshuajonah a commenté le 20 octobre 2015
C'est fou. Je suppose que je vais passer à un VPS KVM.

Michael Hampton
la source