ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / MS SQL cъедает больше памяти, чем ему положено.
25 сообщений из 34, страница 1 из 2
  1  все
MS SQL cъедает больше памяти, чем ему положено.
    #39568524
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Всем добрый день.

Перебрались недавно на новые сервера.
На двух из них уже несколько раз выскакивала ошибка: There is insufficient system memory in resource pool 'internal' to run this query.
И сервер отъедает памяти больше, чем установлено в настройках.
Про саму ошибку я почитал:
1) Не выставлено ограничение max server memory
2) Баг версии сервера, исправляется нужным обновлением.

Суть в том, что:
а) ограничение max server memory стоит: на главном 20 из 24гб, на двух других 4 и 4.5 из 6гб. На серверах, кроме MS SQL ничего не крутится. После настроек сервера были перегружены.
б) сервера обновлены до sp3. Сисадмин утверждает, что нужный апдейт входит в установленные сервис паки.

Единственное отличие от старых серверов, где подобных проблем не было, что те были sp2.

Версия сервера: Microsoft SQL Server 2008 R2 (SP3) - 10.50.6000.34 (X64) Aug 19 2014 12:21:34 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Два второстепенных сервера уже пришлось экстренно перегружать из-за того, что MS SQL съел больше памяти, чем ему положено. Но это было не критично.
А вот остановка основного сервера критична днем даже на 5минут. Там просто памяти больше 20, но он уже сожрал 21 с копейками.

Я уже и не знаю, куда копать. Это таки бага верчсии\сервис пака, или мы что-то недонастроили в дб сервере?
---
Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с)
...
Рейтинг: 0 / 0
12.12.2017, 17:29
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39568538
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гавриленко Сергей Алексеевич
Участник
https://technet.microsoft.com/en-us/library/ms180797(v=sql.105).aspx?f=255&MSPPError=-2147217396 SQL Server as a process acquires more memory than specified by max server memory option. Both internal and external components can allocate memory outside of the buffer pool
...
Рейтинг: 0 / 0
12.12.2017, 17:46
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39568550
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Megabyte,

здесь некоторые рекомендации
https://msdn.microsoft.com/ru-ru/library/ms178067(v=sql.120)

съедать могут CLR сборки, XML документы, OLE Automation и т.п.
...
Рейтинг: 0 / 0
12.12.2017, 18:03
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39568608
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
MegabyteНа двух из них уже несколько раз выскакивала ошибка: There is insufficient system memory in resource pool 'internal' to run this query.
И сервер отъедает памяти больше, чем установлено в настройках.Это не та память, которую вы указываете в настройках. В настройках задаётся страничный кэш. Так что задавайте с запасом.
Ну и ошибка говорит о баге, а не о нехватке памяти на сервере. Копайтесь, смотрите.
Вот, например, тема: http://www.sql.ru/forum/970396/error-701-there-is-insufficient-system-memory-in-resource-pool-internal-to-run-this-query
Ну и вообще поищите по названию ошибки (если не поможет снижение max memory)
...
Рейтинг: 0 / 0
12.12.2017, 19:13
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39568679
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Всем спасибо. Буду копать.
Clr-сборок нет.
xml, ole - да, используем.

Просто странно, что функционал при переезде не менялся, а проблемы появились.
...
Рейтинг: 0 / 0
12.12.2017, 21:17
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39568681
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
alexeyvgMegabyteНа двух из них уже несколько раз выскакивала ошибка: There is insufficient system memory in resource pool 'internal' to run this query.
И сервер отъедает памяти больше, чем установлено в настройках.Это не та память, которую вы указываете в настройках. В настройках задаётся страничный кэш. Так что задавайте с запасом.
Ну и ошибка говорит о баге, а не о нехватке памяти на сервере. Копайтесь, смотрите.
Вот, например, тема: http://www.sql.ru/forum/970396/error-701-there-is-insufficient-system-memory-in-resource-pool-internal-to-run-this-query
Ну и вообще поищите по названию ошибки (если не поможет снижение max memory)
Да, спасибо. Тему эту конечно же читал, но поверхносно.
...
Рейтинг: 0 / 0
12.12.2017, 21:19
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39569071
Гигабайт Мегабайтович Килобайтов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гигабайт Мегабайтович Килобайтов
Участник
MegabyteВсем спасибо. Буду копать.
Clr-сборок нет.
xml, ole - да, используем.

Просто странно, что функционал при переезде не менялся, а проблемы появились.
а настройки памяти менялись?))
...
Рейтинг: 0 / 0
13.12.2017, 15:25
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39575593
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Гигабайт Мегабайтович КилобайтовMegabyteВсем спасибо. Буду копать.
Clr-сборок нет.
xml, ole - да, используем.

Просто странно, что функционал при переезде не менялся, а проблемы появились.
а настройки памяти менялись?))
Памяти либо добавили, либо не изменилось. :)

Или вы про какие-то другие настройки?

Реанимирую тему:
Из 2х проблемных на одном проблемы ушли, после того, как установил 4гб из 6, вместо 4.5гб.
У 2го так и было 4 из 6.
И у него же появились новые проблемы:
22.12.2017 в логе увидел такую ошибку: " Failed Virtual Allocate Bytes: FAIL_VIRTUAL_RESERVE 65536"
После нее была куча сообщений, связанных с памятью(для меня пока малопонятных):
автор Memory Manager KB ---------------------------------------- ---------- VM Reserved 6446192 VM Committed 4477832 Locked Pages Allocated 0 Reserved Memory 1024 Reserved Memory In Use 0
Memory node Id = 0 KB ---------------------------------------- ---------- VM Reserved 6442544 VM Committed 4474296 Locked Pages Allocated 0 MultiPage Allocator 231040 SinglePage Allocator 1604544
Memory node Id = 64 KB ---------------------------------------- ---------- VM Reserved 2560 VM Committed 2504 Locked Pages Allocated 0 MultiPage Allocator 2416 SinglePage Allocator 1604544
MEMORYCLERK_SQLGENERAL (node 0) KB ---------------------------------------- ---------- VM Reserved 0 VM Committed 0 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 3248 MultiPage Allocator 7176
MEMORYCLERK_SQLBUFFERPOOL (node 0) KB ---------------------------------------- ---------- VM Reserved 6168576 VM Committed 4202880 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 0 MultiPage Allocator 400
MEMORYCLERK_SQLQUERYEXEC (node 0) KB ---------------------------------------- ---------- VM Reserved 0 VM Committed 0 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 12952 MultiPage Allocator 21408
MEMORYCLERK_SQLOPTIMIZER (node 0) KB ---------------------------------------- ---------- VM Reserved 0 VM Committed 0 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 248 MultiPage Allocator 896
MEMORYCLERK_SQLUTILITIES (node 0) KB ---------------------------------------- ---------- VM Reserved 240 VM Committed 240 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 96 MultiPage Allocator 0
MEMORYCLERK_SQLSTORENG (node 0) KB ---------------------------------------- ---------- VM Reserved 11136 VM Committed 11136 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 8192 MultiPage Allocator 4192
MEMORYCLERK_SQLCONNECTIONPOOL (node 0) KB ---------------------------------------- ---------- VM Reserved 0 VM Committed 0 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 3752 MultiPage Allocator 0
MEMORYCLERK_SQLCLR (node 0) KB ---------------------------------------- ---------- VM Reserved 0 VM Committed 0 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 8 MultiPage Allocator 0
MEMORYCLERK_SQLSERVICEBROKER (node 0) KB ---------------------------------------- ---------- VM Reserved 0 VM Committed 0 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 152 MultiPage Allocator 544
MEMORYCLERK_SQLXML (node 0) KB ---------------------------------------- ---------- VM Reserved 0 VM Committed 0 Locked Pages Allocated 0 SM Reserved 0 SM Committed 0 SinglePage Allocator 16 MultiPage Allocator 0
Просто раньше в логе их не наблюдал.

Заметил, что на сервере стал часто появляться тип ожидания: PAGELATCH_XX.
Почитал в статье на хабре про этот тип ожидания:
авторЭто конкуренция за доступ к копиям страниц в памяти. Наиболее известные случаи — это конкуренция PFS, SGAM, и GAM, возникающие в базе tempdb при определенных типах нагрузок (англ.). Для того, чтобы выяснить, за какие страницы идет конкуренция, вам нужно использовать DMV sys.dm_os_waiting_tasks для того, чтобы выяснить, из-за каких страниц возникают блокировки. По проблемам с базой tempdb Роберт Дэвис (его блог, твиттер) написал хорошую статью, показывающую, как их решать (англ.) Другая частая причина, которую я видел — часто обновляемый индекс с конкурирующими вставками в индекс, использующий последовательный ключ (IDENTITY).

Выполнил запрос:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
SELECT a.database_id,
	cast(db_name(a.database_id) AS VARCHAR) AS Database_Name
	 , a.io_stall_read_ms / a.num_of_reads 'Ср.задержка одной операции чтения'
	 , a.io_stall_write_ms / a.num_of_writes 'Ср.задержка одной операции записи'
	 --,CHARINDEX('\', REVERSE(b.physical_name))
	 --,REVERSE(b.physical_name)
	 ,REVERSE(SUBSTRING(REVERSE(b.physical_name), 1, CHARINDEX('\', REVERSE(b.physical_name))-1))
	 --,a.database_id
FROM
	sys.dm_io_virtual_file_stats(NULL, NULL) a
	INNER JOIN sys.master_files b
		ON a.database_id = b.database_id AND a.file_id = b.file_id
where num_of_writes > 0 and num_of_reads > 0
	AND a.database_id NOT IN (10, 11)
ORDER BY a.io_stall DESC


Таки да, с tempDB что-то не так:
Database_Name Ср.задержка одной операции чтения Ср.задержка одной операции записи (Отсутствует имя столбца)
tempdb 92 2752 tempdb.mdf
tempdb 167 85 templog.ldf

2752 - ср. задержка записи.

По ссылке конкуренция PFS, SGAM, и GAM, возникающие в базе tempdb при определенных типах нагрузок (англ.) из статьи на хабре надеялся прочитать про причины возникающих проблем, но увидел только то, что предлагается сделать несколько файлов tempDB. Для чего, я не сильно понял...

Вопросы:
1) По какой причине могла возникнуть ошибка " Failed Virtual Allocate Bytes: FAIL_VIRTUAL_RESERVE 65536"?
2) Как избавляться от ожиданий PAGELATCH_XX?
3) И связан ли п.1 с п.2?
4) Надо ли что-то делать с tempDB? И если да, то что?
5) Разбирение tempDB на несколько файлов, но расположенных на одном диске, какую-то пользу вообще дает?
...
Рейтинг: 0 / 0
25.12.2017, 16:21
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39575609
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
Megabyte2) Как избавляться от ожиданий PAGELATCH_XX?
5) Разбирение tempDB на несколько файлов, но расположенных на одном диске, какую-то пользу вообще дает?

2) добавить больше дисков, SSD, добавить памяти, оптимизировать свой код
5) да
...
Рейтинг: 0 / 0
25.12.2017, 16:52
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39575631
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
КритикMegabyte2) Как избавляться от ожиданий PAGELATCH_XX?
5) Разбирение tempDB на несколько файлов, но расположенных на одном диске, какую-то пользу вообще дает?

2) добавить больше дисков, SSD, добавить памяти, оптимизировать свой код
5) да
2) Код оптимальный, насколько возможно. Да и в принципе этот сервер не такой нагруженный, по сравнению с двумя другими.
Дисков добавить пока нет возможности. Память теоретически можно нарастить. Но хотелось бы самому разобраться, что причина именно в этом.

5) А подробнее можно? В чем будет плюс? Если бы другие файлы были бы на другом диске, я бы понял пользу...
...
Рейтинг: 0 / 0
25.12.2017, 17:29
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39575732
Eleanor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Eleanor
Участник
MegabyteА подробнее можно? В чем будет плюс? Если бы другие файлы были бы на другом диске, я бы понял пользу...
По вашей ссылке:
1) When you see PAGELATCH_XX waits on tempdb, you’ve got contention for in-memory allocation bitmaps.
2) When you see PAGEIOLATCH_XX waits on tempdb, you’ve got contention at the I/O subsystem level.

У вас первый случай, конкуренция за страницы в памяти , а не на диске .
Создавая несколько файлов, вы пытаетесь увеличить количество allocation pages в памяти, за которые идет конкуренция.

Если бы были PAGEIOLATCH_XX, то от размещения файлов tempdb на разных дисках и ускорения дисковой подсистемы была бы польза.
...
Рейтинг: 0 / 0
25.12.2017, 22:25
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39575746
step_ks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
step_ks
Участник
MegabyteВсем добрый день.

Перебрались недавно на новые сервера.
На двух из них уже несколько раз выскакивала ошибка: There is insufficient system memory in resource pool 'internal' to run this query.


1. В "min memory per query" ничего неординарного не выставлено?
2. Попробуйте определить запросы, на которых падает. Возможно, их не так много и у них будет что-то общее.
...
Рейтинг: 0 / 0
25.12.2017, 22:48
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39575840
f000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
f000
Гость
про tempdb - послушайте Диму АртЁмова
https://www.techdays.ru/videos/6565.html
...
Рейтинг: 0 / 0
26.12.2017, 09:02
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39575864
f000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
f000
Гость
про память
https://blogs.msdn.microsoft.com/sqljourney/2015/04/27/an-in-depth-look-at-memory-sql-server-20122014
дается примерный алгоритм расчета, помимо MaxServMem
http://www.datainternals.ru/blog/анализ-производительности-память

ЗЫ. недавно товарищ переехал на новое железо и ОСь. было 32Гб озу и Win2008 R2 + SQL2008 R2, стало 128Гб Win2012 R2 + SQL2008 R2, на новом серве выставил MaxMem = 120Гб, думая, что 8Гб под ОСь будет достаточно, но SQL сожрал дополнительно еще около 4Гб, и все стало как то невесело. пришлось подбирать параметр методом "тыка".
...
Рейтинг: 0 / 0
26.12.2017, 09:43
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39575927
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
EleanorMegabyteА подробнее можно? В чем будет плюс? Если бы другие файлы были бы на другом диске, я бы понял пользу...
По вашей ссылке:
1) When you see PAGELATCH_XX waits on tempdb, you’ve got contention for in-memory allocation bitmaps.
2) When you see PAGEIOLATCH_XX waits on tempdb, you’ve got contention at the I/O subsystem level.

У вас первый случай, конкуренция за страницы в памяти , а не на диске .
Создавая несколько файлов, вы пытаетесь увеличить количество allocation pages в памяти, за которые идет конкуренция.

Если бы были PAGEIOLATCH_XX, то от размещения файлов tempdb на разных дисках и ускорения дисковой подсистемы была бы польза.
Спасибо за разъяснение. С PAGEIOLATCH_XX я уже сталкивался ранее понимаю, в чем суть.
С PAGELATCH_XX вот впервые...

step_ksMegabyteВсем добрый день.

Перебрались недавно на новые сервера.
На двух из них уже несколько раз выскакивала ошибка: There is insufficient system memory in resource pool 'internal' to run this query.


1. В "min memory per query" ничего неординарного не выставлено?
2. Попробуйте определить запросы, на которых падает. Возможно, их не так много и у них будет что-то общее.
1) На всех серверах 1024кб, как по умолчанию. Честно говоря, не в курсе, на что и как влияет этот параметр.
2) Запросов не так много: xml-заливка(через OPENXML) данных для мониторинга работы нашей системы, ну и много селектов из web-приложения к этим данным.
Заметил, что периодически блокировка идет именно на селективных запросах: блокируют друг друга. Сами запросы работают быстро.
Опять же заметил, что подобные проблемы появились при переезде на новый сервер, тогда как функционал не менялся.

2f000: спасибо, ознакомлюсь.
...
Рейтинг: 0 / 0
26.12.2017, 11:11
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39576432
смотрю_тут
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
смотрю_тут
Участник
в 2008 R2 еще есть понятие multipage, эта память BLOB и другая которая вне буфферного пула сиквела, есть представление по которому надо смотреть sys.dm_os_memory_clerks , сколько идет памяти на это,
в версия после 2008r2 этого уже нет, эта память внутри буферного пула.
+ к этому как говорили все xml, clr так же вне буферного пула.
запрос про multi страницы ниже:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
select  
    sum(awe_allocated_kb) / 1024 as [AWE allocated, Mb]  
from  
    sys.dm_os_memory_clerks
SELECT TYPE, SUM(single_pages_kb) InternalPressure, SUM(multi_pages_kb) ExtermalPressure
FROM sys.dm_os_memory_clerks
GROUP BY TYPE
 ORDER BY SUM(single_pages_kb) DESC, SUM(multi_pages_kb) DESC
GO
--below
--If a significant amount of memory is allocated through the multi-page allocator (100-200 MB or more), further investigation is warranted.
select  
    type, sum(multi_pages_kb/1024)  
from  
    sys.dm_os_memory_clerks  
where  
    multi_pages_kb != 0  
group by type



инфа
https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-memory-clerks-transact-sql

https://blogs.msdn.microsoft.com/karthick_pk/2012/06/15/troubleshooting-sql-server-memory/
...
Рейтинг: 0 / 0
26.12.2017, 22:58
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39576566
f000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
f000
Гость
тут тоже не менее интересно:
http://www.sqlservercentral.com/articles/Memory/74867/

любопытно:
system_cache_kb из sys.dm_os_sys_memory включает ли в себя multi_pages_kb из sys.dm_os_memory_clerks и размер закешировнных планов или для подсчета памяти за пределами buffer pool использовать их сумму или иерархия какая то другая?
...
Рейтинг: 0 / 0
27.12.2017, 10:04
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39585764
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Реанимирую тему.

Просмотрел лекцию.
f000про tempdb - послушайте Диму АртЁмова
https://www.techdays.ru/videos/6565.html
Изучил типы страниц IAM, GAM, SGAM, PFS.

Увидел, что на проблемном сервере тип ожидания PAGELATCH_% занимает 25% от всех ожиданий.

Решил добавить 1 файл tempDB. В рекомендациях Мелкософта советуют 1 файл на каждый процессор(на сервере 4 процессора), но решил посмотреть, как повлияет добавление файла.

При добавлении файла кол-во блокировок только возросло, ср. время записи 2го файла так же резко подскочило.

Начал копать, наткнулся на тему "Помогите понять что с памятью SQL SERVER R2 enterprise" .
Заметил аналогичные проблемы у себя:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
1) SELECT
    object_name
   ,Counter_name
   ,cntr_value
   ,ROUND(( cntr_value * 8192.0 ) / 1048576, 0) AS cntr_value_MB
FROM
    sys.dm_os_performance_counters
WHERE
    object_Name LIKE '%Buffer Manager%'
    AND RTRIM(counter_name) IN ( 'Free pages', 'Total pages',
                                 'Database pages' ) 
UNION SELECT
    object_name
   ,Counter_name
   ,cntr_value
   ,ROUND(( cntr_value / 1024 ), 0) AS cntr_value_MB
FROM
    sys.dm_os_performance_counters
WHERE
    counter_name IN ( 'Target Server Memory (KB)',
                      'Total Server Memory (KB)' )

2) select physical_memory_in_use_kb from sys.dm_os_process_memory

3) select type, name, sum(multi_pages_kb)/1024 as multi_pages_mb
from sys.dm_os_memory_clerks
where multi_pages_kb > 0
group by type, name
order by multi_pages_mb desc



Результаты:
1) OBJECT_NAME Counter_name cntr_value cntr_value_MB
SQLServer:Buffer Manager Database pages 92559 723.000000000
SQLServer:Buffer Manager Free pages 23469 183.000000000
SQLServer:Buffer Manager Total pages 140832 1100.000000000
SQLServer:Memory Manager Target Server Memory (KB) 4096000 4000.000000000
SQLServer:Memory Manager Total Server Memory (KB) 1126656 1100.000000000

2) physical_memory_in_use_kb
1316256

3) type name multi_pages_mb
MEMORYCLERK_SOSNODE SOS_Node 15
MEMORYCLERK_SQLGENERAL Default 13
CACHESTORE_SQLCP SQL Plans 7
MEMORYCLERK_SQLSTORENG Default 4
CACHESTORE_OBJCP Object Plans 3
USERSTORE_TOKENPERM TokenAndPermUserStore 1
MEMORYCLERK_XE XE Engine 0
CACHESTORE_STACKFRAMES SOS_StackFramesStore 0
USERSTORE_SCHEMAMGR SchemaMgr Store 0
OBJECTSTORE_SNI_PACKET SNIPacket 0
OBJECTSTORE_LBSS LbssCache 0
MEMORYCLERK_HOST MSDART 0
MEMORYCLERK_SQLOPTIMIZER Default 0
MEMORYCLERK_SQLSERVICEBROKER Default 0
CACHESTORE_PHDR Bound Trees 0
MEMORYCLERK_SNI Default 0
MEMORYCLERK_SQLBUFFERPOOL Default 0

В теме, как лечить, увидел только предложение апгрейда до 2012. Мы это, конечно, планируем, но не в ближайшее время.

Буду благодарен, если направите в нужном направлении.
Повторюсь, проблемы появились после переезда на другой сервер: машина и SQL Server(C 2008 R2 SP2 на 2008 R2 SP3).
Хотя, возможно, проблема и была раньше, но мы ее не замечали, либо не стояла так остро.
...
Рейтинг: 0 / 0
17.01.2018, 13:24
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39585841
архивариус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
архивариус
Участник
MegabyteНа двух из них уже несколько раз выскакивала ошибка: There is insufficient system memory in resource pool 'internal' to run this query.
давно дело было, может забыл чего, но с такой ошибкой столкнулся когда на сервере c windows2008 32 битной пытался потестировать работу с колумсторе индексами, конкретнее вроде просто пытался построить кластерный колумсторе индекс на табличке в несколько гигабайт размером.
...
Рейтинг: 0 / 0
17.01.2018, 14:38
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39585977
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Такой вопрос: А временные таблицы, созданные как
SELECT INTO кешируются MS SQL?

Просто в одном запросе, который очень часто вызывается и, судя по различным выборкам, юзает много ресурсов, есть такой запрос:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SELECT 	
			*
		INTO #Table
		FROM OPENXML (@idoc, '*/ShortCallsList/Call',1)
			WITH (
				[status] VARCHAR(50),
				connect_time_t INT,
				id VARCHAR(64),
				start_time_t INT,
				E1_abonent VARCHAR(255) './Endpoint1/@abonent',
				E1_host VARCHAR(50) './Endpoint1/@host',
				E1_number VARCHAR(100) './Endpoint1/@number',
				E2_abonent VARCHAR(255) './Endpoint2/@abonent',
				E2_host VARCHAR(50) './Endpoint2/@host',
				E2_number VARCHAR(100) './Endpoint2/@number'
			) tbl



Имеет ли смысл для производительности\кеширования явно задать структуру временной таблицы?
...
Рейтинг: 0 / 0
17.01.2018, 17:12
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39586104
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
MegabyteИмеет ли смысл для производительности\кеширования явно задать структуру временной таблицы?Без разницы.
...
Рейтинг: 0 / 0
17.01.2018, 22:51
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39586247
dao
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dao
Участник
alexeyvgMegabyteИмеет ли смысл для производительности\кеширования явно задать структуру временной таблицы?Без разницы.
для "производительности\кеширования " без разницы, по с точки зрения поддержки - все же лучше явно задавать.
...
Рейтинг: 0 / 0
18.01.2018, 10:09
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39586251
TaPaK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TaPaK
Участник
daoalexeyvgпропущено...
Без разницы.
для "производительности\кеширования " без разницы, по с точки зрения поддержки - все же лучше явно задавать.
это точно касается памяти sql сервера?
...
Рейтинг: 0 / 0
18.01.2018, 10:10
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39586338
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владислав Колосов
Участник
Megabyte,

авторИмеет ли смысл для производительности\кеширования явно задать структуру временной таблицы?

Если таблицу будете предварительно создавать, то для вставки может потребоваться включить минимальное протоколирование хинтом TABLOCK, если писать SELECT INTO #tt, то там минимальное включается автоматически.
...
Рейтинг: 0 / 0
18.01.2018, 12:03
| Ответить | Цитировать | Написать  
MS SQL cъедает больше памяти, чем ему положено.
    #39596619
Фотография Megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Megabyte
Участник
Если вдруг кому будет интересно, напишу, что делал.

1) Добавление файлов tempDb до 4шт на 4 процессора, как по рекомендации Микрософт, ничего не дало.
2) Начал копать запросы, нашел, что несколько удаленных запросов с другого сервера не самые оптимальные.
Переделал, после этого по статистике вылезли пара необходимых индексов. До этого статистика почему-то показывала только 1 дорогой, но реально совершенно бесполезный индекс(потому как точно такой индекс уже был).
Это снизило ср. время чтения\записи по tempDB, но полностью проблемы не исправило.
3) Сделал настройку SET READ_COMMITTED_SNAPSHOT ON на рабочей базе при стандартном уровне изоляции READ_COMMITTED.
Это уменьшило тип ожидания PAGELATCH_UP на порядок. Проверил по статистике типов ожиданий, которую сохраняю.
Ср. время чтения\записи tempDB и рабочей базы еще больше уменьшилось.

В итоге, полностью блокировки тира PAGELATCH_% полностью не ушли, но субъективно стали короче по времени.

Ошибок памяти пока не наблюдается. Но я сервер перегружал недавно. Буду мониторить.
...
Рейтинг: 0 / 0
05.02.2018, 11:25
| Ответить | Цитировать | Написать  
25 сообщений из 34, страница 1 из 2
  1  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / MS SQL cъедает больше памяти, чем ему положено.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]