Используемая память не освобождается после вставки SQL BULK / экспорта BCP

Я создал очень простую таблицу SQL следующим образом

CREATE TABLE [dbo].[TickData](
[Date] [varchar](12) NULL,
[Time] [varchar](12) NOT NULL,
[Symbol] [varchar](12) NOT NULL,
[Side] [varchar](2) NOT NULL,
[Depth] [varchar](2) NOT NULL,
[Quote] [varchar](12) NOT NULL,
[Size] [varchar](18) NOT NULL
    ) ON [PRIMARY]

Затем я выполнил массовую вставку на 3 гигабайта

    BULK
    INSERT TickData
    FROM 
    'C:\SUMO.csv'
    GO

Затем использование оперативной памяти для SQL-сервера стало стремительным, потребляя около 30 ГБ оперативной памяти:

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

РЕДАКТИРОВАТЬ:
Хорошо, это похоже на поведение по умолчанию. Справедливо.
Тем не менее, почему память не освобождается долго после завершения массовой вставки?

Пара дополнительных соображений:
Что касается комментариев, касающихся SQL-сервера, освобождающего память, когда об этом «сообщает» ОС, то мой практический опыт работы с 24-ядерным 32-гигабайтным сервером Xeon доказывает, что это будет неточно: после завершения извлечения памяти-прожорливого BCP У меня есть пул .Net Экземпляров моего приложения для обработки данных, которые должны обрабатывать извлеченные данные, и они оставляют удушающие / боевые действия, чтобы разделить оставшуюся память, чтобы попытаться выполнить свою работу, что занимает больше времени, чем при включении SQL Server выкл и память доступна для всех приложений, чтобы поделиться. Я должен остановить агент SQL Server, чтобы все прошло гладко и предотвратить сбои приложений для Articiallt, вызвавшего исключение OutOfMemmroy. Что касается искусственного ограничения / ограничения жестокой памяти, если доступна свободная память, почему бы не использовать его? В идеале это было бы динамически настроено на адаптацию к тому, что доступно, а не просто насильственное ограничение «случайным образом». Но я предполагаю, что это не совсем так, поэтому дело закрыто по этому последнему пункту.

SQL Server обычно выделяет столько памяти, сколько может, в свой буферный пул. Базы данных лучше всего работают с большим количеством буфера. Если вы хотите изменить поведение, вы можете установить параметр «max server memory» . Хорошая справочная информация об этом здесь.

Если вы действительно хотите, чтобы ОС забрала память у SQL Server, возьмите большой файл размером 20 ГБ и скопируйте его по сети. SQL Server освободит память по мере необходимости ОС. Но я бы посмотрел различные счетчики производительности, пока это происходит, и посмотрел бы, как изменится производительность вашего BULK INSERT, если вы запустите его снова либо во время копирования, либо сразу после него.

Если вы хотите сделать это вручную, то вам следует установить нижний предел на максимальный объем памяти сервера SQL Server и перезапустить службу. Теперь SQL Server не будет использовать 28 ГБ, даже если ему это нужно. Но это, кажется, искусственно ограничивает SQL Server.

Вы, кажется, ожидаете более гибкого поведения, когда у вас может быть свободная часть времени. Для чего? Это похоже на сжатие файла базы данных, чтобы освободить место на диске, которое вы не можете использовать для других целей, потому что файл базы данных снова будет расти?

Забавно, если вы набираете в поиске Google слово «почему нет SQL Server», то наиболее распространенным автозаполнением является «освобождение памяти».

Это, к сожалению, дизайн, пожалуйста, ссылку на этот пост. Тем не менее, в этом посте он дает вам некоторые инструкции о том, как его контролировать.

/server/251832/sql-server-bulk-insert-physical-memory-issue

Распределение памяти Править

Память не freedработает, потому что она выделяет память во многом как приложение .NET. Поскольку выделение памяти является дорогостоящим, оно будет сохраняться до тех пор, пока ОС не запросит его. Но не бойтесь, если ОС хочет память, она ее получит, как в приложении .NET.