[Hashtable][OutOfMemoryException] Une solution ?

Version imprimable

10/05/2011, 09h43
Xploit

[Hashtable][OutOfMemoryException] Une solution ?

Bonjour à tous,

Voilà je teste un systeme de distribution de numéros de série.
Pour ce faire je lance un soft sur plusieurs PCs qui ma récupérer des numéros de série sur le PC utilisé et qui va les stocker dans des fichiers de logs pour traitement ulterieur.

En effet, il s'agit de traiter tous ces fichiers créés sur differents PC et d'analyser leur contenu pour s'assurer de l'unicité des numéros.

Les numéros extraits des fichiers de logs sont stockés dans une hashtable (pour une recherche plus efficace).

Le probleme c'est que lorsque j'arrive à un taille de hashtable conséquente (100 000 entrées environ) j'ai une exception outofmemory lorsque je veux ajouter une entrée dans la hashtable.

Y a-t-il un moyen de contourner cette limite de taille de la hashtable ?

Sachant que j'ai plus de 3 Go de ram et qu'au max j'en utilise 2.03(winxp y compris ) avec le soft lorsque j'ai le message d'exception.

Je pensais que la limite en taille d'une hashtable est fixé par la place dispo en RAM.

Vous avez des idées ?
10/05/2011, 09h58
ostenhard

Bonjour,

De quel type sont les objets stockés dan ta hashtable ?
10/05/2011, 10h03
Xploit

Des chaines de caractères
KEY : string de 17 caractères
Value : chemin vers le fichier analysé + 20 caractères

Je vois l'idée. Mettre dans la hashtable des données moins gourmandes en mémoire genre

KEY (entier) | Value (entier )

?
10/05/2011, 10h33
tomlev

Citation:

Envoyé par Xploit

Des chaines de caractères
KEY : string de 17 caractères
Value : chemin vers le fichier analysé + 20 caractères

Je vois l'idée. Mettre dans la hashtable des données moins gourmandes en mémoire genre

KEY (entier) | Value (entier )

?

100000 entrées comme ça, c'est pas monstrueux... si on considère que le chemin fait 100 caractères, ça fait 100000 * (17 + 100 + 20), soit environ 13Mo (plus l'overhead de la hashtable, mais ça fait pas une grosse différence. Donc y a pas de quoi causer une OutOfMemoryException, le problème doit venir d'ailleurs...

Citation:

Y a-t-il un moyen de contourner cette limite de taille de la hashtable ?

La hashtable n'a pas de limite de taille (ou alors s'il y en a une ça doit être Int32.MaxValue, autant dire que tu as de la marge.)
10/05/2011, 10h48
Bluedeep

Poster un bout de code serait une bonne idée.

Alors en fait je fais une petite précision :

Ma hashtable possede 10 367 102 entrées lorsque que l'ajout d'une entrée me sort en outofmemory exception...

Si je reprends le calcul donné par tomlev ça me ferait du 1.4Go ?! Oo

Voici le code qui traite les fichiers

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
 
//membre de la classe
private Hashtable m_allSN;
            try
            {
                m_allSN = new Hashtable();
 
                for (int i = 0; i < m_allFiles.Count; i++)  // Treatment for each File given by the user
                {
                    string line;
                    int line_number =  0;
                    string[] separator = { ";" };
 
                    m_sr = new StreamReader((String)m_allFiles[i]);
 
                    while ((line = m_sr.ReadLine()) != null)    // Reads lines from file til EOF
                    {                    
 
                        //Serials treatment
                        if (m_allSN.ContainsKey(line.Split(separator, StringSplitOptions.None)[0]))
                        {
 
                            m_duplicateSerials.Add(line.Split(separator, StringSplitOptions.None)[0]+ 
                                                "\t" + m_allFiles[i] + 
                                                " at line " + line_number);
                            m_pass = false;
                            //throw new Exception("Serial Number " + line.Split(separator, StringSplitOptions.None)[0] +
                            //                    " already exists in the file " + m_allFiles[i] + 
                            //                    " at line " + line_number);
                        }
                        else m_allSN.Add(line.Split(separator, StringSplitOptions.None)[0], m_allFiles[i]);
                        line_number ++;
                    }

10/05/2011, 11h39
Bluedeep

Citation:

Envoyé par Xploit

Alors en fait je fais une petite précision :

Ma hashtable possede 10 367 102 entrées lorsque que l'ajout d'une entrée me sort en outofmemory exception...

Là, ça fait un 0 de plus ....

Citation:

Si je reprends le calcul donné par tomlev ça me ferait du 1.4Go ?! Oo

Et avec XP en 32 bits tu es limité à 2 Go addressable + 1 en cache. Ceci explique cela.

Il faut revoir le concept....
10/05/2011, 12h19
tomlev

Citation:

Envoyé par Bluedeep

Là, ça fait un 0 de plus ....

Deux en fait, il parlait de 100 000 entrées au début...

Donc oui, effectivement ce n'est pas étonnant que ça pète... c'est vraiment nécessaire de charger toutes ces données en mémoire en même temps ?
10/05/2011, 12h34
Xploit

Et bien ma petite appli consiste à vérifier l'unicité des serials numbers.
Donc il faut pouvoir comparer le numéro traité avec tous les précédents...donc je dirais qu'i il me faut toutes les infos (tous les numéros de série déjà récupéré dans les fichiers de logs) au même moment en mémoire.

Après je pourrais créer une fusion de tous les fichiers de logs en un seul fichier qui contiendrait tous les numéros puis faire le traitement dessus mais c'est pas du tout satisfaisant.
10/05/2011, 12h59
Bluedeep

Citation:

Envoyé par Xploit

Et bien ma petite appli consiste à vérifier l'unicité des serials numbers.

8O

Ce serait quand même plus simple de balancer le tout dans une table de base de données et de faire une requête en unicité, non ? (dans la mesure où intercepter via une violation de clef dupliquée n'est pas forcément l'idéal ici, si on veut tout garder).

D'où viennent-ils ces fichiers de log ?
10/05/2011, 14h41
Xploit

Tout mettre dans une table de BDD ça serait refaire le chemin inverse de mon processus de distribution de numéro de série. Mais l'idée peut etre interessante.

Sinon les fichiers de logs proviennent d'une application qui récupère des numéros de série sur un serveur mysql et qui les enregistre dans un fichier .txt de log.
Le tout est justement de valider l'unicité des numeros générés.
10/05/2011, 14h48
Bluedeep

Citation:

Envoyé par Xploit

Sinon les fichiers de logs proviennent d'une application qui récupère des numéros de série sur un serveur mysql et qui les enregistre dans un fichier .txt de log.
Le tout est justement de valider l'unicité des numeros générés.

Mais dans ce cas pourquoi ne pas requêter la base existante pour vérifier l'unicité ?

Ou alors il y aurait plusieurs bases ?
11/05/2011, 08h40
Xploit

l'idée me semble bonne, le problème est que mes numéros de série sont générés à partir d'un seul enregistrement dont un champ est incrémenté à chaque fois qu'on récupère la valeur du champs pour l'attribution d'un numéro de série.
Donc dans ce cas là, je n'ai pas un enregistrement par numéro de série attribué et donc demander à la base l'unicité des numéros générés n'est pas possible, si j'ai bien compris.
11/05/2011, 08h46
Bluedeep

Citation:

Envoyé par Xploit

l'idée me semble bonne, le problème est que mes numéros de série sont générés à partir d'un seul enregistrement dont un champ est incrémenté à chaque fois qu'on récupère la valeur du champs pour l'attribution d'un numéro de série.
Donc dans ce cas là, je n'ai pas un enregistrement par numéro de série attribué et donc demander à la base l'unicité des numéros générés n'est pas possible, si j'ai bien compris.

Si j'ai bien compris, ce que tu viens d'écrire est antinomique avec ce que tu as écrits au dessus où tu laissez entendre que tes numéros étaient dans une base.

Dans tous les cas de figure, il y a quelque chose que je ne comprends pas : si tes numéros sont délivrés via une sequence de la base, comment pourraient ils être dupliqués ?
11/05/2011, 09h08
Xploit
Dans ma table gerant les numéros de série, j'ai un enregistrement (ligne ) pour chaque clé (VendorID, ServiceID) ayant un champ numéro d'allocation.

En sachant que le client doit d'abord faire un SELECT... FOR UPDATE puis un update de la valeur d'allocation.

Le souci était d'être certain que si plusieurs clients attaquent en meme temps la table, ils ne puissent lire la même valeur de numéro d'allocation.

En faisant un :
Code:

1 2 3 4 Start transaction SELECT...FOR UPDATE UPDATE ... Commit
Je pense que la table est bien lockée par le client qui fait la transaction et les autres sont en attente.

J'aurais juste aimé pouvoir le démontrer...

Je ne sais pas si c très clair mais je fais de mon mieux pour expliquer le but des applis dont je parle.
11/05/2011, 09h10
Bluedeep

Citation:

Envoyé par Xploit

Dans ma table gerant les numéros de série, j'ai un enregistrement (ligne ) pour chaque clé (VendorID, ServiceID) ayant un champ numéro d'allocation.

En sachant que le client doit d'abord faire un SELECT... FOR UPDATE puis un update de la valeur d'allocation.

Le souci était d'être certain que si plusieurs clients attaquent en meme temps la table, ils ne puisse lire la même valeur de numéro d'allocation.

Drôle d'idée !
Je ne connais pas MySql mais j'ai quand même du mal à imaginer que ce soit tellement pauvre fonctionnellement qu'il n'y ait pas de notion de séquence.
11/05/2011, 09h12
jbrasselet

Dans MySql je ne crois pas qu'il y ait de sequence mais il y a des champs autoincrement de souvenir
11/05/2011, 09h12
Xploit

La notion de séquence dont tu parles serait comparable à ce que j'utilise ... une TRANSACTION ?

je ne suis pas expert non plus en SQL...

En tout cas la transaction verrouille la table
11/05/2011, 09h14
Bluedeep

Citation:

Envoyé par jbrasselet

Dans MySql je ne crois pas qu'il y ait de sequence mais il y a des champs autoincrement de souvenir

Oui, je disais "séquence" mais c'est ce que je voulais exprimer comme concept fonctionnel.
11/05/2011, 09h14
Xploit

Citation:

Envoyé par jbrasselet

Dans MySql je ne crois pas qu'il y ait de sequence mais il y a des champs autoincrement de souvenir

L'autoincrément, si je ne me trompe pas, est utilisé pour auto incrémenter un champ de la table lorsque l'on fait un nouvel enregistrement.

OR dans mon cas il s'agit de faire une mise à jour d'un champ d'un enregistrement existant...
11/05/2011, 09h15
Bluedeep

Citation:

Envoyé par Xploit

En tout cas la transaction verrouille la table

Ce n'est pas pour cela qu'il est légitime de faire faire par le programme client ce que habituellement on délègue au SGBD.
11/05/2011, 09h29
Xploit

1 pièce(s) jointe(s)

Citation:

Envoyé par Xploit

L'autoincrément, si je ne me trompe pas, est utilisé pour auto incrémenter un champ de la table lorsque l'on fait un nouvel enregistrement.

OR dans mon cas il s'agit de faire une mise à jour d'un champ d'un enregistrement existant...

Ceci me parait être un point important qui, s'il est affirmé, m'empeche d'utiliser l'auto increment du SGBD...

Pour en revenir à l'exception OutOfMemory ... j'ai fait tourner l'appli et il me semble qu'il reste de la mémoire disponible lorsque j'ai l'exception ...
11/05/2011, 10h08
tomlev

Citation:

Envoyé par Xploit

Pour en revenir à l'exception OutOfMemory ... j'ai fait tourner l'appli et il me semble qu'il reste de la mémoire disponible lorsque j'ai l'exception ...

Le fait que ton système ait encore de la RAM disponible ne veut pas dire grand chose...
http://blogs.msdn.com/b/ericlippert/...al-memory.aspx
11/05/2011, 10h30
swif79
Citation:

Envoyé par Xploit

Et bien ma petite appli consiste à vérifier l'unicité des serials numbers.
Donc il faut pouvoir comparer le numéro traité avec tous les précédents...donc je dirais qu'i il me faut toutes les infos (tous les numéros de série déjà récupéré dans les fichiers de logs) au même moment en mémoire.

Après je pourrais créer une fusion de tous les fichiers de logs en un seul fichier qui contiendrait tous les numéros puis faire le traitement dessus mais c'est pas du tout satisfaisant.

J'aurai bien une idée qui devrait éviter l'outOfMemory mais non performante et t'obligant à former un fichier XML regroupant tes fichier de log.
Ceci dit l'idée serait dont de former un fichier xml vraiment simpliste du genre
Code:

1 2 3 4 <racine> <_numeroDeSérie>Contenu de value</_numeroDeSérie> </racine>
Tu stocke tes numéros de série dans une liste et quand tu l'a parcours pour avoir accès à value tu fait une requête Xpath sur le fichier XML
11/05/2011, 10h44
Bluedeep

Citation:

Envoyé par swif79

Tu stocke tes numéros de série dans une liste et quand tu l'a parcours pour avoir accès à value tu fait une requête Xpath sur le fichier XML

SAuf que affirmer que cela diminura la consommation mémoire me semble plus qu'hasardeux.
Vu à la base le détestable ratio payload/occupation totale du XML cela me semble une idée même un peu tordue.
Mais en gros tu lui suggères de faire ce que je lui proposais via une DB mais avec beaucoup de problèmes potentiels (que ce soit en temps de réponse et en occupation mémoire).
11/05/2011, 12h09
swif79

Tu as raison, je viens de tester alors même si j'évite l'outOfMemory (de vraiment rien des value un peu plus grosse et boom), les temps de réponse sont désastreux, c'est une horreur.
La DB est la seul vrai solution...
11/05/2011, 12h27
giova_fr

Je crois vraiment en terme de productivité, et d'efficacité, que tu devrais plutot te pencher sur une solution SQL. ton probleme d'unicité et de concurence d'instance c'est du pur probleme d'administrateur SQL !!!

Pour éviter les problemes de concurrence, on fais de la transaction qui garantira que les deux requettes SELECT INSERT se sont bien déroulées, sinon elle annule tout.

Une fois la transaction mise en place, tu peux nettoyer la base en faisant une requette SQL qui vérifie/corrige l'unicité.

Compte tenu du nombre d'entré, je pense vraiment que ca vaut le coup...
11/05/2011, 12h38
Xploit

J'utilise effectivement déjà le concept de transaction dont j'ai donné mon utilisation dans un message plus haut.

Là où cela devient délicat c'est que ma transaction n'est pas simplement un SELECT puis un INSERT (nouvel enregistrement dans la table).

Mais un SELECT FOR UPDATE puis un UPDATE d'un champ d'un enregistrement existant.

à ce compte là je ne peux vérifier l'unicité des numéros de série qu'en récupérant les numéros de série grattés par les clients. Je ne peux rien utiliser au niveau serveur pour démontrer l'unicité. En effet tout repose sur la valeur d'un champ d'un seul enregistrement.

Je ne sais pas si j'arrive à me faire comprendre ...
Enfin bref j'ai bien pris note de vos suggestions...
11/05/2011, 13h28
giova_fr

Je ne vois pas quel probleme ca pose, quelques que soit les requettes (insert,update, update sur select, etc...) dans ta transcation, et quelque soit le nombre de ces requettes, si tu annule la transaction, ca annule toutes tes requettes.

Ca reste encore un probleme du coté SQL, donc à réglé dans la bdd. Ca sera plus fiable, plus performant, beaucoup beaucoup plus performant vu le nombre d'entrées dans ta table, et tu n'aura pas à fabriquer quelque chose d'exterieur avec toutes les contraintes que çà sous entend !

Bref tu dois absolument rendre ta BDD ACID compliant (voir les 4 points qui définissent ACID, tu es en plein dedans)

en francais, mois détaillé

Citation:

La majorité des systèmes de gestion de base de données du marché permettent de réaliser des transactions atomiques, cohérentes, isolées et durables.
11/05/2011, 17h37
Xploit
Attention il y a peut-être matière à confusion.

Je veux bien que ce soit un pb coté SQL, mais ma transaction me semble correcte. J'aurais juste voulu le démontrer ...

Quand je parlais de hashtable de + 10 Millions d'entrées, c'est bien la structure de données .Net et non pas une table du serveur SQL.

Mes numéros de séries (pour simplifier la chose) sont générés via un seul enregistrement d'une table SQL.

Structure de la table
_____________________________________
|serviceId | vendorId | numero d'allocation(na) |
_____________________________________|
| 00 | 01 | 0 |
_____________________________________|

tous les clients qui veulent un numero de série viennent lire le champ numéro d'allocation correspondant à leur service/vendor.
Chaque client qui vient lire la valeur l'incrémente pour le suivant. Mais ne crée pas de nouvelle entrée dans la table sql c un update...
Code:

1 2 3 4 Start transaction SELECT na FROM table WHERE ...FOR UPDATE UPDATE table SET na = na + 1 Commit
Je sais que cette transaction permet de gérer au mieux les accès concurrents et l'unicité des numéros. Cependant j'aurais voulu le démontrer ...

Bon le sujet à bien dévié du sujet premier du post ...

Fuseau horaire GMT +2. Il est actuellement 11h23.