2017-08-31 1 views
1

J'essaie de former un modèle d'apprentissage automatique avec H2O (3.14). La taille de ma base de données est de 4 Go et celle de mon ordinateur est de 2 Go avec le swap 2 Go, le JDK 1,8. Reportez-vous à ce article, H2O peut traiter un énorme ensemble de données avec 2 Go de RAM.Comment traiter un grand ensemble de données avec H2O

  • Une note sur Bigger données et GC: Nous faisons un swap sur disque en mode utilisateur lorsque le tas Java est trop plein, à savoir, vous utilisez plus que Big Data DRAM physique. Nous ne mourrons pas avec une spirale de la mort du GC, mais nous nous dégraderons à des vitesses hors du cœur. Nous irons aussi vite que le disque le permettra . J'ai personnellement testé le chargement d'un ensemble de données 12Gb dans une JVM 2Gb (32 bits); il a fallu environ 5 minutes pour charger les données et 5 minutes supplémentaires pour exécuter une régression logistique.

Quelques questions autour de cette questions:

  • Loading data bigger than the memory size in h2o. La réponse mentionnée swap-to-disk en mode utilisateur a été désactivée car les performances étaient si mauvaises. Cependant, il n'a pas expliqué une méthode alternative et comment peut activer les drapeaux --cleaner en h2o?

travail autour de 1:

J'ai configuré le tas java avec des options java -Xmx10g -jar h2o.jar. Quand je charge le jeu de données. L'information H2O comme suit:

Cependant, JVM consommé toute la mémoire RAM et Swap, puis le système d'exploitation interrompu java h2o programme.

travail autour de 2:

I installé H2O spark. Je peux charger ensemble de données, mais l'étincelle traînais avec les journaux suivants avec une mémoire d'échange complète:

+ FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=841.3 MB OOM! 
09-01 02:01:12.377 192.168.233.133:54321 6965 Thread-47 WARN: Swapping! OOM, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=841.3 MB OOM! 
09-01 02:01:12.377 192.168.233.133:54321 6965 Thread-48 WARN: Swapping! OOM, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=841.3 MB OOM! 
09-01 02:01:12.381 192.168.233.133:54321 6965 Thread-45 WARN: Swapping! OOM, (K/V:1.75 GB + POJO:513.3 MB + FREE:426.7 MB == MEM_MAX:2.67 GB), desiredKV=803.2 MB OOM! 
09-01 02:01:12.382 192.168.233.133:54321 6965 Thread-46 WARN: Swapping! OOM, (K/V:1.75 GB + POJO:513.4 MB + FREE:426.5 MB == MEM_MAX:2.67 GB), desiredKV=840.9 MB OOM! 
09-01 02:01:12.384 192.168.233.133:54321 6965 #e Thread WARN: Swapping! GC CALLBACK, (K/V:1.75 GB + POJO:513.4 MB + FREE:426.5 MB == MEM_MAX:2.67 GB), desiredKV=802.7 MB OOM! 
09-01 02:01:12.867 192.168.233.133:54321 6965 FJ-3-1 WARN: Swapping! OOM, (K/V:1.75 GB + POJO:513.4 MB + FREE:426.5 MB == MEM_MAX:2.67 GB), desiredKV=1.03 GB OOM! 
09-01 02:01:13.376 192.168.233.133:54321 6965 Thread-46 WARN: Swapping! OOM, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=803.2 MB OOM! 
09-01 02:01:13.934 192.168.233.133:54321 6965 Thread-45 WARN: Swapping! OOM, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=841.3 MB OOM! 
09-01 02:01:12.867 192.168.233.133:54321 6965 #e Thread WARN: Swapping! GC CALLBACK, (K/V:1.75 GB + POJO:513.2 MB + FREE:426.8 MB == MEM_MAX:2.67 GB), desiredKV=803.2 MB OOM! 

Dans ce cas, je pense que le collecteur gc attend pour le nettoyage de la mémoire non utilisée dans l'échange.

Comment puis-je traiter un grand ensemble de données avec une mémoire RAM limitée?

+0

Pourquoi l'étiquette 'r'? – shmosel

+0

J'ai retiré la balise 'r'. Mon client est un programme 'r' – khant

Répondre

1

Si cela est commercial, achetez plus de RAM ou payez quelques dollars pour louer quelques heures sur un serveur cloud. C'est parce que le temps et les efforts supplémentaires pour faire l'apprentissage automatique sur une machine trop petite ne valent tout simplement pas la peine.

S'il s'agit d'un projet d'apprentissage, sans budget du tout: découpez l'ensemble de données en 8 parties de taille égale (*) et utilisez simplement la première partie pour créer et ajuster vos modèles. (Si les données ne sont pas triées au hasard, coupez-les en 32 parties égales, puis concaténez les parties 1, 9, 17 et 25, ou quelque chose comme ça.)

Si vraiment, vraiment, vraiment, vous devez construire un modèle en utilisant l'ensemble des données, puis encore faire ce qui précède. Mais enregistrez le modèle, puis passez au 2e de vos 8 ensembles de données. À ce stade, vous aurez déjà réglé des hyperparamètres, vous générez donc simplement un modèle, et ce sera rapide. Répétez pour les parties 3 à 8. Maintenant, vous avez 8 modèles, et vous pouvez les utiliser dans un ensemble.

*: J'ai choisi 8, ce qui vous donne un 0.5 Go de données, soit un quart de la mémoire disponible. Pour les premières expériences, je recommanderais d'aller encore plus petit, par exemple. 50 Mo, car cela rendra les itérations beaucoup plus rapides.

quelques autres pensées:

  • H2O compresse les données en mémoire. Donc, si le 4 Go était la taille des données non compressées, vous pourriez vous débrouiller avec une plus petite mémoire. (Cependant, rappelez-vous que la recommandation est de 3 à 4 fois la taille de vos données.)
  • Si vous avez des amis avec des ordinateurs à petite mémoire similaires, vous pouvez les mettre en réseau ensemble. 4 à 8 ordinateurs peuvent suffire pour charger vos données. Cela pourrait bien fonctionner, cela pourrait être horriblement lent, cela dépend de l'algorithme (et de la rapidité de votre réseau).
+0

Existe-t-il une solution pour l'ajustement d'un modèle avec une méthode de générateur comme le cadre de keras? – khant

+0

@khant Pas que je sache. La philosophie H2O est l'apprentissage automatique en mémoire, qui fonctionne efficacement sur un cluster: continuez à ajouter des machines jusqu'à ce que la mémoire totale du cluster soit suffisamment grande pour votre ensemble de données. (Je viens d'ajouter quelques idées à ma réponse, j'espère que ça aide.) –

1

L'article cité en 2014 est vieux de plusieurs années et fait référence à H2O-2. Le concept de swap-to-disk en mode utilisateur H2O était expérimental à ce moment-là.

Mais cela n'a jamais été pris en charge dans H2O-3 (qui est devenu le principal code de H2O début 2015) parce que la performance était mauvaise, comme l'explique le message StackOverflow cité.