Никаких баз не создано.
Ни одного подключения нет.
Процесс sqlservr.exe сожрал 170..200мб памяти, пожирает процессор в диапазоне 16..22% (т.е. почти одно ядро четырёхядерника целиком).
Перезапуск службы не помогает.
В ProcessMonitor особого криминала не вижу. Иногда грузит какие-то библиотеки, иногда читает-пишет в:
ReadFile C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\master.mdf SUCCESS Offset: 65,536, Length: 8,192, I/O Flags: Non-cached, Priority: Normal
ReadFile C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\mssqlsystemresource.mdf SUCCESS Offset: 15,925,248, Length: 65,536, I/O Flags: Non-cached, Priority: Normal
WriteFile C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log\system_health_0_131225149500030000.xel SUCCESS Offset: 112,640, Length: 23,552, I/O Flags: Non-cached, Priority: Normal
ReadFile C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\tempdb.mdf SUCCESS Offset: 2,654,208, Length: 8,192, I/O Flags: Non-cached, Priority: Normal
ReadFile C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\sqllang.dll SUCCESS Offset: 2,581,504, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal
и т.д. Расстояние между событиями в 26 секунд обычное дело, при той же стабильной загрузке CPU. Т.е. жрёт чисто вычислительная задача.
запрос
select * from master..sysprocesses
order by CPU
desc
выдаёт в топе один из двух lastwaittype: PREEMPTIVE_XE_CALLBACKEXECUTE и SLEEP_TASK с дофига cpu, которые всё время растут.
Запустил профайлер. Но мне так не повезло, как камраду в соседней теме. Постоянных запросов нет. Единственный, кто светится среди запросов — телеметрия от SQLServerCEIP, но это не она. Потушил службу — ничего не изменилось. На всякий случай перевёл запуск в manual.
Всего с названием SQL у меня запущено 2 службы: "SQL Server" (хостится в sqlservr.exe) и "SQL Server VSS Writer" (хостится в sqlwriter.exe, процессор не жрёт).
Здравствуйте, IID, Вы писали:
IID>Потушил службу — ничего не изменилось. На всякий случай перевёл запуск в manual.
В смысле — нагрузка CPU не исчезла? Так кто же вжрет на самом деле?
Здравствуйте, IID, Вы писали:
IID>Процесс sqlservr.exe сожрал 170..200мб памяти, пожирает процессор в диапазоне 16..22% (т.е. почти одно ядро четырёхядерника целиком). IID>Перезапуск службы не помогает.
Здравствуйте, IID, Вы писали: IID>Никаких баз не создано. IID>Ни одного подключения нет. IID>Процесс sqlservr.exe сожрал 170..200мб памяти, пожирает процессор в диапазоне 16..22% (т.е. почти одно ядро четырёхядерника целиком). IID>Что это ?
Дополнительно попробуйте еще применить DMV, возможно они прольют свет, чем занимается сервер. Я привел не полный список полей, вы его можете расширить для анализа из документации.
DMV
select scheduler_id,
cpu_id,
current_tasks_count,
runnable_tasks_count,
current_workers_count,
active_workers_count,
work_queue_count
from sys.dm_os_schedulers
where scheduler_id < 255
select top 10 wait_type,
waiting_tasks_count ,
(wait_time_ms - signal_wait_time_ms) as resource_wait_time,
max_wait_time_ms,
case waiting_tasks_count
when 0 then 0
else wait_time_ms / waiting_tasks_count
end as avg_wait_time
from sys.dm_os_wait_stats
where wait_type not like '%SLEEP%'
and wait_type not like 'XE%'
and wait_type not in-- системные
('KSOURCE_WAKEUP', 'BROKER_TASK_STOP', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'SQLTRACE_BUFFER_FLUSH', 'CLR_AUTO_EVENT', 'BROKER_EVENTHANDLER',
'BAD_PAGE_PROCESS', 'BROKER_TRANSMITTER', 'CHECKPOINT_QUEUE',
'DBMIRROR_EVENTS_QUEUE', 'SQLTRACE_BUFFER_FLUSH', 'CLR_MANUAL_EVENT',
'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'LOGMGR_QUEUE',
'BROKER_RECEIVE_WAITFOR', 'PREEMPTIVE_OS_GETPROCADDRESS',
'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'BROKER_TO_FLUSH')
order by wait_time_ms desc-- Несмотря на то, что активности на сервере нет, можно посмотреть дорогостоящие запросы по использованию CPUselect top 10 [Average CPU used] = total_worker_time / qs.execution_count
,[Total CPU used] = total_worker_time
,[Execution count] = qs.execution_count
,[Individual Query] = substring (qt.text,qs.statement_start_offset/2,
(case when qs.statement_end_offset = -1
then len(convert(nvarchar(max), qt.text)) * 2
else qs.statement_end_offset end - qs.statement_start_offset)/2)
,[Parent Query] = qt.text
,DatabaseName = db_name(qt.dbid)
,qs.creation_time
,qs.last_execution_time
from sys.dm_exec_query_stats qs
cross apply sys.dm_exec_sql_text(qs.sql_handle) as qt
order by [Average CPU used] desc
Что касается памяти, то ситуация по наблюдениям нормальная. У меня тоже процесс отъедает 180-200 МБ в неактивном состоянии, в то время как прошлые версии занимают раза в 4-е меньше памяти. А вот чем занят у вас процессор совсем непонятно.
Здравствуйте, Olaf, Вы писали:
O>Дополнительно попробуйте еще применить DMV, возможно они прольют свет, чем занимается сервер. Я привел не полный список полей, вы его можете расширить для анализа из документации.
Спасибо. Но больше не воспроизводится Запустил (отключенную) службу — процессор больше не жрётся. Возможно помог недавний KB3194716. Не знаю.
Правда теперь ДВА процесса sqlservr.exe, из-под юзеров MSSQLSERVER (173mb) и MSSQL$MICROSOFT##WID (143mb). Раньше такого, вроде бы, не было.
Здравствуйте, IID, Вы писали:
IID>Спасибо. Но больше не воспроизводится Запустил (отключенную) службу — процессор больше не жрётся. Возможно помог недавний KB3194716. Не знаю.
Вообще, по описанным тобой симптомам, это может быть баг, связанный с освобождением памяти, который чаще всего проявляется на
виртуальных машинах. Поэтому я спрашивал у тебя, на виртуалке это или на физике появилось. Лечится установлением жестких лимитов
памяти и для SQL Server и для виртуалки. Данный KB вряд ли мог помочь.
IID>Правда теперь ДВА процесса sqlservr.exe, из-под юзеров MSSQLSERVER (173mb) и MSSQL$MICROSOFT##WID (143mb). Раньше такого, вроде бы, не было.
WID — это отдельный инстанс, ставится с некоторыми службами и программами MS. Либо просто не замечал, либо установил что-то дополнительно.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, IID, Вы писали:
IID>>Спасибо. Но больше не воспроизводится Запустил (отключенную) службу — процессор больше не жрётся. Возможно помог недавний KB3194716. Не знаю. _AB>Вообще, по описанным тобой симптомам, это может быть баг, связанный с освобождением памяти, который чаще всего проявляется на _AB>виртуальных машинах. Поэтому я спрашивал у тебя, на виртуалке это или на физике появилось. Лечится установлением жестких лимитов _AB>памяти и для SQL Server и для виртуалки. Данный KB вряд ли мог помочь.
На физической. Я про это выше писал. Что за лимиты ? SQL сервер работает вхолостую, ни одной пользовательской БД на нём нет.
IID>>Правда теперь ДВА процесса sqlservr.exe, из-под юзеров MSSQLSERVER (173mb) и MSSQL$MICROSOFT##WID (143mb). Раньше такого, вроде бы, не было. _AB>WID — это отдельный инстанс, ставится с некоторыми службами и программами MS. Либо просто не замечал, либо установил что-то дополнительно.
Вроде бы ничего не изменилось со времени проявления.
Здравствуйте, IID, Вы писали:
IID>На физической. Я про это выше писал. Что за лимиты ?
Disclaimer. Объяснение поверхностное, а значит содержит допущения, неточности и т.п. вещи. Ну и не без
участия КО оно написано. Кроме того, он может быть путанным и немного перескакивать с одного на другое.
Тут КО уже непричастен.
Каждому инстансу SQL Server можно задать минимальный и максимальный размер используемой памяти.
По умолчанию, эти размеры не ограничены и инстанс при необходимости пытается сожрать всю доступную память.
Если же возникает ситуация нехватки памяти другим приложениям или самой ОС, то винда требует освободить сколько-то памяти.
При незаданном минимальном размере (0 по умолчанию), сервер будет пытаться освободить память всегда, когда этого требует винда.
Скорее всего, внутри есть какая-то незадокументрированная скрытая граница, отличная от дефолтного нуля, но 16-й жрет больше,
чем предыдущие версии, а эту границу могли и не проапдейтить.
Если ты задашь минимальный размер, допустим, в 1 ГБ, то он стартанет с обычных 100+ МБ и не будет пытаться освободить память
по запросу ОС пока не достигнет размера 1 ГБ, а в последующем всегда будет держать за собой минимум 1 ГБ.
IID>SQL сервер работает вхолостую, ни одной пользовательской БД на нём нет.
Сам SQL сервер ни за что не отдаст сожранную память добровольно. Только, если винда затребует. А это уже внешний фактор, не зависящий
от того, крутится что-то на инстансе, или нет. Т.е., не SQL server решает, что ему памяти много, а OS.
И вот тут начинаются те вещи, что ты заметил. Винда по какой-то причине дает команду на освобождение памяти, инстанс начинает очистку — растет
нагрузка на ЦПУ, т.к. процесс очистки небесплатный. Память инстанс освободить не может по какой-либо причине (баг, или и так минимально возможное
количество памяти используется и т.п.) и процесс впадает в цикл, что выражается в постоянно занятом почти на 100% одном ядре.
Если ситуация повторится, и ты заметишь, что памяти в целом на машине мало свободной, попробуй ради интереса задать минимальный объем памяти для
SQL Server хотя бы в 210 МБ и посмотри, решит ли это проблему в загрузкой ядра.
Здравствуйте, _ABC_, Вы писали:
_AB>Каждому инстансу SQL Server можно задать минимальный и максимальный размер используемой памяти. _AB>По умолчанию, эти размеры не ограничены и инстанс при необходимости пытается сожрать всю доступную память. _AB>Если же возникает ситуация нехватки памяти другим приложениям или самой ОС, то винда требует освободить сколько-то памяти.
_AB> ...
_AB>И вот тут начинаются те вещи, что ты заметил. Винда по какой-то причине дает команду на освобождение памяти, инстанс начинает очистку — растет _AB>нагрузка на ЦПУ, т.к. процесс очистки небесплатный.
Нет, у меня точно не эта ситуация. Инстанс сожрал <200мб памяти. В системе 8гб физической. Свободной больше половины.
Запустил (отключенную) службу — процессор больше не жрётся. Возможно помог недавний KB3194716. Не знаю.
