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

[QRH 584]

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

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

LOD_RADIUS=5.500000

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

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

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

 

 

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

В процессе стандартного гугления наткнулся на эту тему. Кратко прочитав первый пост, согласился с автором второго:

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 в свой системе, хотя тестирование будет еще продолжаться. Так же на просторах Интернета было обнаружено это. Кто что обо всем этом думает? Предлагаю продолжить обсуждение, если, конечно, я не вынес в отдельную тему давно известный баян (в случае чего заранее извиняюсь).

[QRH 584]

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

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

[Enzzo 1111]

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

[Stetter 265]

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

[Stetter 265]

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

[QRH 584]

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

Речь идет об x64. У меня сейчас 8 Гб физической памяти. x64 ибо уже является must-have-ом.

Я полетаю с этой dll, говорят, что не только мне она помогла. Посмотрим, что получится.

[QRH 584]

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

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

[Enzzo 1111]

ORBX сам по себе вовсе не тяжел и отлично оптимизирован. Летал там 2года вполне комфортно на Е8400 и 4 гб ОЗУ. Настройки АЫЧ очень высокие, но не о каких ООМ не помышлял. Наивно полагал, что ловят его какие то "лохи", сидящие на 32х.

Теперь у меня комп из разряда "Маст Хэв Фо АЫЧ за 60 руб", разогнан, памяти с гаком. И я теперь знаю, что такое ООМ. Если хотите нагнуть аппарат, слетайте но маршруту, что я написал выше. Дальность прорисовки и автоген можно даже не завышать...

[QRH 584]

ORBX сам по себе вовсе не тяжел и отлично оптимизирован. Летал там 2года вполне комфортно на Е8400 и 4 гб ОЗУ. Настройки АЫЧ очень высокие, но не о каких ООМ не помышлял. Наивно полагал, что ловят его какие то "лохи", сидящие на 32х.

Теперь у меня комп из разряда "Маст Хэв Фо АЫЧ за 60 руб", разогнан, памяти с гаком. И я теперь знаю, что такое ООМ. Если хотите нагнуть аппарат, слетайте но маршруту, что я написал выше. Дальность прорисовки и автоген можно даже не завышать...

Согласен, что ловить OOM в ORBX будет сложно. А вот в Анкоридже от а-софта + UT Alaska самое то.

Не знаю, я никогда не летал в FSX на x32 на тяжелых крафтах в тяжелых сценах. Только на слабом ПК с дефолтном баловался.

[QRH 584]

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

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

[Enzzo 1111]

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

[QRH 584]

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

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

[QRH 584]

ORBX сам по себе вовсе не тяжел и отлично оптимизирован. Летал там 2года вполне комфортно на Е8400 и 4 гб ОЗУ. Настройки АЫЧ очень высокие, но не о каких ООМ не помышлял. Наивно полагал, что ловят его какие то "лохи", сидящие на 32х.

Теперь у меня комп из разряда "Маст Хэв Фо АЫЧ за 60 руб", разогнан, памяти с гаком. И я теперь знаю, что такое ООМ. Если хотите нагнуть аппарат, слетайте но маршруту, что я написал выше. Дальность прорисовки и автоген можно даже не завышать...

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

[Enzzo 1111]

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

[QRH 584]

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

1.01 на борту

[AMX 1]

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

 

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

 

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

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

[skyKostik 587]

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

[QRH 584]

Невнимательно читали, что делает патч. Он убирает обработку ошибки 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Гб.

Дело было ночью. Особо не вдавался. Но все же лучше так и без вылета.

[QRH 584]

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

Обнаружил, что файл подкачки у меня выставлен на 3072-3072, поставил 12XXX=12XXX, посмотрим результат.

[AMX 1]

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

 

Увеличение оперативки никак не решает проблему. 32 битное приложение в принципе не может использовать более 3Гб памяти.

 

[skyKostik 587]

Мы про 64х битную винду, насколько я понял.

У меня подкачка по умолчанию стоит 16,4 Гб (чот много, кстати. Обнаглела винда совсем )

[AMX 1]

Обнаружил, что файл подкачки у меня выставлен на 3072-3072, поставил 12XXX=12XXX, посмотрим результат.

 

Вот это больше похоже на источник проблемы. Вся память изначально выделяется там. Физическая память выделяется диспетчером памяти только по необходимости и наличия свободных ресурсов. И может использоваться повторно - в одном процессе сбрасывается в файл подкачки, физическая отдается другому и так по кругу. Поэтому от определенного предела размер физической памяти влияет только на производительность, а не на возможность использования того или иного количества "памяти".

[AMX 1]

Мы про 64х битную винду, насколько я понял.

 

64 битная винда не отменяет ограничений для 32 битных приложений к сожалению.

[QRH 584]

Если решил выставить файл подкачки, то он должен быть выставлен в полтора раза(вроде) больше твоей установленной оперативы! И помним, что Win7 64bit Home premium(если она у тебя стоит)-видит только 16 Гбайт!!! А вот Professional, Enterprise и Ultimate видит до 192Гбайт! Исходный и максимальный размер должен быть одинаковым! А симу особо это и не поможет...она 32 битное уродство!

Вспомнил уже про это правило. Выставил как ннада)

[QRH 584]

Сумел наконец выполнить полноценный полет. OMDB-EDDV. Автоген даже поставил на very dence. Все прошло штатно. На стоянке посмотрел сколько занято памяти: >3 Гб. => был я спасен от OOM неминуемого казалось бы. Поэтому эту траблу в мастхэв.