Использование более 4Гб оперативной памяти в 32 битных гостевых операционных системах


Не секрет, что 32 битные операционные системы не позволяют адресовать более 4Гб оперативной памяти. Сейчас я вам хочу рассказать как это ограничение можно косвенно обойти в виртуальной среде, где есть полноценный доступ к хостовой операционной системе.

Собственно, цель достаточно ясна – это позволить гостевой x32 операционной системе использовать помимо «честных» 4Гб оперативной памяти еще какое-то количество, которое можно безболезненно выделить из доступной.

Для начала опишу краткий план достижения цели, а потом рассмотрим детали и реализацию. Но сразу оговорюсь, что данный способ, конечно же, не позволит операционной системе «увидеть» больше памяти, чем она может это себе позволить, но вот использовать ее незаметно для себя она будет.

Начнем

Исходные данные:
  • Host: Ubuntu 12.04 x64, RAM 8Gb
  • VM: VMware Player 4.0.4
  • Guest: Windows XP SP3 x32, RAM 3Gb

Дополнительную оперативную память будем «выделять» необычным способом, для этого создадим vmdk диск и расположим его в оперативной памяти хост системы. Созданный диск подключим к гостевой системе. Для начала полноценного использования дополнительной оперативной памяти останется только переместить на этот диск файл подкачки. Кроме переноса файла подкачки можно перенастроить некоторые программы на хранение своих кэшей или временных файлов в этой «оперативной памяти», но это уже зависит от ее объема.

Некоторые детали

  • Размер создаваемого vmdk диска можно рассчитать следующим образом:
    (ОЗУ доступная хост системе) — (ОЗУ переданная VM) — k
    где k – это минимальное необходимое количество ОЗУ для работы хост системы.
  • Так как vmdk диск должен располагается в оперативной памяти, то его следует туда помещать, как минимум, каждый раз после загрузки системы
  • Так как I/O операции в оперативной памяти достаточно быстры, нет необходимости создавать preallocated (т.е. с заранее выделенным местом) файл vmdk диска.
  • Желательно, чтобы конфигурация файла подкачки содержала минимальный и максимальный его размер, приблизительно равный объему созданного vmdk диска. Этот размер будет немного отличаться от указанного объема при создании vmdk, так как часть места займет файловая система и служебная информация самой системы.
  • Для размещения vmdk файла в оперативной памяти нужно эту память подготовить для доступа к ней из файловой системы.
  • В большинстве случаев при использовании такого тюнинга уже нельзя будет воспользоваться функцией «Suspend» в vmplayer.

Интересный факт: если vmdk диск был сделан не preallocated (т.е. «резиновый»), а файл подкачки был настроен так, как описано выше, то есть максимального и фиксированного размера, то, несмотря на то, что файл подкачки займет все пространство vmdk диска, в хосте этот vmdk файл будет занимать места почти так же, как и до переноса на него файла подкачки. Естественно, это не может не порадовать, так как гостевая система будет использовать дополнительную оперативную память по мере необходимости, правда, только в сторону увеличения.

А теперь пошаговая инструкция для конфигурации описанной выше

  1. Конфигурируем хостовую файловую систему, так чтобы через нее получить доступ ко всей оперативной памяти. Для этого в файл /etc/fstab нужно добавить, такую строку:
    tmpfs /run/shm tmpfs size=8G 0 0
  2. Создаем однофайловый, не preallocated vmdk диск. Указываем размер 3Gb и сохраняем его в /run/shm с именем ramtemp.vmdk. После создания отключаем кеширование записи на этом диске.
  3. Загружаем виртуальную машину. Создаем на появившемся в гостевой системе диске основной раздел, форматируем его и метим его, как ramtemp. Монтируем его в предварительно созданную папку c:\ramtemp. Да, да, в Windows так тоже можно делать, это когда вместо выбора буквы диска выбирается пункт «Подключить том как пустую NTFS папку». Подключение в папку делается, чтобы не плодить в системе лишние неиспользуемые «буквенные диски». Так же следует отключить индексирование этого диска в его свойствах. После этого виртуальную машину выключаем.
  4. Далее, подготовленный /run/shm/ramtemp.vmdk копируем в папку с целевой виртуальной машиной и переименовываем в ramtemp.vmdk.new. Делается это для того, чтобы случайно не подключить этот диск к виртуальной машине и не начать использовать. Этот диск необходим всегда в своем первозданном виде, чтобы занимал свой минимальный объем.
  5. Для всех последующих запусков виртуальной машины нужно создать скрипт, который будет автоматически перед запуском копировать чистый ramtemp.vmdk в виртуальную память и запускать виртуальную машину. Например, он может быть таким:
    #!/bin/sh
    cp /home/vm/workstation/ramtemp.vmdk.new /run/shm/ramtemp.vmdk
    vmplayer /home/vm/workstation/workstation.vmx 
  6. Снова запускаем виртуальную машину и перемещаем файл подкачки в «оперативную память». Для этого переходим в ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management и меняем путь к файлу подкачки на c:\ramtemp\pagefile.sys в параметре PagingFiles. После все сделанного выше нужно перезагрузить гостевую ОС.

После выполнения всех шагов можно считать вашу виртуальную машину официально прокачанной.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 41

  • UFO just landed and posted this here
      0
      • UFO just landed and posted this here
          0
          Фантастика. 3 ГБ всё же преодолимы… Спасибо большое.
            +1
            … были преодолимы задолго до появления Windows XP. Просто XP официально так не умеет.

            64 Гб можно адресовать на процессорах начиная с Pentium Pro, 1995 год
        +1
        Жесть. Почему просто не поставить 64-битную Windows?
          +1
          Возможно, потому что 64-битная Vista или Windows 7 будут занимать намного больше места как на диске, так и в оперативке, а 64-ю Windows XP надо ещё поискать, а потом заставить работать :)

          У меня другой вопрос: какой же софт в виртуальной машине требует больше 3 ГБ опертивки? Может, для фотошопа проще наоборот, Windows 7 64 bit, а в ней Ubuntu? :)
            +2
            В моем случае, виртуальная машина — мое рабочее место, на переносном USB 3 жестком диске. Я часто работаю в трех разных городах, и мне удобно возить с собой именно такой девайс. Windows XP — это потому что, пока мы не перешли на Windows 7, ибо лицензирование. А память как ни странно жрет Chrome, корпоративная почта, антивирус и что-то еще, но главный пожиратель — это все же Chrome.
              +1
              Отказаться от Chrome?!
              +5
              странно… вставляете в ноут/комп 8Гб (вместо 2 или 4) и при этом поставить 64битную версию винды нельзя, будет больше памяти есть
              тогда зачем она(память) вам нужна??
                +6
                Что бы написать пост на хабре и получить инвайт.
                  0
                  Ну полно вам. Человек ведь красиво решил свою проблему. Мне например понравилась его идея.
                    0
                    никто не отрицает что способ решения проблемы интересный и стоит внимания в общеобразовательных целях
                  +1
                  У нас было 2 камня core i7, 75 гектар оперативки, 5 ssd и целое множество шнурков всех сортов и расцветок… Единственное что вызывало у меня опасение — это tmpfs. Нет ничего более беспомощного безответственного и испорченного чем база при внезапном ребуте неспасенная из tmpfs. Я знал, что рано или поздно мы перейдем и на эту дрянь…
                  0
                  а потом заставить работать :)

                  Хм, XP x64 прекрасно работала с момента выхода. Даже постабильнее, чем обычная Windows XP — ядро же посвежее.
                  +1
                  Думаю правильней так: если есть возможность, нужно поставить 64-битную систему.
                  Но статья как раз для другого случая. Вы не считаете?
                  +3
                  Еще можно заявить, что на компьютере с жестким диском возможно достижение скорости работы ссд, если в гостевой ос замапить вообще все на рам-диски.
                    0
                    Хм, начала поста не соответствует действительности — 32х битные системы не могут адресовать больше 4Гб памяти, при этом на эти 4Гб мапится адресация портов и видео встроенное. Поэтому доступно меньше 4Гб. Например на WinXP из 4х доступно 3-3,5Гб.
                    Извините, если не очень в тему, но это просто уточнение вопроса.
                      0
                      Спасибо большое! Поправил.
                        0
                        Могут. У меня 8гб на win xp 32bit. верхние 4,5гб как рам диск висят. Если может работать рамдиск значит система может адресовать. Но не использовать, конечно.
                          –2
                          Интересный вывод. И как же вы в 4 байта запихнете адресацию больше чем на 4Гб? Ведь софт то 32-х битный, и приложение использует именно 4-х байтовые указатели
                            +1
                            рамдиск даёт доступ к ним через систему, ибо требуется поддержка PAE. А то, что сама система и приложения не использующие работу через PAE не могут — я написал ещё в первом комментарии.
                              0
                              Извиняюсь, думал речь идет о адресации на приложение.
                            0
                            Хм, а не подкините мануальчик с подробностями реализации?
                              0
                              Вот тут мануальчик, который заключается только в добавлении /pae в boot.ini, а вообще чтобы pae работал он должен поддерживаться процессором.
                          0
                          Проблема 32-х битных систем не в том что они вообще поддерживают не более 4 Гб виртуальной памяти памяти (32-битные Windows Server 2000 Advanced без проблем поддерживает и больше, да и обычная XP c файлом подкачки я думаю тоже), а в том что адресное пространство процесса ограничено 4Гб и часть его съедает ядро.

                          Хотя и для преодоления этого ограничения есть всяких хитрости, типа PAE. Но это костыли, а костыли это потеря скорости и более сложный процесс разработки. 64-битному процессу доступно куда большее адресное пространство без всяких ухищрений.
                            –3
                            Адресное простанство процесса ограничено двумя гигабайтами.
                              0
                              Для адресации 2 Гб 32 бита ни к чему, достаточно 31 бит. Вот тут все вполне лаконично описано:
                              The virtual address space for 32-bit Windows is 4 gigabytes (GB) in size...
                                0
                                Есть еще и костыль в виде /3gb, однако требуется:
                                To enable an application to use the larger address space, set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header. The linker included with Microsoft Visual C++ supports the /LARGEADDRESSAWARE switch to set this flag

                                msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx
                                  0
                                  А я говорю — два гигабайта на процесс. blogs.msdn.com/b/tom/archive/2008/04/10/chat-question-memory-limits-for-32-bit-and-64-bit-processes.aspx

                                  И костыль до трех есть, но я изначально про то, что не 4.
                                    0
                                    Адресное пространство каждого процесса — ровно 4 Гб.

                                    Просто один или два гигабайта из этих четырёх используются для интерфейсов ОС-приложение (хранения общих библиотек и т. п.), и недоступны для прикладных данных. Однако, все эти интерфейсы и библиотеки, тем не менее, доступны для нашего приложения именно в рамках его адресного пространства. Вы можете в своей программе получить адрес такой-то функции из разделяемой библиотеки, хотя она находится в «недоступной» памяти, а потом вызвать эту функцию по адресу. Таковой адрес в приложении существует — значит, находится в пространстве адресов приложения.

                                    Причём, этот адрес в принципе может быть разным для разных приложений: в одном приложении библиотека маппится на одни адреса, в другом — на другие. А физически в памяти она вообще хранится один раз.

                                    Ещё раз: то, что какая-то область недоступна для приложений, никак не исключает эту область из адресного пространства.

                                    В IBM PC был процессор 8086. Разрядность его адресной шины — 20 бит, т.е. 1024 Кбайт. А в компьютере могло быть до 640 Кбайт ОЗУ. Остальное адресное пространство (384 Кбайт) отводилось для memory-mapped устройств: видеопамяти, ПЗУ и прочего. Это не означало, что «адресное пространство 640 Кбайт», это означало, что «размер ОЗУ 640 Кбайт», а простраство — 1 мегабайт, как положено.
                                      0
                                      Хех, пока искал пруфы, тут уже развернутый ответ накатали :)
                                        0
                                        Не соглашусь. Можно сколько угодно придираться к словам, и тыкать циферками, но на 32 битной системе процесс не может адресовать больше 2х гигов без включенного флага large address aware.

                                        Технически, 32 битный процесс способен адресовать 4Гб, с этим я не спорю. Но 32 система(без флага /3GB) его ограничивает 2 гигабайтами, хоть ты трести.

                                        А вот если 32 битный процесс запустить на 64 битной системе, тогда он как положено сможет адресовать 4Гб.
                                          0
                                          А для 32-битного процесса разве не эмулируется 32-битное окружение, с shared-библиотеками «вверху памяти» и т.п.? остаются все те-же 2гб минус занятое библиотеками место, откуда 4?
                                            0
                                            Забыл добавить: нужно не забывать разницу между понятиями «может адресовать» и «может использовать»
                                              0
                                              Марк пишет что

                                              Because the address space on 64-bit Windows is much larger than 4GB, something I’ll describe shortly, Windows can give 32-bit processes the maximum 4GB that they can address and use the rest for the operating system’s virtual memory.

                                              blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
                                          +1
                                          И все таки 4Гб на процесс, но верхний диапазон адресов: 0x80000000-0xFFFFFFFF не доступен из user mode.
                                          Пруф ищите текст: Если говорить совсем точно, то раздел для ваших данных в случае 32-х бит имеет диапазон $0000FFFF-$7FFEFFFF
                                            0
                                            А я читал Руссиновича, а не Алексеева. Сходу, одной строчкой:

                                            blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx

                                            Even if the thread had no code or data and the entire address space could be used for stacks, a 32-bit process with the default 2GB address space could create at most 2,048 threads.
                                      +1
                                      Нет там потерь. Собственно PAE выполняет блок MMU в процессоре, полностью аппаратно, да ещё и с использованием TLB (буфер трансляций).

                                      С точки зрения разработки приложения вообще никакой разницы: как писалось под 4 Гбайт, так и пишется.
                                      +1
                                      идея стара как мир. можно создать рамдиск и поставить на него гостевую систему целиком ))
                                        +1
                                        В общем, проблема с 4 Гбайтами памяти в XP — проблема не XP. Процессор-то умеет, ОС в принципе тоже умеет, но вот некоторые драйверы (были) уверены, что 32 бит достаточно. А ещё в этом (было) уверено некоторое оборудование, которое имеет доступ к памяти помимо процессора, т.е. DMA, а также контроллеры PCI.

                                        Совместимость, блин. Уже в Windows 98 или в Windows NT 4 можно было сделать доступными более 4 Гбайт, но не делали из-за проблем с совместимостью устройств.

                                        А вообще проблемы, описанной в топике не существует. У меня есть 32-битная машина с линуксом и 12 гбайт ОЗУ, и вся эта память отлично видна и используется ОС и приложениями (каждому из них, правда, достаётся по-прежнему не более 4 Гбайт — адресация в MMU 32-битная, никуда не денешься). В десктопной винде это просто намеренно отключено.

                                        Only users with full accounts can post comments. Log in, please.