FSX: OOM crashes. Решение проблемы вылета после пересечения отметки в 3 Гб используемой памяти. — Microsoft Flight Simulator X

Не хотелось бы создавать новую тему, но может быть, оно того стоит. Я думаю, многие сталкивались с такой красноречивой проблемой:
memory problem.jpg

Отчасти это решалось этим:

LOD_RADIUS=5.500000

, и мы всегда помнили, что:

DDM (11 December 2012 — 15:06) писал:

(если поставить больше — словим OOM)

Сегодня в летя рейс AB 7318 EDDT-OMDB, несмотря на все меры предосторожности от такого рода ошибок (как значение LOD_RADIUS так и  значение Autogen density=Very DenseDense, x64 ОС, Виртуальная память 3072-3072 на системном диске)

Spoiler

все таки словил ошибку «out of available memory» :vava: , которой не видел на своем мониторе очень давно. Думаю, все знают как это происходит, FSUIPC несколько раз подает звуковой сигнал, затем спустя некоторое время и появляется «заветное» окошко. Попытки закрыть все открытые сторонние приложения и в аварийном порядке выключить весь автоген и т.п. не привели :nea: Обидно после 6 часов полета, не так ли? Раз есть проблема, значит, есть и её решение. Вот я и отправился его искать.
В процессе стандартного гугления наткнулся на эту тему. Кратко прочитав первый пост, согласился с автором второго:

FSMP сказал:

TOO GOOD TO BE TRUE!

Да и следующие посты оптимизма не преувеличивали, но я все же решил попробовать описанные действия.
По-русски:
1) Скачиваем это. (! Это для пользователей FSX SP2, коим я и являюсь, для пользователей разгона см. тему)
2) При помощи нехитрого и интуитивно понятного инсталлера патчим свой api.dll (о бэкапе можно не беспокоится, утилитка об этом позаботится)
3) Соответственно смотрим результат.
=> Чем я и занялся. У меня CTD в ходе произошел когда отметка используемой памяти приближалась к 3 Гб, поэтому я отправился на тестирование с попыткой искусственно вызвать OOM, приложив для этого все усилия: все настройки на максимум, тяжелая сцена, тяжелый крафт. Максимумы использованной памяти я фиксировал: 3.194 Гб, 3.177 Гб, 3.151 Гб. на «заходе» (в кавычках, т.к. заход был а аркадном режиме) в KJFK от FsDreamTeam, повторюсь на максимально возможных настройках. ФПС «порадовали» :sarcastic: В Дубаях от FSDreamTeam где и произошел вылет, так же тестировал, но там мне не удавалось сделать так, чтобы расход памяти стабильно переступил отметку в 3 гб. (не виртуальной, а физической, речь насколько я понимаю, все время идет о ней).
«Нотариально заверенный скриншот» ( :rtfm: еще раз прошу не обращать внимания на приборы и положения ВС относительно ВПП, ибо не в этом суть)  пересечения отметки в 3 Гб. Конечно, полноценным тестированием этого фикса может быть только полноценный регулярный полет на тяжелом крафте, в тяжелую сцену, но в 2 часа ночи этого делать как то не хочется :secret:
Честно сказать, даже не знаю, что и думать. Может ли это быть страховкой от таких вылетов в дальнейшем? Пока, я не нашел аргументов что бы не оставить патченный api.dll в свой системе, хотя тестирование будет еще продолжаться. Так же на просторах Интернета было обнаружено это. Кто что обо всем этом думает? Предлагаю продолжить обсуждение, если, конечно, я не вынес в отдельную тему давно известный баян (в случае чего заранее извиняюсь).

Сообщение отредактировал BK-117_Pilot: 16 December 2012 — 03:31

Ответов: 19

Оказалось, что 3.194 это не предел, хотя на авсим.коме в ветке говорят о OOM после пересечения отметки в 4 гб. FSUIPC предупреждал о грядущем OOM, но его не следовало. Значит, что это, возможно, можно считать панацеей от этой болячки.
Untitled.png

Я все ближе подхожу к выводу, что это открытие avsim.com -а равносильно открытию панацей вроде HIGHMEMFIX=1 и ему подобных. Странно, что она не является must-have-ом… В общем, пробуйте!

Сообщение отредактировал BK-117_Pilot: 16 December 2012 — 03:42

Пробовал это (api. dll). В первом же полете словил ошибку чтения файла (PAFA-PANC, Aerosoft + UT Alaska Max Setting). Там чел это для х32 делал и строго для «Ускорения». Тем неменее — слежу за событиями…

Сообщение отредактировал Enzzo: 16 December 2012 — 09:38

Интересная новость, взял на заметку.

Stetter (16 December 2012 — 12:55) писал:

Да не в этом дело. Я так понял речь же идёт о  32 системе. Причёт тут 8 гиг.? А FSX на 32 битной ОС идёт куда шустрее  чем на X64,вся соль как раз в нехватке оперативной памяти в 32 системе.

Речь идет об x64. У меня сейчас 8 Гб физической памяти. x64 ибо уже является must-have-ом.
Я полетаю с этой dll, говорят, что не только мне она помогла. Посмотрим, что получится.

Сообщение отредактировал BK-117_Pilot: 16 December 2012 — 15:39

У меня 8Гбайт оперативы, файл подкачки-12Гб не на системном диске! Вылетов связанных с нехваткой памяти нет! Позже скринчик про симовскую нагрузку закину-выжму всё там в максимале!

Прикрепленные изображения

  • файл подкачки.jpg

Да не в этом дело. Я так понял речь же идёт о  32 системе. Причёт тут 8 гиг.? А FSX на 32 битной ОС идёт куда шустрее  чем на X64,вся соль как раз в нехватке оперативной памяти в 32 системе.

Zorgair (16 December 2012 — 17:44) писал:

Вот! Летал-аркадничал 2 часа в пакете Канада-Америка от ORBX(всё на максимале и траффик 50% с плохой-ветрянной погодой)-заскринил начало(30 минут)…вообщем не растёт размер в мегабайтах-скачет бывало до 2500мбайт и всё! Вылетов нет…их и небыло у меня! :preved:

Так ты летел в глубинке так сказать. У меня расход памяти в ходе регулярного рейса возрос до 3000 гб в Дубаях от Тампы и произошел вылет сима после 6 часов полета. А так у меня тоже такие вылеты редкость, но раз проблема проявилась, то её нужно было решить.

Enzzo (16 December 2012 — 18:32) писал:

ORBX сам по себе вовсе не тяжел и отлично оптимизирован. Летал там 2года вполне комфортно на Е8400 и 4 гб ОЗУ. Настройки АЫЧ очень высокие, но не о каких ООМ не помышлял. Наивно полагал, что ловят его какие то «лохи», сидящие на 32х. :)
Теперь у меня комп из разряда «Маст Хэв Фо АЫЧ за 60 руб», разогнан, памяти с гаком. И я теперь знаю, что такое ООМ. Если хотите нагнуть аппарат, слетайте но маршруту, что я написал выше. Дальность прорисовки и автоген можно даже не завышать…

Согласен, что ловить OOM в ORBX будет сложно. А вот в Анкоридже от а-софта + UT Alaska самое то.
Не знаю, я никогда не летал в FSX на x32 на тяжелых крафтах в тяжелых сценах. Только на слабом ПК с дефолтном баловался.

Сообщение отредактировал BK-117_Pilot: 16 December 2012 — 18:37

Zorgair (16 December 2012 — 18:32) писал:

Я просто подумал взять сцену которая тяжёлая в объёме! Дубай весит-то всего 800мбайт где-то! А я летал в том месте где общий размер тех мест превышает 5Гбайт! Да и давно…когда 9-ти часовой перелёт из Менорки в Кетчикан совершал… не видел там более 2800мбайт в диспетчере в процессе fsx да и то местами-в среднем ниже было!! Этот сим не понять! :nea:

Одно я знаю, наверняка, теперь от вылетов с «недостатком» памяти я застрахован чуть более лучше. Лишняя страховка никогда не помешает.

Enzzo (16 December 2012 — 18:40) писал:

В UT Alaska каждый самый мелкий домишко представляет собой сценарный объект (при макс настройках). Прикиньте, сколько их в районе крупного города и его окрестностей?

Знаю. Сейчас вот ставлю Анкоридж что бы проверить окончательно ли я застрахован от ООМ-ов в дальнейшем. С UTAlaska мне не летать по Европе, но лучшего места для проверки нет.

Enzzo (16 December 2012 — 18:32) писал:

ORBX сам по себе вовсе не тяжел и отлично оптимизирован. Летал там 2года вполне комфортно на Е8400 и 4 гб ОЗУ. Настройки АЫЧ очень высокие, но не о каких ООМ не помышлял. Наивно полагал, что ловят его какие то «лохи», сидящие на 32х. :)
Теперь у меня комп из разряда «Маст Хэв Фо АЫЧ за 60 руб», разогнан, памяти с гаком. И я теперь знаю, что такое ООМ. Если хотите нагнуть аппарат, слетайте но маршруту, что я написал выше. Дальность прорисовки и автоген можно даже не завышать…

А если и буду летать дальние рейсы в Анкоридж, уже на всякий случай поставил UT Alaska на минимум ибо…

Enzzo (16 December 2012 — 18:57) писал:

Кстати, если Анкоридж не «всамделишный», то будет еще веселее :) . В патче 1.01 заметно на глаз улучшены фпс, ну или плавность.

1.01 на борту

Вот! Летал-аркадничал 2 часа в пакете Канада-Америка от ORBX(всё на максимале и траффик 50% с плохой-ветрянной погодой)-заскринил начало(30 минут)…вообщем не растёт размер в мегабайтах-скачет бывало до 2500мбайт и всё! Вылетов нет…их и небыло у меня! :preved:

Прикрепленные изображения

  • Изменение размера 1test.jpg
  • Изменение размера 2test.jpg
  • Изменение размера 3test.jpg
  • Изменение размера 4test.jpg
  • Изменение размера 5test.jpg
  • Изменение размера 6test.jpg

ORBX сам по себе вовсе не тяжел и отлично оптимизирован. Летал там 2года вполне комфортно на Е8400 и 4 гб ОЗУ. Настройки АЫЧ очень высокие, но не о каких ООМ не помышлял. Наивно полагал, что ловят его какие то «лохи», сидящие на 32х. :)
Теперь у меня комп из разряда «Маст Хэв Фо АЫЧ за 60 руб», разогнан, памяти с гаком. И я теперь знаю, что такое ООМ. Если хотите нагнуть аппарат, слетайте но маршруту, что я написал выше. Дальность прорисовки и автоген можно даже не завышать…

Я просто подумал взять сцену которая тяжёлая в объёме! Дубай весит-то всего 800мбайт где-то! А я летал в том месте где общий размер тех мест превышает 5Гбайт! Да и давно…когда 9-ти часовой перелёт из Менорки в Кетчикан совершал… не видел там более 2800мбайт в диспетчере в процессе fsx да и то местами-в среднем ниже было!! Этот сим не понять! :nea:
В UT Alaska каждый самый мелкий домишко представляет собой сценарный объект (при макс настройках). Прикиньте, сколько их в районе крупного города и его окрестностей?

Кстати, если Анкоридж не «всамделишный», то будет еще веселее :) . В патче 1.01 заметно на глаз улучшены фпс, ну или плавность.

Невнимательно читали, что делает патч. Он убирает обработку ошибки HeapRealloc в случае когда она не может больше выделить памяти. Стандартная обработка предусматривает завершение процесса, т.е. fsx в этом случае. Получается, что сим продолжает работать хотя памяти больше не выделяется. Поэтому и фпс растет — вместо отрисовки и обсчета дополнительных обьектов ничего не делается. Все новое добавлется только после уничтожения старого и освобождения адресного пространства. Хорошо, если это графические обьекты ландшафта, а вот если память не получит что-то другое, то глюки гарантированы.

Не получится прорваться за 2Гб или 3Гб, в зависимости от того как они были скомпилированы, в 32 битном приложении. И дело не в количестве памяти, а в адресуемом пространстве. Почему так, можно почитать тут: http://wm-help.net/b…64/59464-6.html

Предвосхищая вопрос почему такие цифры и почему под 64 битной win по другому, то если почитать внимательно по ссылке выше то можно узнать, что 32 битное приложение может адресовать 4Гб, но верхние 2 или 1Гб забирает система. Т.е. диспетчер задач показывает общее использование памяти в адресном пространстве процесса.
При запуске под 64 битной системой, в которой 32 битные приложения выполняются под эмулятором WoW64, сильно снижается нагрузка как раз на эти верхние 2Гб и уменьшается вероятность проблем нехватки адресного пространства там, плюс освобождается возможность заюзать 1Гб дополнительно для тех dll, которые это могут. Сам fsx по всем признакам не может видеть более 2Гб.

Решение проблемы, поставить 16-32 Гб оперативки :), и забить на ООМ.

Сообщение отредактировал НЕБО: 16 December 2012 — 23:49