Есть СКЛ Сервер 2000 (или МСДЕ 2000 результат один и тот же).
Параметры:
Microsoft SQL Server 2000 — 8.00.384 (Intel X86) May 23 2001 00:02:52 Copyright (c) 1988-2000 Microsoft Corporation Desktop Engine on Windows NT 5.0 (Build 2195: Service Pack 3)
Он стоит на ХР винде, там же я с ним и работаю.
Есть программа, которая через ОДБС гоняет селекты к нему.
Программа является очень критичной к потребляемым ресурсам, так как должна работать без перезагрузки долгие месяцы. Однако, обнаружилось, что на вторые сутки работы сам СКЛ Сервер съедает 500 М памяти и вся система просто вешается..
Причем ест он память очень быстро..
В результате долгой отладки на причину таких утечек был найден селект (селекты), который при своейм выполнении съедает каждый раз по 40 К памяти и назад её не отдает.
Затем эта ситуация была проверена на QA — результат тот же — память растет.
Я так понимаю работу СКЛ Сервера. Он выполняет запрос — выбирает данные. И одновременно кэширует какую-то часть информации по какому-то своему алгоритму. Чтобы если следующая выборка попадет в эти данные, то он не будет обращаться к диску, а сразу возьмет все из памяти. Это все ок — из-за этого память может немного скушаться. НО размер этого кэша ведь должен быть фиксированным. Т.е. не может же быть так, что программа выполняет 10 000 селектов и каждый из них кэшируется... Ну вот я тоже думаю, что не может такого быть.
Далее был проведен эксперимент. В самих настройках СКЛ Сервера было указано, чтобы он не ел всю доступную память, а ограничился скажем 25 метрами. Результат был таким. Он дорос до указанного предела. поработал некоторое время, а затем стал выдавать на каждый запрос к нему, будь то селект или попытка установить соединение, что вся свободная память кончилась и мол — отвали.
Итак. Возможно я сумбурно описал ситуацию — просто указал, все что делалось.
Резюме такое. Есть некий селект, который при своем выполнении каждый раз отхватывает от СКЛ Сервера по 40 К. Этих селектов за сутки проходит туча. В результате я теряю всю свободную память. Самое интересное то, что даже если все таблицы, по которым работает этот селект полностью пустые — результат будет тем же.
CREATE TABLE OUT_REPLICA_LOG (
IID NUMERIC(38) NOT NULL IDENTITY (1,1),
REPLICA_GUID uniqueidentifier NOT NULL ,
DB_ID NUMERIC(38) NOT NULL ,
STATUS_ID NUMERIC(38) NOT NULL ,
DESCRIPTION_ VARCHAR(4000) NOT NULL ,
DATE_ DATETIME NOT NULL DEFAULT GETDATE ( ) ,
PRIMARY KEY (IID, REPLICA_GUID),
FOREIGN KEY (REPLICA_GUID) REFERENCES OUT_REPLICA_PROPERTY);
CREATE TABLE OUT_REPLICA_DB_MAP (
REPLICA_GUID uniqueidentifier NOT NULL ,
DB_ID int NOT NULL ,
CHANNEL_ID int NOT NULL ,
RECV_STATUS bit NULL ,
FILL_STATUS bit NULL,
FOREIGN KEY (REPLICA_GUID) REFERENCES OUT_REPLICA_PROPERTY );
Большая просьба создайте их через QA, а затем сразу выполните след. селект
SELECT DISTINCT
MAP.DB_ID
FROM
OUT_REPLICA_PROPERTY AS PROPERTY,
OUT_REPLICA_DB_MAP AS MAP,
OUT_REPLICA_LOG AS LOG
WHERE
PROPERTY.REPLICA_GUID = MAP.REPLICA_GUID
AND
LOG.REPLICA_GUID = MAP.REPLICA_GUID
AND
PROPERTY.REPLICA_TYPE = 0
AND
(MAP.FILL_STATUS IS NULL OR MAP.FILL_STATUS = 0)
AND
MAP.DB_ID in (2)
AND
LOG.IID < ( SELECT MIN (IID) FROM OUT_REPLICA_LOG WHERE REPLICA_GUID = '3FD1F219-7B00-4E79-86A1-8B6F783C610B')
И при этом обратите внимание на расход памяти в диспетчере задач. И ещё такой момент. В селекте указан ГУИД '3FD1F219-7B00-4E79-86A1-8B6F783C610B'. От запроса к запросу его нужно менять (например первую цифру), т.е. чтобы выборка не повторялась. Тогда память начнет течь.
Буду очень признателен, если общественность внимательно прочтет это сообщение, "въедет" в его смысл и посоветует мне хоть что-нибудь.. — проект горит, его инсталлировать нужно, а он фактически не может работать, т.к. СКЛ ест всю доступную память.
JS>Программа является очень критичной к потребляемым ресурсам, так как должна работать без перезагрузки долгие месяцы. Однако, обнаружилось, что на вторые сутки работы сам СКЛ Сервер съедает 500 М памяти и вся система просто вешается..
Система точно вешается?
JS>Причем ест он память очень быстро..
Это нормально...
Более того, ограничивать память сиквела насильно не рекомендуется.
Сиквел ведет довольно агрессивную политику по работе с памятью, чтобы избежать лишнего pagin'га по вине системы, он съедает под кешь все что ему дают, какие бы маленькие селекты не были, если есть возможность, то он практически всю базу в память и запихивает.
Однако по первому требованию системы память освобождается..
Здравствуйте, John Scherbatov, Вы писали:
JS>Господа. JS>Ситуация такая.
JS>Есть программа, которая через ОДБС гоняет селекты к нему.
JS>Программа является очень критичной к потребляемым ресурсам, так как должна работать без перезагрузки долгие месяцы. Однако, обнаружилось, что на вторые сутки работы сам СКЛ Сервер съедает 500 М памяти и вся система просто вешается.. JS>Причем ест он память очень быстро.. JS>В результате долгой отладки на причину таких утечек был найден селект (селекты), который при своейм выполнении съедает каждый раз по 40 К памяти и назад её не отдает. JS>Затем эта ситуация была проверена на QA — результат тот же — память растет.
Сервер старается съесть всю доступную ему память, но при этом при первом требовании операционки должен вернуть ее обратно, так что скорее всего что-то мешает ему это сделать. Нет ли случайно каких-нибудь "висящих" коннектов? Не растет ли все время количество блокировок на сервере?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, John Scherbatov, Вы писали:
JS>>Программа является очень критичной к потребляемым ресурсам, так как должна работать без перезагрузки долгие месяцы. Однако, обнаружилось, что на вторые сутки работы сам СКЛ Сервер съедает 500 М памяти и вся система просто вешается.. M>Система точно вешается?
Смотря что иметь ввиду под этой фразой — в моем случае наблюдается эффект, когда многие приложения в ОС виснут (либо в самой ОС отваливаются многие ф-ии — например клава не работает — только мышь и т.д.), а дебагер в каком либо приложении на запрос p = new Class возвращает NULL; Ну и т.п. эффекты
JS>>Причем ест он память очень быстро.. M>Это нормально... M>Более того, ограничивать память сиквела насильно не рекомендуется. M>Сиквел ведет довольно агрессивную политику по работе с памятью, чтобы избежать лишнего pagin'га по вине системы, он съедает под кешь все что ему дают, какие бы маленькие селекты не были, если есть возможность, то он практически всю базу в память и запихивает. M>Однако по первому требованию системы память освобождается..
Хорошо.. он может съедать память под кэш. Но как объяснить тогда описываемую мной ситуацию, что я ставлю ему ограничение в 50 М. Один запрос (на пустые таблицы!!!!!) съедает 40К и как только СКЛ доходит до заветных 50 М — он выдает сообщение, что все память кончилась ...?? И ещё.. эта ситуация наблюдается только с приведенным мной запросом — во всех остальных случаях все работает "по честному".
Здравствуйте, DrDred, Вы писали:
DD>Здравствуйте, John Scherbatov, Вы писали:
JS>>Господа. JS>>Ситуация такая.
JS>>Есть программа, которая через ОДБС гоняет селекты к нему.
JS>>Программа является очень критичной к потребляемым ресурсам, так как должна работать без перезагрузки долгие месяцы. Однако, обнаружилось, что на вторые сутки работы сам СКЛ Сервер съедает 500 М памяти и вся система просто вешается.. JS>>Причем ест он память очень быстро.. JS>>В результате долгой отладки на причину таких утечек был найден селект (селекты), который при своейм выполнении съедает каждый раз по 40 К памяти и назад её не отдает. JS>>Затем эта ситуация была проверена на QA — результат тот же — память растет.
DD>Сервер старается съесть всю доступную ему память, но при этом при первом требовании операционки должен вернуть ее обратно, так что скорее всего что-то мешает ему это сделать. Нет ли случайно каких-нибудь "висящих" коннектов? Не растет ли все время количество блокировок на сервере?
Насчет коннектов.. Система работает так. У приложения всегда есть одновременно открытых 5 соединений. 3 из них постоянные (кэшируются для определенных целей), а 2 динамически создаются/утичтожаются довольно часто.
Насчет блокировок не знаю — а как это посмотреть..?
Понимаете.. я вот на что хотел бы обратить Ваше внимание. Не важно сколько соединений/блокировок у меня используется и т.п. Я в QA просто выполняю этот запрос 100 раз над пустыми(!) таблицами и добиваюсь того же эффекта. Чего он там кэширует-то?
И ещё. После закрытия приложения (корректного), всех соединений и т.п. — память у СКЛ никуда не уходит, даже спустя время.
JS>Насчет коннектов.. Система работает так. У приложения всегда есть одновременно открытых 5 соединений. 3 из них постоянные (кэшируются для определенных целей), а 2 динамически создаются/утичтожаются довольно часто. JS>Насчет блокировок не знаю — а как это посмотреть..?
sp_lock
JS>Понимаете.. я вот на что хотел бы обратить Ваше внимание. Не важно сколько соединений/блокировок у меня используется и т.п. Я в QA просто выполняю этот запрос 100 раз над пустыми(!) таблицами и добиваюсь того же эффекта. Чего он там кэширует-то?
Если верить BOL
Virtual Memory and the Database Engine
Virtual memory is a method of extending the available physical memory on a computer. In a virtual memory system, the operating system creates a pagefile, or swapfile, and divides memory into units called pages. Recently referenced pages are located in physical memory, or RAM. If a page of memory is not referenced for a while, it is written to the pagefile. This is called swapping or paging out memory. If that piece of memory is later referenced by an application, the operating system reads the memory page back from the pagefile into physical memory, also called swapping or paging in memory. The total amount of memory available to applications is the amount of physical memory in the computer plus the size of the pagefile. If a computer has 256 MB of RAM and a 256 MB pagefile, the total memory available to applications is 512 MB. Operating systems such as Microsoft Windows NT®, Windows 2000, Windows 98, and Windows Me support virtual memory.
One of the primary design goals of all database software is to minimize disk I/O because disk reads and writes are among the most resource-intensive operations. SQL Server builds a buffer cache in memory to hold pages read from the database. Much of the code in SQL Server is dedicated to minimizing the number of physical reads and writes between the disk and the buffer cache. The larger the buffer cache is, the less I/O SQL Server has to do to the database files. However, if the buffer cache causes SQL Server memory requirements to exceed the available physical memory on the server, the operating system starts swapping memory to and from the pagefile. All that has happened is that the physical I/O to the database files has been traded for physical I/O to the swap file.
Having a lot of physical I/O to the database files is an inherent factor of database software. By default, SQL Server tries to reach a balance between two goals:
Minimizing or eliminating pagefile I/O to concentrate I/O resources for reads and writes of the database files.
Minimizing physical I/O to the database files by maximizing the size of the buffer cache.
By default, the SQL Server 2000 editions dynamically manage the size of the address space for each instance. There are differences in the way Windows NT, Windows 2000, Windows 98, and Windows Me report virtual memory usage to applications. Because of this, SQL Server 2000 uses different algorithms to manage memory on these operating systems.
Если я правильно понимаю, он все равно хранит страницы, проичтанные им (даже если запрос вернулся пустой) в оперативной памяти...
Правда это не снимает Вашего главного вопроса — почему при необходимости он не сбрасывает эти уже не нужные ему страницы в файл подкачки?
Сейчас попытаюсь смоделировать подобную ситуацию у себя, и отпишу результаты...
JS>Хорошо.. он может съедать память под кэш. Но как объяснить тогда описываемую мной ситуацию, что я ставлю ему ограничение в 50 М. Один запрос (на пустые таблицы!!!!!) съедает 40К и как только СКЛ доходит до заветных 50 М — он выдает сообщение, что все память кончилась ...?? И ещё.. эта ситуация наблюдается только с приведенным мной запросом — во всех остальных случаях все работает "по честному".
Для данного запроса будет построено несколько (как минимум 2) worktable...
Интересно, если убрать distinct И min , будет ли по-прежнему память утекать?
Здравствуйте, John Scherbatov, Вы писали:
JS>Насчет блокировок не знаю — а как это посмотреть..?
sp_lock.
Насчет незакоммиченых транзакций @@trancount и в EM есть соответствующие счетчики..
JS>Понимаете.. я вот на что хотел бы обратить Ваше внимание. Не важно сколько соединений/блокировок у меня используется и т.п. Я в QA просто выполняю этот запрос 100 раз над пустыми(!) таблицами и добиваюсь того же эффекта. Чего он там кэширует-то?
Просто вся база потихоньку в память кладется, а не только что-то имеющее отношение к этим запросам...
JS>И ещё. После закрытия приложения (корректного), всех соединений и т.п. — память у СКЛ никуда не уходит, даже спустя время.
И не должна, там база лежит... Вот если система попросит, то он эту память должен отдать...
Здравствуйте, DrDred, Вы писали:
DD>Правда это не снимает Вашего главного вопроса — почему при необходимости он не сбрасывает эти уже не нужные ему страницы в файл подкачки?
По идее и не должен сбрасывать, пока система не попросит... Или под "необходимостью" это и имелось ввиду?
Здравствуйте, John Scherbatov, Вы писали:
JS>Хорошо.. он может съедать память под кэш. Но как объяснить тогда описываемую мной ситуацию, что я ставлю ему ограничение в 50 М. Один запрос (на пустые таблицы!!!!!) съедает 40К и как только СКЛ доходит до заветных 50 М — он выдает сообщение, что все память кончилась ...?? И ещё.. эта ситуация наблюдается только с приведенным мной запросом — во всех остальных случаях все работает "по честному".
Надо посмотреть на блокировки и на наличие незафиксированных транзакций.
Здравствуйте, DrDred, Вы писали:
DD>Здравствуйте, John Scherbatov, Вы писали:
JS>>Насчет коннектов.. Система работает так. У приложения всегда есть одновременно открытых 5 соединений. 3 из них постоянные (кэшируются для определенных целей), а 2 динамически создаются/утичтожаются довольно часто. JS>>Насчет блокировок не знаю — а как это посмотреть..? DD>sp_lock
JS>>Понимаете.. я вот на что хотел бы обратить Ваше внимание. Не важно сколько соединений/блокировок у меня используется и т.п. Я в QA просто выполняю этот запрос 100 раз над пустыми(!) таблицами и добиваюсь того же эффекта. Чего он там кэширует-то? DD>Если верить BOL
DD>Virtual Memory and the Database Engine DD>Virtual memory is a method of extending the available physical memory on a computer. In a virtual memory system, the operating system creates a pagefile, or swapfile, and divides memory into units called pages. Recently referenced pages are located in physical memory, or RAM. If a page of memory is not referenced for a while, it is written to the pagefile. This is called swapping or paging out memory. If that piece of memory is later referenced by an application, the operating system reads the memory page back from the pagefile into physical memory, also called swapping or paging in memory. The total amount of memory available to applications is the amount of physical memory in the computer plus the size of the pagefile. If a computer has 256 MB of RAM and a 256 MB pagefile, the total memory available to applications is 512 MB. Operating systems such as Microsoft Windows NT®, Windows 2000, Windows 98, and Windows Me support virtual memory.
DD>One of the primary design goals of all database software is to minimize disk I/O because disk reads and writes are among the most resource-intensive operations. SQL Server builds a buffer cache in memory to hold pages read from the database. Much of the code in SQL Server is dedicated to minimizing the number of physical reads and writes between the disk and the buffer cache. The larger the buffer cache is, the less I/O SQL Server has to do to the database files. However, if the buffer cache causes SQL Server memory requirements to exceed the available physical memory on the server, the operating system starts swapping memory to and from the pagefile. All that has happened is that the physical I/O to the database files has been traded for physical I/O to the swap file.
DD>Having a lot of physical I/O to the database files is an inherent factor of database software. By default, SQL Server tries to reach a balance between two goals:
DD>Minimizing or eliminating pagefile I/O to concentrate I/O resources for reads and writes of the database files.
DD>Minimizing physical I/O to the database files by maximizing the size of the buffer cache. DD>By default, the SQL Server 2000 editions dynamically manage the size of the address space for each instance. There are differences in the way Windows NT, Windows 2000, Windows 98, and Windows Me report virtual memory usage to applications. Because of this, SQL Server 2000 uses different algorithms to manage memory on these operating systems.
DD>Если я правильно понимаю, он все равно хранит страницы, проичтанные им (даже если запрос вернулся пустой) в оперативной памяти... DD>Правда это не снимает Вашего главного вопроса — почему при необходимости он не сбрасывает эти уже не нужные ему страницы в файл подкачки? DD>Сейчас попытаюсь смоделировать подобную ситуацию у себя, и отпишу результаты...
Буду признателен, если Вы попытаетесь смоделировать эту ситуацию у себя и оцените свежим взглядом.
Насчет файла подкачки.. забыл сказать.. Помимо самой оперативки файл подкачки тоже растет на N-ю сумму килобайтов постоянно и достигает в конце совсем обалденных размеров.
И ещё.. предположим СКЛ достиг моего ограничения в N Мб.. Почему он не пытается освободить свой кэш, который не используется, а говорит мне , что ему не достаточно памяти? Вот именно здесь у меня главная заковыка и подозрения просто на утечки.. Если бы все было по честному он бы съедал память, а когда лимит бы кончился начинал бы колбаситься с тем что уже нахватал.. А так получается икакой памяти не напасешся..
Здравствуйте, DrDred, Вы писали:
DD>Здравствуйте, John Scherbatov, Вы писали:
JS>>Хорошо.. он может съедать память под кэш. Но как объяснить тогда описываемую мной ситуацию, что я ставлю ему ограничение в 50 М. Один запрос (на пустые таблицы!!!!!) съедает 40К и как только СКЛ доходит до заветных 50 М — он выдает сообщение, что все память кончилась ...?? И ещё.. эта ситуация наблюдается только с приведенным мной запросом — во всех остальных случаях все работает "по честному".
DD>Для данного запроса будет построено несколько (как минимум 2) worktable... DD>Интересно, если убрать distinct И min , будет ли по-прежнему память утекать?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, DrDred, Вы писали:
DD>>Правда это не снимает Вашего главного вопроса — почему при необходимости он не сбрасывает эти уже не нужные ему страницы в файл подкачки? M>По идее и не должен сбрасывать, пока система не попросит... Или под "необходимостью" это и имелось ввиду?
Да... Меня смущает, что этого не происходит, и система похоже умирает в свопе...
Как вариант, можно попробовать понизить приоритет sqlserver'у...
И еще (но это уже из области фантастики, почти что пляски с бубном) — OUT_REPLICA_PROPERTY имеет длину строки более 8060 байт, возможно здесь происходят какие-то неизвестные науке утечки...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, John Scherbatov, Вы писали:
JS>>Хорошо.. он может съедать память под кэш. Но как объяснить тогда описываемую мной ситуацию, что я ставлю ему ограничение в 50 М. Один запрос (на пустые таблицы!!!!!) съедает 40К и как только СКЛ доходит до заветных 50 М — он выдает сообщение, что все память кончилась ...?? И ещё.. эта ситуация наблюдается только с приведенным мной запросом — во всех остальных случаях все работает "по честному". M>Надо посмотреть на блокировки и на наличие незафиксированных транзакций.
Здравствуйте, John Scherbatov, Вы писали:
JS>И ещё.. предположим СКЛ достиг моего ограничения в N Мб.. Почему он не пытается освободить свой кэш, который не используется, а говорит мне , что ему не достаточно памяти? Вот именно здесь у меня главная заковыка и подозрения просто на утечки..Если бы все было по честному он бы съедал память, а когда лимит бы кончился начинал бы колбаситься с тем что уже нахватал.. А так получается икакой памяти не напасешся..
Честно говоря не думаю, что Вам повзло нарваться на какие-нибудь утечки в ядре сервера. Скорее всего причину надо искать в не закрытых коннекшенах, незафиксированных транзакциях и т. д.
Кстати, а sp последний стоит?
У меня сейчас к сожалению нет возможности смоделировать ситуацию, будем ждать ответа от DrDred'а
Здравствуйте, John Scherbatov, Вы писали:
JS>Здравствуйте, DrDred, Вы писали:
DD>>Здравствуйте, John Scherbatov, Вы писали: DD>>Сейчас попытаюсь смоделировать подобную ситуацию у себя, и отпишу результаты...
JS>Буду признателен, если Вы попытаетесь смоделировать эту ситуацию у себя и оцените свежим взглядом.
Странно. Набросал на форму ADOConnection & ADOQuery с Вашим запросом,
сделал
var
i: Integer;
s: string;
begin
for i := 1 to 10000000 do
begin
ADOQuery1.Close;
s := CreateClassID;
ShowMessage(s);
ADOQuery1.Parameters.ParamValues['GUID'] := s;
ADOQuery1.Open;
ADOQuery1.First;
end;
end;
Память не растет. Вообще никак не растет
правда я использовал родной OLEDB провайдер для SQL Server'a
Так что скорее всего дело действительно в неосвобождаемых ресурсах...
можно попытаться еще посмотреть несколько раз в процессе работы, растет ли количество процессов через sp_who
Здравствуйте, DrDred, Вы писали:
DD>Здравствуйте, Merle, Вы писали:
M>>Здравствуйте, DrDred, Вы писали:
DD>>>Правда это не снимает Вашего главного вопроса — почему при необходимости он не сбрасывает эти уже не нужные ему страницы в файл подкачки? M>>По идее и не должен сбрасывать, пока система не попросит... Или под "необходимостью" это и имелось ввиду? DD>Да... Меня смущает, что этого не происходит, и система похоже умирает в свопе... DD>Как вариант, можно попробовать понизить приоритет sqlserver'у... DD>И еще (но это уже из области фантастики, почти что пляски с бубном) — OUT_REPLICA_PROPERTY имеет длину строки более 8060 байт, возможно здесь происходят какие-то неизвестные науке утечки...
Здравствуйте, DrDred, Вы писали:
DD>Здравствуйте, John Scherbatov, Вы писали:
JS>>Здравствуйте, DrDred, Вы писали:
DD>>>Здравствуйте, John Scherbatov, Вы писали: DD>>>Сейчас попытаюсь смоделировать подобную ситуацию у себя, и отпишу результаты...
JS>>Буду признателен, если Вы попытаетесь смоделировать эту ситуацию у себя и оцените свежим взглядом.
DD>Странно. Набросал на форму ADOConnection & ADOQuery с Вашим запросом, DD>сделал
DD>
DD>var
DD> i: Integer;
DD> s: string;
DD>begin
DD> for i := 1 to 10000000 do
DD> begin
DD> ADOQuery1.Close;
DD> s := CreateClassID;
DD> ShowMessage(s);
DD> ADOQuery1.Parameters.ParamValues['GUID'] := s;
DD> ADOQuery1.Open;
DD> ADOQuery1.First;
DD> end;
DD>end;
DD>
DD>Память не растет. Вообще никак не растет
DD>правда я использовал родной OLEDB провайдер для SQL Server'a DD>Так что скорее всего дело действительно в неосвобождаемых ресурсах...
DD>можно попытаться еще посмотреть несколько раз в процессе работы, растет ли количество процессов через sp_who
Интересные результаты...
Скажите , а в QA у вас есть утечка?
Re: SQL Server дает сильные утечки памяти.
От:
Аноним
Дата:
25.09.03 13:05
Оценка:
У меня эксперимент воспроизводится
Но если заменить
Здравствуйте, John Scherbatov, Вы писали:
JS>Интересные результаты... JS>Скажите , а в QA у вас есть утечка?
Иногда есть, иногда раза три-четыре выполнял этот запрос, и никакого увеличения не происходило.
А вообще объем занимаемой памяти растет по чуть-чуть, при любых запросах... Но еще не было такого, чтобы сервер свалился от того, что ему не хватило RAM и он ушел в своп...
Скажите, а нет возможности отрубать постоянные коннекты на некоторое время? возможно они держат на себе большое количество ресурсов?
declare @i integer
set @i=0
while (@i<10000)
begin
SELECT DISTINCT
MAP.DB_ID
FROM
OUT_REPLICA_PROPERTY AS PROPERTY,
OUT_REPLICA_DB_MAP AS MAP,
OUT_REPLICA_LOG AS LOG
WHERE
PROPERTY.REPLICA_GUID = MAP.REPLICA_GUID
AND
LOG.REPLICA_GUID = MAP.REPLICA_GUID
AND
PROPERTY.REPLICA_TYPE = 0
AND
(MAP.FILL_STATUS IS NULL OR MAP.FILL_STATUS = 0)
AND
MAP.DB_ID in (2)
AND
LOG.IID < ( SELECT MIN (IID) FROM OUT_REPLICA_LOG WHERE REPLICA_GUID = '3FD1F219-7B00-4E79-86A1-8B6F783C610B')
set @i=@i+1
end
Как видите, данный селект исполняется 10000 раз.
При этом утечек памяти вообще нет. Занимаемая память колеблется вокруг 16700K (обе колонки Mem Usage и VM Size).
Product: SQL Server Developer Edition
OS: MS Win NT 5.1 (2600)
Product Version: 8.00.194(RTM)
OS Memory: 512 MB
Processor: 1
Конфигурация памяти — динмаическая, от 0 до 511
Max Worker Threads = 255
Boost Priority — off
NT Fibers — off
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, John Scherbatov, Вы писали:
JS>>Хорошо.. он может съедать память под кэш. Но как объяснить тогда описываемую мной ситуацию, что я ставлю ему ограничение в 50 М. Один запрос (на пустые таблицы!!!!!) съедает 40К и как только СКЛ доходит до заветных 50 М — он выдает сообщение, что все память кончилась ...?? И ещё.. эта ситуация наблюдается только с приведенным мной запросом — во всех остальных случаях все работает "по честному". M>Надо посмотреть на блокировки и на наличие незафиксированных транзакций.
А через Performance не пробовал глянуть? Ну там число соединений, сессий и так далее, мне в таких слуях эти счетчики сильно помогали для отслеживания утечек.
JS>Есть СКЛ Сервер 2000 (или МСДЕ 2000 результат один и тот же). JS>Параметры: JS>Microsoft SQL Server 2000 — 8.00.384 (Intel X86) May 23 2001 00:02:52 Copyright (c) 1988-2000 Microsoft Corporation Desktop Engine on Windows NT 5.0 (Build 2195: Service Pack 3)
Смущает что установлен всего лишь Service Pack 1. Например, в багах до 2 СП значится утечка памяти при быстром коннекте/диссконнекте. Зачему также что у товарища вообще без СП (8.00.194) вроде как работает. Рекомендую поставить 3 СП и проверить.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, John Scherbatov, Вы писали:
S>Я слегка поменял текст второго скрипта: S>
S>declare @i integer
S>set @i=0
S>while (@i<10000)
S>begin
S> LOG.IID < ( SELECT MIN (IID) FROM OUT_REPLICA_LOG WHERE REPLICA_GUID = '3FD1F219-7B00-4E79-86A1-8B6F783C610B')
S> set @i=@i+1
S>end
S>
S>Как видите, данный селект исполняется 10000 раз. S>При этом утечек памяти вообще нет. Занимаемая память колеблется вокруг 16700K (обе колонки Mem Usage и VM Size). 2 Sinclair
И ещё такой момент. В селекте указан ГУИД '3FD1F219-7B00-4E79-86A1-8B6F783C610B'. От запроса к запросу его нужно менять (например первую цифру), т.е. чтобы выборка не повторялась. Тогда память начнет течь
Мы уже победили, просто это еще не так заметно...
