Lorsque vous exécutez sur EC2, vous ne pouvez souvent pas gagner en ce qui concerne les types d'instances. L'un des types les plus économiques disponibles est le c1.xlarge. Il a suffisamment de CPU pour gérer les compactages, une quantité décente de disque et des E/S réseau élevées. Cependant, nous avons constaté que la mémoire relativement faible de 7 Go sur le c1.xlarge entraîne souvent des problèmes de stabilité dans les clusters HBase hautement simultanés. Bien qu'il existe d'autres options plus coûteuses, ce didacticiel HBase vous aidera à tirer le meilleur parti de vos serveurs de région c1.xlarge.
1. Réduire le nombre de régions par RegionServer
Idéalement, vous devriez avoir moins de 100 régions par RegionServer . Le magasin de mémoire est divisé pour être utilisé par toutes les régions actives, et chaque région ajoute (par défaut) 2 Mo de mémoire pour le MSLAB. Réduire ce nombre aidera les choses à se dérouler sans heurts, et pas seulement du point de vue de la mémoire.
2. Voler de la mémoire à d'autres services
Vous ne devriez certainement pas exécuter un TaskTracker avec votre RegionServer sur ces types d'instances, mais vous exécutez très probablement un DataNode local. Une configuration typique nécessite 1 Go de mémoire pour un DataNode, mais nous avons constaté que vous n'en avez pas besoin dans de nombreux cas. Vérifiez vos métriques avant de déployer cela, mais nous étions parfaitement sûrs de réduire le tas DataNode à 400 Mo . Ce joli morceau de 624 Mo aidera HBase à aller un peu plus loin.
3. Régler ou désactiver MSLAB
Si après avoir volé de la mémoire et réduit des régions, vous rencontrez toujours des problèmes, vous pouvez aller plus loin. Comme je l'ai mentionné, la fonctionnalité MSLAB ajoute 2 Mo de surcharge de tas par défaut pour chaque région. Vous pouvez régler ce tampon avec hbase.hregion.memstore.mslab.chunksize . Plus vous descendez, moins il est efficace, mais moins il y a de surcharge de mémoire également. Désactivez-le complètement avec hbase.hregion.memstore.mslab.enabled .
4. Soyez agressif en matière de mise en cache et de traitement par lots
Mise en cache (Scan#setCaching(int) ) et traitement par lots (Scan#setBatch(int) ) sont parfaits pour limiter l'effet de la latence du réseau sur les scans volumineux. Malheureusement, ils nécessitent également plus de mémoire côté client et côté serveur. Gardez à l'esprit le compromis de vitesse, mais profitez d'un peu plus de stabilité en les réglant , aussi proche d'une valeur de 1 que nécessaire.
Le RegionServer doit également disposer de suffisamment de mémoire pour gérer toutes vos écritures simultanées. Si vous traitez fortement vos écritures par lots ou si vous envoyez quelques valeurs de cellule très volumineuses, vous risquez de rencontrer des exceptions OutOfMemoryExceptions. Réduisez également votre traitement par lots ici ou trouvez un moyen de réduire la taille de vos valeurs de cellule.
5. Contrôler la charge depuis Hadoop
Si vous exécutez des tâches hadoop sur vos données HBase, vous exécutez essentiellement de nombreuses analyses volumineuses. Dans une tâche HBase MapReduce, chaque région devient un mappeur. Si vous avez plus d'une région par RegionServer, il est probable que quelques mappeurs analysent simultanément le même RegionServer à un moment donné. Chacune de ces analyses utilise des ressources de mémoire, de disque et de processeur et, lorsqu'elles sont multiples, cela peut causer de la douleur.
Réduction de hbase.regionserver.handler.count aidera à limiter le nombre de connexions actives prenant de la mémoire, mais vous pourriez toujours avoir un problème si tous les gestionnaires gèrent de grandes analyses de région complète. Grâce à notre extension de TableInputFormat, vous pouvez contrôler facilement le nombre de mappeurs simultanés exécutés sur un seul RegionServer , offrant une utilisation de la mémoire plus prévisible.
Si vous écrivez dans HBase à partir d'un réducteur, vous souhaiterez également y contrôler le partitionnement. Ceci est facilement implémenté à l'aide du Partitioner de Hadoop interface, avec HBaseAdmin de HBase interface fournissant la région aux mappages RegionServer.
L'exécution de HBase avec peu de mémoire est difficile, mais pas impossible
Avec ces conseils en main, vous devriez être sur la bonne voie pour survivre aux opérations dans votre environnement à faible mémoire. Il peut être frustrant de se battre pour chaque mégaoctet de mémoire à une époque de RAM rapide et extrêmement bon marché. Mais suivez ces conseils et votre directeur financier vous remerciera d'avoir tiré le meilleur parti de ce type d'instance économique. Pour ceux qui ont un peu plus de liberté financière, nous explorerons l'impact des nouveaux types d'instances I2 d'Amazon dans un prochain article . Alors restez à l'écoute !
Cet article a été initialement publié sur dev.hubspot.com
