C# и OutOfmemoryExtension — как перейти на полноценные 64х?

Question

[iamserge]

Собственно я пользователь "Microsoft Visual Studio Community 2022 (64-bit)" ... Но одолела меня проблема System.OutOfMemoryException хотя памяти свободной аж 60Gb, которой так много именно для того чтобы не скромничать и ворочать словари по 60М+ записей. Нашел статью более менее по теме. И даже намного более общую.

Итого есть кажется две беды:

1. Нужно обязательно х64 систему (она есть), х64 среду (ведь отладка идет и среда тоже работает пока я творю эти большие списки), х64 приложение что кажется универсальное и на скрине я нашел только одну галочку по теме из всего что касается моего приложения - не уверен что оно х64 га самом деле. Галочку я снял и попробовал еще разок - ... кажется помогло и словарь на котором я стабильно спотыкался был обработан ...



2. Нужен некий "непрерывный блок памяти" этого самого большого размера ... Речь идет о фрагментации подобно HDD как это было много лет назад кажется и вот беда я без понятия как с этим управляться.

То есть у меня есть память, резерв на эти дела аж 32Gb, то есть именно на эти списки и они еще ни разу не превышали 3,7Gb на деле, а ошибки я уже ловлю. В общем памяти много и хочется ей пользоваться а не перебирать все по 200-300Мб, боясь лишний раз чего то привысить.

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

Вопрос - как убедиться что моя VS2022 реально работает в х64 и если надо изменить на этот режиме работы. Где проверить что мое приложение тоже х64 и если надо перевести его в такой же режим работы? То есть чтобы и среда и приложение могли адресовать намного более 4Гб без всяких проблем, т.к. я уповаю что среди 32Gb минимум (а то и более чаще) они как то найдут себе "непрерывный" кусочек сами и без проблем все туда сложат ...

Вопрос по второй проблеме - я вообще могу как то помочь программе найти "цельный" кусок памяти? Т.е. заведомо я даю ей с запасом места ... может чистить как-то, может еще что ...

p.s. Объем данных на котором была обшибка как раз около 5-6Гб и пока вроде работает. НО!!!! Мало ли может мне повезло просто и я вот вот опять не буду иметь "цельного" куска памяти и опять все начнет ломаться на ходу ...

p.s.s. То есть пока работает, но я первый раз пишу такое крупногабаритное приложение и чувствую что мне сейчас кажется повезло, чем я и правда в курсе как этот процесс с памятью взять под контроль =((

Comments

[Роман]

x64 выбирается в выпадающем списке Platform как раз таки.

[iamserge]

Роман, Спс, а ведь и правда есть такой список =/

Answer 1

[Василий Банников]

Ну без кода сказать в чём конкретно проблема нельзя, но вот пара советов:

1. Убедись что Target platform у тебя x64 (Но вообще, если у тебя dotnet core, то он и так и так не будет упираться в 4гб)
2. Убедись, что где-то в недрах у тебя не выделяется массив более чем на int.MaxValue элементов (внутри словарей массив, если мне память не изменяет)
3. Убедись, что это ошибка именно из рантайма приходит, а не выкинуто где-то явно
4. Попробуй как-нибудь разделить свои данные, чтобы для их хранения не требовался непрерывный кусок памяти.
5. Если ты используешь net framework, а не net core, то тебе нужно в конфиге явно указать, что ты хочешь создавать объекты более 2гб размером.
https://docs.microsoft.com/en-us/dotnet/framework/...

VS2022 и так x64, да и даже если бы была х32, как в 2019 - это бы не повлияло на само приложение.
Ну и возьми dotMemory, чтобы продиагностировать проблемы в работе с памятью.

Comments

[iamserge]

1. Да целевая точно x64 и памяти много, т.е. этот пункт - ОК
2. Повсеместно использую Int64 если речь об этом ...
3. Она плавает, ну то есть это не одно место конкретное - почти каждый раз новое (видимо там где память по факту кончалась)
4. Именно этого хочу все меньше, даже думаю сделать себе +128GB еще просто чтобы не заниматья обслуживанием этих "кусочков" т.е. помнить где остановился и писать всякое лишнее
5. Обязательно перепроверю, т.к. сейчас чудо исполняется до сих пор и работает уже второй час как - но и понять где я и с чем мне не помешает. Не отличаю на слух core от framework на самом деле =)

VS на самом деле съела 1,7Gb и вроде как держится в рамках, хотя и трудно следить за ней вечно т.к. процесс долгий. Просто я так понял что она тоже может съесть много при запуске из нее, если приложение прожорливое - хз зачем, может как раз чтобы ошибки искать ...

dotMemory - ок попробую и его. Но кажется сами настройки приложения в VS исчерпаны и о боже мой кажется на этом все мои беды кончаются, по крайней мере сейчас ...

[Василий Банников]

iamserge,
2. От того что ты сам используешь int64 - не сделает размер массивов int64 :) Размер массива всё ещё описывается int32.
4. Ты всегда можешь сделать обёртку, чтобы API был такой, будто ты к единому куску обращаешься, а по факту он переадресовывается на какой-то из чанков :)
5. Если покажешь содержимое csproj-файла (в виде текста), то я смогу тебе сказать

[iamserge]

Василий Банников,
3. На самом деле именно по размеру он скромный. Всего то 60М записей, а в int аж 2Млрд. Столько у меня слава богу нету)
4. Ох, я тот кто не хочет даже просто это обрабатывать, не то чтобы еще обернуть это красиво и скрыть следы ... DDR4 сейчас дешевый довольно, а возится мне с ними много ...
5. Собственно файл и там и про Core есть и как будто у меня .net framework и я core тоже подключаю ...

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{10F57573-3782-4F08-B170-0082BFDD01DF}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <RootNamespace>FSA</RootNamespace>
    <AssemblyName>FSA</AssemblyName>
    <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <Deterministic>true</Deterministic>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <PlatformTarget>AnyCPU</PlatformTarget>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <Prefer32Bit>false</Prefer32Bit>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <PlatformTarget>AnyCPU</PlatformTarget>
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="MySql.Data, Version=8.0.29.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d, processorArchitecture=MSIL" />
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="System.Windows.Forms.DataVisualization" />
    <Reference Include="System.Xml.Linq" />
    <Reference Include="System.Data.DataSetExtensions" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Data" />
    <Reference Include="System.Deployment" />
    <Reference Include="System.Drawing" />
    <Reference Include="System.Net.Http" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="System.Xml" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Form1.cs">
      <SubType>Form</SubType>
    </Compile>
    <Compile Include="Form1.Designer.cs">
      <DependentUpon>Form1.cs</DependentUpon>
    </Compile>
    <Compile Include="Program.cs" />
    <Compile Include="Properties\AssemblyInfo.cs" />
    <EmbeddedResource Include="Form1.resx">
      <DependentUpon>Form1.cs</DependentUpon>
    </EmbeddedResource>
    <EmbeddedResource Include="Properties\Resources.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>Resources.Designer.cs</LastGenOutput>
      <SubType>Designer</SubType>
    </EmbeddedResource>
    <Compile Include="Properties\Resources.Designer.cs">
      <AutoGen>True</AutoGen>
      <DependentUpon>Resources.resx</DependentUpon>
    </Compile>
    <None Include="Properties\Settings.settings">
      <Generator>SettingsSingleFileGenerator</Generator>
      <LastGenOutput>Settings.Designer.cs</LastGenOutput>
    </None>
    <Compile Include="Properties\Settings.Designer.cs">
      <AutoGen>True</AutoGen>
      <DependentUpon>Settings.settings</DependentUpon>
      <DesignTimeSharedInput>True</DesignTimeSharedInput>
    </Compile>
  </ItemGroup>
  <ItemGroup>
    <None Include="App.config" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

[Василий Банников]

iamserge, в общем да, у тебя framework.
Переходи на dotnet 6

[iamserge]

Василий Банников, Уже прямо сейчас? А мне дорого оно обойдется? Я бы и просто конфиг бы не поленился поправить ... Хотя кажется уже поправлен иначе как объяснить словарики что были под 5-6Гб после снятия заклятой галочки. Может быть именно она и помогла мне с этим

[Василий Банников]

iamserge, по цене - зависит.
В поддержке net 6 сильно легче.
В некоторых случаях это можно полностью автоматически провести.
В некоторых других - придётся руками переписать часть кода, который привязан к платформе.

Вот тут инструкция: https://docs.microsoft.com/en-us/dotnet/core/porti...

[iamserge]

Василий Банников, ок, спасибо :) Когда я отойду от перманентного блаженства от того что все работает то пожалуй посмотрю на это серьезнее. Но пока ознакомлюсь все таки ...

Answer 2

[freeExec]

Фрагментация существует в самой памяти ОС, там вполне может не оказаться таких больших непрерывных блоков.
Чтобы убедиться в том что приложение 64-битное, надо смотреть флаги в его PE-заголовке. Или на худой конец в диспетчере задач, он подписывает 32-битные.
Тулза от людей из микрософт, которая показывала дефрагментацию оперативной памяти, там полный швах.

Comments

[iamserge]

Спасибо. А ммм... где посмотреть в самой среде? Т.е. оно у меня в исходниках ... Вроде бы не должно быть секретом для меня заголовки моего же приложения ...

p.s. Диспетчер его точно не считае 32 битным