Si tu parle de plus de 4Gio tu parle de logiciels qui utilisent plus de mémoire que la plus puissantes des machines que j'utilise.
Tu vis dans quel siècle ? ;) C'est ce qu'avaient les stations ou nœuds des Grid le plus moisi il y a presque 10 ans !
Je ne sais pas si c'est ridicule ou pas, je ne sais pas si les applications qui prennent tant de mémoire sont monnaies courantes ou pas (moi je n'en ai jamais rencontrée). J'ai travaillé surtout sur des systèmes distribués où l'on a 4Gio par nœud.
Ça dépend vraiment ce que tu fais tant d'un point de vu hardware que config logicielle. Actuellement en général on tourne souvent entre 4 et 8GB de RAM par cœur.
Après tu as des tâches où tu vas faire tourner un processus par cœur et garder des heaps < 8GB, et d'autres ou tu vas avoir un gros processus parallèle qui va attaquer toutes les resources de la machine. D'autre encore où la plupart de la RAM ne sera pas utiliser par l'applicatif mais par le cache VFS. Pour les gros consommateurs de RAM tu as typiquement les DB qui vont avoir un cache applicatif en plus du cache VFS, les gros traitements de graphes qui vont plusieurs ordre de grandeur plus vite que si tu devais le faire en distribué, tout ce qui bosse entièrement in-memory plutôt que de toucher au disque.
Je ne bosse actuellement plus du tout dans le big data, mais même ailleurs on nous file de base des VM avec 64GB de RAM. Après pour des déploiements plus conséquent tu configures ton hardware en fonction des besoins. Mais la RAM c'est pas cher. J'ai déjà passé plus deux semaines à devoir tordre et optimiser des gros batch map/reduce pour que ca passe sur une petite heap alors que le design, l'implémentation et le tuning étaient déjà parfaitement gaulés pour être efficace pour le problème. C'est pas très rentable à long terme...
Après il faut bien voir que tu n'as pas forcément besoin d'une énorme heap pour devoir faire une gestion propre de la mémoire ou bien comprendre les problématiques du GC. Ça se voit très facilement sur des grosses heap par ce que les pauses deviennent extrêmement importantes. Mais grosso modo dès que tu veux une latence bornée tu vas voir que ça arrive vite. Maintenant si tu as des heap à 1GB, sauf a avoir des bornes dans la dizaine de ms tu n'auras pas de soucis. Ça garbage vite...
[^] # Re: la réponse est évidente
Posté par ckyl . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Tu vis dans quel siècle ? ;) C'est ce qu'avaient les stations ou nœuds des Grid le plus moisi il y a presque 10 ans !
Ça dépend vraiment ce que tu fais tant d'un point de vu hardware que config logicielle. Actuellement en général on tourne souvent entre 4 et 8GB de RAM par cœur.
Après tu as des tâches où tu vas faire tourner un processus par cœur et garder des heaps < 8GB, et d'autres ou tu vas avoir un gros processus parallèle qui va attaquer toutes les resources de la machine. D'autre encore où la plupart de la RAM ne sera pas utiliser par l'applicatif mais par le cache VFS. Pour les gros consommateurs de RAM tu as typiquement les DB qui vont avoir un cache applicatif en plus du cache VFS, les gros traitements de graphes qui vont plusieurs ordre de grandeur plus vite que si tu devais le faire en distribué, tout ce qui bosse entièrement in-memory plutôt que de toucher au disque.
Je ne bosse actuellement plus du tout dans le big data, mais même ailleurs on nous file de base des VM avec 64GB de RAM. Après pour des déploiements plus conséquent tu configures ton hardware en fonction des besoins. Mais la RAM c'est pas cher. J'ai déjà passé plus deux semaines à devoir tordre et optimiser des gros batch map/reduce pour que ca passe sur une petite heap alors que le design, l'implémentation et le tuning étaient déjà parfaitement gaulés pour être efficace pour le problème. C'est pas très rentable à long terme...
Après il faut bien voir que tu n'as pas forcément besoin d'une énorme heap pour devoir faire une gestion propre de la mémoire ou bien comprendre les problématiques du GC. Ça se voit très facilement sur des grosses heap par ce que les pauses deviennent extrêmement importantes. Mais grosso modo dès que tu veux une latence bornée tu vas voir que ça arrive vite. Maintenant si tu as des heap à 1GB, sauf a avoir des bornes dans la dizaine de ms tu n'auras pas de soucis. Ça garbage vite...