Bonsoir!

flyman a écrit:

J'ai remarqué qu'au fur et à mesure de l'utilisation du programme , la conso
mémoire progresse constamment (sans jamais varier vers le bas) ce qui tend à démontrer un manque d'optimisation de la mémoire qui s'encombre de plus en plus pour finir à friser les 4 Go fatidiques entraînant le crash du simulateur.

Pour moi rien n'y fait... la mémoire monte inexorablement quel que soit les réglages ... diminuer les  réglages ne fait qu'éloigner l'arrivée de L'OOM...
Je n'ai aucun complément d'installé sauf un avion l'airbus X... et je suis en Version 2.1. C'est vraiment dommage... Je pense qu'il ya la un problème de conception...

Au départ de Chambéry avec des réglages tout pratiquement à zéro...



à l'arrivée à Marseille quelques instant avant l'OOM...



Espérons que les développeurs trouvent une solution à ce problème...

Config I5 4670 K 4.2GHZ 8GO de RAM CG HD 7880 2GO RAM DDR5...

Salut, sur le forum de P3D certains mettent en cause l'autogen vegetation qu'ils conseillent, en attendant un éventuel patch, de mettre au plus bas.

@tous,

Je ne pense pas que l'autogen soit systématiquement responsable des OOM constatés.
Il y a une cause bien plus évidente, dont peu de gens parlent, c'est la multiplication trop importante de bgls dans certaines scènes.  FSX est limité dans sa gestion des identifiants des bgls et lorsque la limite du nombre de bgls différents utilisés est atteinte, les artefacts puis le plantage graphique arrivent sans possibilité de revenir en arrière.
FVFR a limité le nombre de créations de bgls en créant des "plaques" qui ne consomment qu'un identifiant. Ce procédé retarde largement l'apparition de l'OOM et fluidifie l'affichage.

Un argument qui conforte ce que j'avance : mes "Plans Lumière" rajoutent des milliers de bgls sur une zone parfois très réduite et ils ne plantent pas la scène pour autant parce qu'il n'y a que 4 identifiants utilisés ....

Sous XP il existe une dll modifiée qui supprime la limite de stockage de ces identifiants. Je ne la conseille pas, ça ne fait que retarder l'OOM qui est plus violent quand le stockage vient se faire sur les lignes de code

Donc, mon conseil serait :
Vous voulez voler tranquillement sur une zone : mettez tous les addons que vous voulez en restant sur cette zone.
Vous voulez faire des vols entre grands aeroports : gardez l'autogen (réglage moyen à faible) et supprimez tous les addons autres que ceux des aeroports que vous souhaitez desservir et s'il vous avez toujours des problèmes, utilisez les scènes génériques car elles ne consomment pas d'identifiants bgls supplémentaires.

Cordialement

Gropied

Bonjour!

"toujours des problèmes, utilisez les scènes génériques car elles ne consomment pas d'identifiants bgls supplémentaires."

En vol local autogène réduit sur position 2 (Arbres et Bâtiments) Météo sur beau temps et avion standard T6 la mémoire monte également pour ce stabiliser vers 2.5 GO si on change de vue la mémoire regrimpe... C'est rageant car question FPS on tient 30, même avec pratiquement tout à fond, mais alors le gouffre à mémoire...

Vu le nombre de post sur le site de P3D décrivant ce problème j'espère que cela va être pris en compte...

En tous cas je vais essayer Game Booster, et une réinstallation complète a partir d'une archive complète sans passer par la mise à jour...

Merci à tous les derniers intervenants: autant d'avis qui, une fois mis en pratique,
peuvent aider à franchir un tant soit peu convenablement cette mauvaise expérience
avec la v2.1.
Comme le problème était nettement moins récurrent avec la v2, les développeurs
devraient quand même pouvoir pister dans un délai raisonnable le défaut provoqué
sans doute par la correction d'un autre bug...

Dans l'un de mes messages précédents j'évoquais mon utilisation du logiciel System
Mechanic (avec son défragmenteur de la mémoire) pour "dégraisser" quelque peu la RAM encombrée. Pas très pratique puisqu'il faut d'abord lancer le programme avant de pouvoir accéder à l'outil.

En cherchant sur le net, je suis tombé sur un programme nommé cleanmem_v2.4.3 en freeware (pour la version basique) et payant à 4.99 $ (pour la version pro).
L'avantage est le fait qu'on peut garder toujours visible un mini tableau indiquant
en permanence la charge de la mémoire avec la possibilité de lancer un nettoyage
par un simple clic sur ce grand timbre poste qui passe presque inaperçu à l'écran.
Cette défrag peut aussi être automatisée en des intervalles de temps à définir.

Toutefois, les premiers essais m'ont permis de constater que le gain obtenu est relativement modeste à chaque opération (300 à 400 Mégas). Je poursuis
quand même les tests, car si un rafraîchissement automatique régulier peut être
provoqué sans dommage pour la fluidité du simulateur, ce petit gain répétitif
peut éventuellement éviter l'OOM ou au moins le retarder.

Je vous tiendrai au courant

Bons vols

Flyman

Bonjour,

flyman a écrit:

Hi,

Comme annoncé, le petit utilitaire "cleanmem" semble résoudre le problème des OOM.

Je ne connaissais pas ce petit utilitaire et ton post me l'a fait découvrir.

Je suis allé voir ce qu'il faisait et mon conseil amical est : Que tu peux oublier celui-ci pour régler (ou ralentir...) tes problèmes d'OOM.
La seule chose à faire, c'est d'attendre tranquillement que LM corrige son code.

Par contre, bonne nouvelle!... Je ne pense pas qu'il présente des problèmes de stabilité pour ta station.

Dernière modification par Ptipilot (18-02-2014 14:51:36)

Salut Ptipilot

Aussi ancien que moi sur ce forum... (je te bats de 2 jours, na ) sauf que tu n'as pas joué la "fille de l'air" comme moi... mais c'est une autre histoire.

Curieusement et ce n'est pas un placebo, j'obtiens des résultats pourtant visibles avec cleanmem. Je poursuivrai encore mes tests, cette fois dans des situations qui devraient normalement provoquer des OOM: si P3d ne crashe pas, ce ne sera sûrement pas le fruit du hasard.
De toute manière, quelque soient les médicaments utilisés, si l'on obtient un quelconque résultat, pourquoi ne pas les utiliser en attendant l'hypothétique intervention chirurgicale des développeurs deP3d ?

A moins que des spécialistes de la communauté parviennent à fabriquer entretemps une bidouille plus efficace que la mienne..

Qui vivra verra.

Bons vols

flyman

flyman a écrit:

Aussi ancien que moi sur ce forum... (je te bats de 2 jours, na ) sauf que tu n'as pas joué la "fille de l'air" comme moi... mais c'est une autre histoire.

OUI, mais tu as le droit à tout mon respect car tu es le plus âgé de nous deux...

flyman a écrit:

Curieusement et ce n'est pas un placebo, j'obtiens des résultats pourtant visibles avec cleanmem. Je poursuivrai encore mes tests, cette fois dans des situations qui devraient normalement provoquer des OOM: si P3d ne crashe pas, ce ne sera sûrement pas le fruit du hasard.

Tu obtiens des résultats.... Mais, tu les interprètes mal !...

Je m'explique...
Ce petit programme ne fait que de suivre l'activité des programmes et dans le cas ou ceux-ci sont inactifs, il les "kill" proprement au travers de l'API Windows officielle.

Cela revient à faire un NET STOP en ligne de commande... Rien de plus...

Ce que tu vois dans tes résultats, ce n'est juste que la phase de rééquilibrage que fait le noyau de l'OS automatiquement, du à la nouvelle quantité de RAM disponible.

Dans la majorité des cas, lorsque tu as un OOM, ce n'est pas que tu manques de mémoire physique (surtout toi avec tes 16 Go et ton potentiel supplémentaire que tu peux faire par ton fichier d'échange), mais bien parce que tu fait un over flow de tes 4 Go dédié à ton processus 32 bits (VAS).
Là, ce petit programme ne fait absolument rien...

Mais, si tu as l'impression que cela améliore quelque chose, fait toi plaisir, continu à l’utiliser...

Dernière modification par Ptipilot (18-02-2014 20:16:10)

Ptipilot a écrit:

flighty a écrit:

... je ne peux pas comprendre pourquoi j'ai un OOM à 700 Mo mémoire utilisée par FS alors que dans une situation similaire mais à 1.5 Go mémoire utilisée je n'ai rien.

Cherche un peu...
Je l'ai déjà expliqué P plus Q fois !...

Trop compliquée pour ma petite tête cher ami. Je jette l'éponge

J'ai trouvé cette page tres instructive (en anglais helas): http://www.fsdeveloper.com/wiki/index.p … =OOM_Error

Lu sur le forum Prepar3D de la part d'un utilisateur lambda (ce n'est pas un message d'un officiel Lockheed Martin), dans la série méthode simple pour retarder l'échéance (sans les supprimer) des OOM ;-)

Lorsque le VAS* atteind les 2.7 Go, pause, ouverture de la fenêtre de "Scenery Library", clique sur OK, attendre que le chargement de la scène se déroule et le VAS retombe vers 2.2 Go ;-)

For staying alive some few minutes more, as soon as the vas goes over 2.7G, i pause the sim, open the scenery library window, juste click Ok and wait for the scenery to reload. When everything is back, the vas becomes +/- 2.2G.

Source : http://www.prepar3d.com/forum-5/?mingle … amp;t=5747

* La mémoire occupée par le process Prepar3D.exe ;-)

Dernière modification par vbazillio (21-02-2014 17:12:46)

vbazillio a écrit:

Lu sur le forum Prepar3D, dans la série méthode simple pour retarder l'échéance (sans les supprimer) des OOM ;-)

Lorsque le VAS* atteind les 2.7 Go, pause, ouverture de la fenêtre de "Scenery Library", clique sur OK, attendre que le chargement de la scène se déroule et le VAS retombe vers 2.2 Go ;-)

Ils sont bons chez LM...
Ils font exploser eux mêmes leurs hash tables avec leurs propres objets !

Avec FSX, il fallait au moins l'aide d'OBX ...