Подтвердить что ты не робот

Разработка и отладка приложений С# для mem-hogging

У меня есть приложение С#, которое должно связываться с 32-битной библиотекой, а также использовать максимальный возможный объем памяти (приложение для обработки изображений); мы запускаем приложение на настольных компьютерах XP64, поэтому мы используем WOW64, настраиваем таргетинг в Visual Studio для x86 (и делаем пост-сборку editbin /largeaddressaware). Мы сталкиваемся с несколькими проблемами:

  • В встроенном отладчике Visual Studio мы можем использовать только 2 ГБ памяти (~ 1,5 гб для приложения, плюс накладные расходы)

  • Запуск из командной строки, приложение может видеть 3 ГБ памяти, но документы Microsoft, похоже, говорят, что мы должны увидеть 4gb.

Может ли кто-нибудь сказать мне, как получить приложение WOW64 С#, чтобы увидеть полный 4gb, который платформа должна уметь его отдать?

Кроме того, может ли кто-нибудь сказать мне, как заставить отладчик Visual Studio (VS 2008, иначе известный как VS90) подчиняться бит /largeaddressaware и прекратить ограничение памяти приложения на 2gb?

Я вижу то же поведение в VS80 и VS90; также нет разницы между .NET Framework 3.5, 3.0 и 2.0. Здесь тривиальная программа на С#, которая иллюстрирует проблемы; построить для x86, editbin /largeaddressaware, а затем запустить во встроенном отладчике или запустить из командной строки, чтобы увидеть разницу в памяти, доступную для С#.

namespace MemoryAllocTest
{
class Program
{
    static void Main(string[] args)
    {
        const int allocSize = 1024 * 1024;
        List<byte[]> myMem = new List<byte[]>();
        UInt64 totalAlloc = 0;

        while (true)
        {
            myMem.Add(new byte[allocSize]);
            totalAlloc += allocSize;
            Console.WriteLine("{0} allocs: {1}MB total", 
             myMem.Count, totalAlloc / (1024 * 1024));
        }
    }
}
}
4b9b3361

Ответ 1

может ли кто-нибудь сказать мне, как заставить отладчик Visual Studio (VS 2008, иначе известный как VS90) подчиняться бит /largeaddressaware и остановить ограничение памяти приложения на 2gb?

Для этого требуются два шага - оба в свойствах проекта:

  • на вкладке "События сборки", установите шаг postbuild для запуска editbin /largeaware $(TargetPath)
  • на вкладке отладки, снимите флажок Включить хостинг Visual Studio Процесс

С помощью этих двух шагов ваша программа-образец работает до 3045 МБ

Ответ 2

Спасибо всем, кто ответил; этот сайт действительно качается!

Похоже, что мы действительно получаем пользовательское пространство 4gb в WOW64, но мне кажется (слегка образованное предположение), что накладные расходы сборщика мусора (или, возможно, запас прочности) становятся значительными, поскольку память, выделяемая управляемым кодом, растет. Запуск моего тестового приложения на WOW64 (командная строка, с LARGEADDRESSAWARE), я получаю общие ассигнования 3175 МБ; работающий на машине WIN32 XP с набором параметров 4GT, я получаю общие ассигнования 2857 МБ: так что полный концерт дополнительной памяти пользовательского режима дает увеличение только на ~ 318 МБ на уровне уровня С#!

(Я изменил свою тестовую программу, чтобы уменьшить размер единицы распределения при сбое распределения, а также добавил призывы к стратегическому принудительному сбору мусора в попытке немного приблизиться к пределу того, что может быть "нормальным" приложением для захвата - напишите примечание здесь, если вы хотите, чтобы я опубликовал пересмотренный код.)

В любом случае, еще раз спасибо всем; похоже, что система работает правильно, но управляемая среда получает меньшее улучшение от дополнительного накопителя памяти, чем можно было ожидать.

Ответ 3

От Microsoft:

Виртуальное адресное пространство процессов и приложения по-прежнему ограничены 2 GB, если переключатель /3GB не используется в файл Boot.ini. Когда физическое ОЗУ в системе превышает 16 ГБ и используется переключатель /3GB, система будет игнорировать дополнительную ОЗУ пока переключатель /3GB не будет удален. Эта из-за увеличенного размера ядро должно поддерживать больше Записи в таблице страниц. Предположение что администратор скорее не потерять функциональность /3 ГБ тихо и автоматически; следовательно, это требует от администратора явно измените этот параметр. Переключатель /3GB выделяет 3 ГБ виртуального адресного пространства для приложение, которое использует IMAGE_FILE_LARGE_ADDRESS_AWARE в заголовок процесса. Этот переключатель позволяет приложений для адреса 1 ГБ дополнительное виртуальное адресное пространство выше 2 ГБ.

Ответ 4

Какую точную версию .NET вы используете? Этот отчет о подключении относится к одной и той же проблеме (насколько я могу судить), рассмотренной на .NET 2.0, но исправленной в .NET 2.0SP1.

Если ваши компьютеры x64 не имеют версии 2.0SP1 (или более поздней версии), стоит попробовать...

Ответ 5

Я построил ваше простое примерное приложение из сообщения, разбил его и подключил к нему WinDbg.

! address -summary покажет вам эффективное адресное пространство пользовательского режима для процесса.

0:003> !address -summary
 TEB fffdd000 in range fffdb000 fffde000
 TEB fffda000 in range fffd8000 fffdb000
 TEB fffd7000 in range fffd5000 fffd8000
 TEB fffaf000 in range fffad000 fffb0000
 ProcessParametrs 004c2b40 in range 004c0000 00535000
 Environment 004c1978 in range 004c0000 00535000

-------------------- Usage SUMMARY --------------------------
    TotSize (      KB)   Pct(Tots) Pct(Busy)   Usage
   e7d2e000 ( 3798200) : 90.56%    98.77%    : RegionUsageIsVAD
   1547b000 (  348652) : 08.31%    00.00%    : RegionUsageFree
    2887000 (   41500) : 00.99%    01.08%    : RegionUsageImage
     3ff000 (    4092) : 00.10%    00.11%    : RegionUsageStack
          0 (       0) : 00.00%    00.00%    : RegionUsageTeb
     1c0000 (    1792) : 00.04%    00.05%    : RegionUsageHeap
          0 (       0) : 00.00%    00.00%    : RegionUsagePageHeap
       1000 (       4) : 00.00%    00.00%    : RegionUsagePeb
          0 (       0) : 00.00%    00.00%    : RegionUsageProcessParametrs
          0 (       0) : 00.00%    00.00%    : RegionUsageEnvironmentBlock
       **Tot: ffff0000 (4194240 KB)** Busy: eab75000 (3845588 KB)

-------------------- Type SUMMARY --------------------------
    TotSize (      KB)   Pct(Tots)  Usage
   1547b000 (  348652) : 08.31%   : <free>
    2aa3000 (   43660) : 01.04%   : MEM_IMAGE
    1f6a000 (   32168) : 00.77%   : MEM_MAPPED
   e6168000 ( 3769760) : 89.88%   : MEM_PRIVATE

-------------------- State SUMMARY --------------------------
    TotSize (      KB)   Pct(Tots)  Usage
   db838000 ( 3596512) : 85.75%   : MEM_COMMIT
   1547b000 (  348652) : 08.31%   : MEM_FREE
    f33d000 (  249076) : 05.94%   : MEM_RESERVE

Largest free region: Base fbfc0000 - Size 03fed000 (65460 KB)

На основе Tot: ffff0000 (4194240 KB) у нас есть 4 ГБ эффективного пространства пользовательского режима.

Также наш самый большой свободный блок составляет 65,460KB, что означает, что мы должны иметь возможность выделять больше памяти.

Ответ 6

Можете ли вы опубликовать, где это означает, что вы можете увидеть все 4 ГБ? О, может быть, здесь: Интересная информация по этой ссылке

Различия в адресной памяти

Первое, что замечают разработчики заключается в том, что 64-разрядные процессоры обеспечивают огромный скачок в количестве физических и виртуальную память, которая может быть адрес.

* 32-bit applications on 32-bit platforms can address up to 2 GB
* 32-bit applications built with the /LARGEADDRESSAWARE:YES linker flag

на 32-разрядной Windows XP или Windows Server 2003 с опцией загрузки /3gb может адресовать до 3 ГБ. Эта ограничивает ядро ​​только 1 ГБ которые могут вызвать некоторые драйверы и/или службы для отказа.

* 32-bit applications built with the /LARGEADDRESSAWARE:YES linker flag

в 32-разрядных версиях Windows Vista, и в 32-разрядных версиях Windows Название кода сервера "Longhorn" систем, может адресовать память до номер, указанный при загрузке элемент конфигурации (BCD) IncreaseUserVa. IncreaseUserVa может имеют значение от 2048, по умолчанию, до 3072 (что соответствует объем памяти, сконфигурированный /3gb для Windows XP). остаток от 4 ГБ выделяется ядра и может привести к сбою драйверов и сервисов.

Дополнительные сведения о BCD см. в разделе Загрузка данных конфигурации в MSDN.

* 32-bit applications on 64-bit platforms can address up to 2 GB, or up

до 4 ГБ с флагом /LARGEADDRESSAWARE: ДА.     * 64-разрядные приложения используют 43 бита для адресации, что обеспечивает 8 ТБ виртуальный адрес для приложений и 8 TB зарезервирован для ядра.

Итак, да, похоже, вы должны (на целевой платформе XP64) увидеть 4 ГБ.