Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 MS SQL cъедает больше памяти, чем ему положено.  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4885
Всем добрый день.

Перебрались недавно на новые сервера.
На двух из них уже несколько раз выскакивала ошибка: 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 с копейками.

Я уже и не знаю, куда копать. Это таки бага верчсии\сервис пака, или мы что-то недонастроили в дб сервере?
---
Проходя мимо разложенных граблей, ты теряешь драгоценный опыт. (с)
12 дек 17, 17:29    [21028216]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36695
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


Сообщение было отредактировано: 12 дек 17, 17:47
12 дек 17, 17:46    [21028280]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7401
Megabyte,

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

съедать могут CLR сборки, XML документы, OLE Automation и т.п.
12 дек 17, 18:03    [21028332]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30801
Megabyte
На двух из них уже несколько раз выскакивала ошибка: There is insufficient system memory in resource pool 'internal' to run this query.
И сервер отъедает памяти больше, чем установлено в настройках.
Это не та память, которую вы указываете в настройках. В настройках задаётся страничный кэш. Так что задавайте с запасом.
Ну и ошибка говорит о баге, а не о нехватке памяти на сервере. Копайтесь, смотрите.
Вот, например, тема: https://www.sql.ru/forum/970396/error-701-there-is-insufficient-system-memory-in-resource-pool-internal-to-run-this-query
Ну и вообще поищите по названию ошибки (если не поможет снижение max memory)
12 дек 17, 19:13    [21028506]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4885
Всем спасибо. Буду копать.
Clr-сборок нет.
xml, ole - да, используем.

Просто странно, что функционал при переезде не менялся, а проблемы появились.
12 дек 17, 21:17    [21028695]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4885
alexeyvg
Megabyte
На двух из них уже несколько раз выскакивала ошибка: There is insufficient system memory in resource pool 'internal' to run this query.
И сервер отъедает памяти больше, чем установлено в настройках.
Это не та память, которую вы указываете в настройках. В настройках задаётся страничный кэш. Так что задавайте с запасом.
Ну и ошибка говорит о баге, а не о нехватке памяти на сервере. Копайтесь, смотрите.
Вот, например, тема: https://www.sql.ru/forum/970396/error-701-there-is-insufficient-system-memory-in-resource-pool-internal-to-run-this-query
Ну и вообще поищите по названию ошибки (если не поможет снижение max memory)

Да, спасибо. Тему эту конечно же читал, но поверхносно.
12 дек 17, 21:19    [21028704]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Гигабайт Мегабайтович Килобайтов
Member [заблокирован]

Откуда:
Сообщений: 5975
Megabyte
Всем спасибо. Буду копать.
Clr-сборок нет.
xml, ole - да, используем.

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

а настройки памяти менялись?))
13 дек 17, 15:25    [21030985]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4885
Гигабайт Мегабайтович Килобайтов
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).


Выполнил запрос:
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 на несколько файлов, но расположенных на одном диске, какую-то пользу вообще дает?
25 дек 17, 16:21    [21061006]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 33265
Блог
Megabyte
2) Как избавляться от ожиданий PAGELATCH_XX?
5) Разбирение tempDB на несколько файлов, но расположенных на одном диске, какую-то пользу вообще дает?


2) добавить больше дисков, SSD, добавить памяти, оптимизировать свой код
5) да
25 дек 17, 16:52    [21061102]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4885
Критик
Megabyte
2) Как избавляться от ожиданий PAGELATCH_XX?
5) Разбирение tempDB на несколько файлов, но расположенных на одном диске, какую-то пользу вообще дает?


2) добавить больше дисков, SSD, добавить памяти, оптимизировать свой код
5) да

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

5) А подробнее можно? В чем будет плюс? Если бы другие файлы были бы на другом диске, я бы понял пользу...
25 дек 17, 17:29    [21061233]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Eleanor
Member

Откуда:
Сообщений: 2634
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 на разных дисках и ускорения дисковой подсистемы была бы польза.
25 дек 17, 22:25    [21061666]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
step_ks
Member

Откуда:
Сообщений: 936
Megabyte
Всем добрый день.

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


1. В "min memory per query" ничего неординарного не выставлено?
2. Попробуйте определить запросы, на которых падает. Возможно, их не так много и у них будет что-то общее.
25 дек 17, 22:48    [21061732]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
f000
Member

Откуда: 61
Сообщений: 48
про tempdb - послушайте Диму АртЁмова
[url=]https://www.techdays.ru/videos/6565.html[/url]
26 дек 17, 09:02    [21062081]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
f000
Member

Откуда: 61
Сообщений: 48
про память
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Гб, и все стало как то невесело. пришлось подбирать параметр методом "тыка".
26 дек 17, 09:43    [21062149]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4885
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 на разных дисках и ускорения дисковой подсистемы была бы польза.

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

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

Перебрались недавно на новые сервера.
На двух из них уже несколько раз выскакивала ошибка: 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: спасибо, ознакомлюсь.
26 дек 17, 11:11    [21062451]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
смотрю_тут
Member

Откуда:
Сообщений: 1368
в 2008 R2 еще есть понятие multipage, эта память BLOB и другая которая вне буфферного пула сиквела, есть представление по которому надо смотреть sys.dm_os_memory_clerks , сколько идет памяти на это,
в версия после 2008r2 этого уже нет, эта память внутри буферного пула.
+ к этому как говорили все xml, clr так же вне буферного пула.
запрос про multi страницы ниже:
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/
26 дек 17, 22:58    [21064984]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
f000
Member

Откуда: 61
Сообщений: 48
тут тоже не менее интересно:
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 использовать их сумму или иерархия какая то другая?
27 дек 17, 10:04    [21065635]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4885
Реанимирую тему.

Просмотрел лекцию.
f000
про tempdb - послушайте Диму АртЁмова
[url=]https://www.techdays.ru/videos/6565.html[/url]

Изучил типы страниц IAM, GAM, SGAM, PFS.

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

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

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

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

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).
Хотя, возможно, проблема и была раньше, но мы ее не замечали, либо не стояла так остро.
17 янв 18, 13:24    [21113680]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
архивариус
Member

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

давно дело было, может забыл чего, но с такой ошибкой столкнулся когда на сервере c windows2008 32 битной пытался потестировать работу с колумсторе индексами, конкретнее вроде просто пытался построить кластерный колумсторе индекс на табличке в несколько гигабайт размером.
17 янв 18, 14:38    [21114064]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4885
Такой вопрос: А временные таблицы, созданные как
SELECT INTO кешируются MS SQL?

Просто в одном запросе, который очень часто вызывается и, судя по различным выборкам, юзает много ресурсов, есть такой запрос:
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


Имеет ли смысл для производительности\кеширования явно задать структуру временной таблицы?
17 янв 18, 17:12    [21114523]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30801
Megabyte
Имеет ли смысл для производительности\кеширования явно задать структуру временной таблицы?
Без разницы.
17 янв 18, 22:51    [21115076]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
dao
Member

Откуда: Москва
Сообщений: 771
alexeyvg
Megabyte
Имеет ли смысл для производительности\кеширования явно задать структуру временной таблицы?
Без разницы.

для "производительности\кеширования " без разницы, по с точки зрения поддержки - все же лучше явно задавать.
18 янв 18, 10:09    [21115646]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
dao
alexeyvg
пропущено...
Без разницы.

для "производительности\кеширования " без разницы, по с точки зрения поддержки - все же лучше явно задавать.

это точно касается памяти sql сервера?
18 янв 18, 10:10    [21115652]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7401
Megabyte,

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


Если таблицу будете предварительно создавать, то для вставки может потребоваться включить минимальное протоколирование хинтом TABLOCK, если писать SELECT INTO #tt, то там минимальное включается автоматически.
18 янв 18, 12:03    [21116029]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL cъедает больше памяти, чем ему положено.  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4885
Если вдруг кому будет интересно, напишу, что делал.

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

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

Ошибок памяти пока не наблюдается. Но я сервер перегружал недавно. Буду мониторить.
5 фев 18, 11:25    [21166135]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить