Discussion :

[Xalendar]

Voilà, mon travail de recherche m'amène à manipuler d'énormes quantités d'informations, notamment sous la forme de vecteur (Vector). Malgré l'usage du -Xmx je me retrouve avec des out of memory après avoir "seulement" créé 825 vecteurs de 873 éléments (en l'occurence des double). Je vais à terme devoir manipuler d'encore plus grande quantité de données (pour information je devrai arriver à une matrice non-creuse de 300 000 x 300 000 !), auriez vous des actuces, truc ou autre tour de magie pour me dépanner.

[woorant]

Salut!

heu.. peux tu nous en dire un peu plus sur le but de ton prog? pourquoi monter tout en memoire?? une base de donnée ne serait elle pas plus adaptée?

[fearyourself]

Voilà, mon travail de recherche m'amène à manipuler d'énormes quantités d'informations, notamment sous la forme de vecteur (Vector). Malgré l'usage du -Xmx je me retrouve avec des out of memory après avoir "seulement" créé 825 vecteurs de 873 éléments (en l'occurence des double). Je vais à terme devoir manipuler d'encore plus grande quantité de données (pour information je devrai arriver à une matrice non-creuse de 300 000 x 300 000 !), auriez vous des actuces, truc ou autre tour de magie pour me dépanner.

Ce n'est pas vraiment un problème de Java que tu as mais d'implémentation générale. Ton problème de out of memory, tu l'auras sur n'importe quelle machine si tu tentes d'avoir en même temps une telle matrice...

Si vraiment tu es obligé de travailler avec de telle quantité de données, la seule solution que je vois est de décharger une partie sur tes disques durs. Mais si tu décharges ta matrice entièrement et qu'on suppose que chaque élément prend un seul octet, ta matrice occupera 90 GB... Autant dire, qu'il faut trouver une autre solution...

Possibilités:

- Réduire la quantité de données à traiter
- Trouver un meilleur algo qui ne nécessite pas autant de données à la fois
- Acheter un disque dur suffisament grand ou des disques durs mis en RAID pour supporter autant de données.
- Mettre en place un système de compression et décharge sur disque dur pour limiter la quantité de données sur le disque dur... Une solution serait de mettre en place un gestionnaire de données qui gère ce qui doit se trouver en mémoire et ce qui se trouve en fichier et chaque accès se fait à travers cette classe. Cela rendra transparent la méthode de stockage utilisé... A travers cette classe, un portage vers une BD peut aussi être envisagée sans trop de difficultés...

[gailuris]

Salut,

Je ne pense vraiment pas que tu puisse faire tenir une telle matrice en memoire...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

300 000² = 90 000 000 000

En envisagent que tu stoques des valeurs qui tiennent sur un octet (ce qui n'est pas le cas des long : 4 octets je crois ??) : ça fait déjà 90 Go de mémoires...

Il va falloir trouver quelques choses d'autres...

Comme le dit Xalendar peut-etre en stoquant en BDD et en ne traitant qu'une partie de ta matrice à la fois...

EDIT : pardon pas Xalendar : woorant

[jowo]

matrice non-creuse c'est à dire que chaque cellule a une valeur?

Commentaire:

Mémoire nécessaire pour ta matrice
300'000 x 300'000 = 90'000'000'000 cellules 9*10^10

un double occupe 64bits d'où 8octets

Ta matrice va occuper au moins 72*10^10octets ==> ~670Goctet

Est-ce raisonnable?

[jowo]

Je pense que tu as de bonnes pistes de recherche avec les commentaires de fearyourself, de gailuris.

Une autre piste est le "File Mapping". "File Mapping" te permet d'accéder à un fichier comme s'il était chargé en mémoire (lecture et écriture). Il charge une région du fichier en mémoire.

Ce mécanisme a pourtant une limite. C'est le problème de localité, c'est à dire que les données à traiter doivent être proche l'une de l'autre sinon le système sera obligé d'effectuer de nombreuses et coûteuses opérations I/O.