T server проверка памяти команды

Обновлено: 06.07.2024

Продолжаем анализировать что происходит на нашем MS SQL сервере. В этой части посмотрим как получить информацию о работе пользователей: кто и что делает, сколько ресурсов на это расходуется.

Думаю, вторая часть будет интересна не только админам БД, но и разработчикам (возможно даже разработчикам больше), которым необходимо разбираться, что не так с запросами на рабочем сервере, которые до этого отлично работали в тестовом.

Задачи анализа действий пользователей условно поделим на группы и рассмотрим каждую отдельно:

Анализ производительности требует глубокого понимания устройства и принципов работы сервера БД и ОС. Поэтому, чтение только этих статей не сделает из вас эксперта.

Рассматриваемые критерии и счетчики в реальных системах находятся в сложной зависимости друг от друга. Например высокая нагрузка HDD, часто связана с проблемой не самого HDD, а с нехваткой оперативной памяти. Даже если вы проведете некоторые из замеров — этого недостаточно для взвешенной оценки проблем.

Цель статей — познакомить с базовыми вещами на простых примерах. Рекомендации не стоит рассматривать как «руководство к действию», рассматривайте их как учебные задачи (упрощенно отражающие действительность) и как варианты «на подумать», призванные пояснить ход мысли.
Надеюсь, по итогу статей вы научитесь аргументировать цифрами свои заключения о работе сервера. И вместо слов «сервер тормозит» будете приводить конкретные величины конкретных показателей.

Анализируем конкретный запрос

Первый пункт довольно прост, остановимся на нем кратко. Рассмотрим только некоторые малоочевидные вещи.

Практически все знают, что план запроса получается кнопками «Display Estimated Execution Plan» (оценочный план) и «Include Actual Execution Plan» (фактический план). Отличаются они тем, что оценочный план строится без выполнения запроса. Соответственно, информация о количестве обработанных строк в нем будет только оценочная. В фактическом плане будут как оценочные данные, так и фактические. Сильные расхождения этих величин говорят о неактуальности статистики. Впрочем, анализ плана — тема для отдельной большой статьи — пока не будем углубляться.
Менее известный факт — можно получать замеры затрат процессора и дисковых операций сервера. Для этого необходимо включить SET опции либо в диалоге через меню «Query» / «Query options. »

либо напрямую командами SET в запросе, например

В результате выполнения, получим данные по затратам времени на компиляцию и выполнение, а также, количество дисковых операций.

Время синтаксического анализа и компиляции SQL Server:
время ЦП = 16 мс, истекшее время = 89 мс.

Время работы SQL Server:
Время ЦП = 0 мс, затраченное время = 0 мс.

Время работы SQL Server:
Время ЦП = 15 мс, затраченное время = 35 мс.

Пример, на котором видно что первое выполнение занимает больше времени

Затраты процессора смотрим используя SET STATISTICS TIME ON.
Дисковые операции: SET STATISTICS IO ON. Не забываем, что «логическое чтение» — это операция чтения, завершившаяся в кэше диска без физического обращения к дисковой системе. «Физическое чтение» требует значительно больше времени.
Объем сетевого трафика оцениваем с помощью «Include Client Statistics».
Детально алгоритм выполнения запроса анализируем по «плану выполнения» с помощью «Include Actual Execution Plan» и «Include Live Query Statistics».

Анализируем нагрузку от приложения

Чуть более сложный путь — к выбранному шаблону добавить (или убавить) фильтров или событий. Данные опции на второй закладке диалога. Чтобы увидеть полный набор возможных событий и колонок для выбора — отметьте пункты «Show All Events» и «Show All Columns».

Из событий нам потребуются (лишние лучше не включать — чтобы создавать меньше трафика):

Stored Procedures \ RPC:Completed
TSQL \ SQL:BatchCompleted

Stored Procedures \ RPC:Starting
TSQL \ SQL:BatchStarting

Еще полезные события, которые мы пока не будем включать:

Stored Procedures \ SP:Starting (*Completed) — фиксирует внутренний вызов хранимой процедуры (не с клиента, а внутри текущего запроса или другой процедуры).
Stored Procedures \ SP:StmtStarting (*Completed) — фиксирует старт каждого выражения внутри хранимой процедуры. Если в процедуре цикл — будет столько событий для команд внутри цикла, сколько итераций было в цикле.
TSQL \ SQL:StmtStarting (*Completed) — фиксирует старт каждого выражения внутри SQL-batch. Если ваш запрос содержит несколько команд — будет по событию на каждую. Т.е. аналогично предыдущему, только действует не для команд внутри процедур, а для команд внутри запроса.

По колонкам

Какие выбирать, как правило, понятно из названия колонки. Нам будут нужны:

TextData, BinaryData — для описанных выше событий содержат сам текст запроса.
CPU, Reads, Writes, Duration — данные о затратах ресурсов.
StartTime, EndTime — время начала/окончания выполнения. Удобны для сортировки.

По кнопке «Column Filters. » можно вызвать диалог установки фильтров событий. Если интересует активность конкретного пользователя — задать фильтр по номеру сессии или имени пользователя. К сожалению, в случае подключения приложения через app-server c пулом коннектов — отследить конкретного пользователя сложнее.

Фильтры можно использовать, например, для отбора только «тяжелых» запросов (Duration>X). Или запросов которые вызывают интенсивную запись (Writes>Y). Да хоть просто по содержимому запроса.

Что же еще нам нужно от профайлера? Конечно же план выполнения!

Такая возможность имеется. Необходимо добавить в трассировку событие «Performance \ Showplan XML Statistics Profile». Выполняя наш запрос, мы получим примерно следующую картинку.

И это еще не всё

Трассу можно сохранять в файл или таблицу БД (а не только выводить на экран).
Настройки трассировки можно сохранить в виде личного template для быстрого запуска.
Запуск трассировки можно выполнять и без профайлера — с помощью t-sql кода, используя процедуры: sp_trace_create, sp_trace_setevent, sp_trace_setstatus, sp_trace_getdata. Пример как это сделать. Данный подход может пригодиться, например, для автоматического старта записи трассы в файл по расписанию. Как именно использовать эти команды, можно подсмотреть у самого профайлера. Достаточно запустить две трассировки и в одной отследить что происходит при старте второй. Обратите внимание на фильтр по колонке «ApplicationName» — проконтролируйте, что там отсутствует фильтр на сам профайлер.

Список событий фиксируемых профайлером очень обширен и не ограничивается только получением текстов запросов. Имеются события фиксирующие fullscan, рекомпиляции, autogrow, deadlock и многое другое.

Анализируем активность пользователей в целом по серверу

Жизненные ситуации бывают и такими, когда информация из разделов выше не помогает:
Какой-то запрос висит на «выполнении» очень долго и непонятно, закончится он когда-нибудь или нет. Проанализировать проблемный запрос отдельно — хотелось бы — но надо сначала определить что за запрос. Профайлером ловить бесполезно — starting событие мы уже пропустили, а completed неясно сколько ждать.

А может висит и не пользовательский запрос совсем, а может это сам сервер что-то активно делает…

Давайте разбираться

Все вы наверно видели «Activity Monitor». В старших студиях его функционал стал богаче. Чем он может нам помочь? В «Activity Monitor» много полезного и интересного, но третий раздел не о нем. Всё что нужно будем доставать напрямую из системных представлений и функций (а сам Монитор полезен тем, что на него можно натравить профайлер и посмотреть какие запросы он выполняет).

session_id — код сессии для связи с предыдущим представлением
start_time — время старта запроса
command — это поле, вопреки названию, содержит не запрос, а тип выполняемой команды. Для пользовательских запросов — обычно это что-то вроде select/update/delete/и т.п. (также, важные примечания ниже)
sql_handle, statement_start_offset, statement_end_offset — информация для получения текста запроса: хэндл, а также начальная и конечная позиция в тексте запроса — обозначающая часть выполняемую в данный момент (для случая когда ваш запрос содержит несколько команд).
plan_handle — хэндл сгенерированного плана.
blocking_session_id — при возникновении блокировок препятствующих выполнению запроса — указывает на номер сессии которая стала причиной блокировки
wait_type, wait_time, wait_resource — поля с информацией о причине и длительности ожидания. Для некоторых видов ожидания, например, блокировка данных — дополнительно указывается код заблокированного ресурса.
percent_complete — по названию понятно, что это процент выполнения. К сожалению, доступен только для команд у которых четко прогнозируемый прогресс выполнения (например, backup или restore).
cpu_time, reads, writes, logical_reads, granted_query_memory — затраты ресурсов.

Приведенный перечень — лишь малая часть. Полный список всех системных представлений и функций описан в документации. Также, имеется схема связей основных объектов в виде красивой картинки — можно распечатать на А1 и повесить на стену.

Текст запроса, его план и статистика исполнения — данные хранящиеся в процедурном кэше. Во время выполнения они доступны. После выполнения доступность не гарантируется и зависит от давления на кэш. Да, кэш можно очищать вручную. Иногда это советуют делать когда «поплыли» планы выполнения, но тут очень много нюансов… В общем, «Имеются противопоказания, рекомендовано проконсультироваться со специалистом».

Поле «command» — для пользовательских запросов оно практически бессмысленно — ведь мы можем получить полный текст… Но не всё так просто. Это поле очень важно для получения информации о системных процессах. Как правило, они выполняют какие-то внутренние задачи и не имеют текста sql. Для таких процессов, информация о команде единственный намек на тип активности. В комментариях к предыдущей статье был вопрос про то, чем занят сервер, когда он, вроде бы, ничем не должен быть занят — возможно ответ будет в значении этого поля. На моей практике, поле «command» для активных системных процессов всегда выдавало что-то вполне понятное: autoshrink/autogrow/checkpoint/logwriter/и т.п.

Как же это использовать

Перейдем к практической части. Я приведу несколько примеров использования, но не стоит ограничивать вашу фантазию. Возможности сервера этим не исчерпываются — можете придумывать что-то своё.

Пример 1: Какой процесс расходует cpu/reads/writes/memory

Для начала, посмотрим какие сессии больше всего потребляют, например, CPU. Информация в sys.dm_exec_sessions. Но данные по CPU (а также reads, writes) — накопительные. Т.е цифра в поле содержит «итого» за все время подключения. Понятно, что больше всего будет у того кто подключился месяц назад, да так и не отключался ни разу. Это вовсе не означает, что он прямо сейчас грузит систему.

Немного кода решает проблему, алгоритм примерно такой:

сначала сделаем выборку и сохраним во временную таблицу
затем подождем немного
делаем выборку второй раз
сравниваем результаты первой и второй выборки — разница, как раз и будет затратами возникшими на п.2
для удобства, разницу можем поделить на длительность п.2, чтобы получить усредненные «затраты в секунду».

Те, кто не любят выполнять запрос в студии — могут его завернуть в приложение написанное на своём любимом языке программирования. Я покажу как это сделать в MS Excel без единой строки кода.

В меню «Данные» подключаемся к серверу. Если будет требовать выбрать таблицу — выбираем произвольную — потом поменяем это. Как всегда, жмем «Next» и «Finish» пока не увидим диалог «Импорт данных» — в нем нужно нажать «Свойства. ». В свойствах необходимо сменить «тип команды» на значение «SQL» и в поле «текст команды» вставить немного измененный наш запрос.

Запрос придется немного поменять:

добавим «SET NOCOUNT ON» — т.к. Excel не любит отсечки количества строк;
«временные таблицы» заменим на «таблицы переменные»;
задержка всегда будет 1сек — поля с усредненными значениями не нужны

Когда данные будут в Excel-е, можете их сортировать как вам нужно. Для актуализации информации — жмите «Обновить». В настройках книги, для удобства, можете поставить «автообновление» через заданный период времени и «обновление при открытии». Файл можете сохранить и передать коллегам. Таким образом, мы из ~~навоза и веточек~~ подручных средств собрали ~~ЫнтерпрайзМониторингТул~~ удобный и простой инструмент.

Пример 2: На что сессия расходует ресурсы

Итак, в предыдущем примере мы определили проблемные сессии. Теперь определим, что именно они делают. Используем sys.dm_exec_requests, а также функции получения текста и плана запроса.

Подставляйте в запрос номер сессии и выполняйте. После выполнения, на закладке «Results» будут планы (два: первый для всего запроса, второй для текущего шага — если шагов в запросе несколько), на закладке «Messages» — текст запроса. Для просмотра плана — необходимо кликнуть в строке на текст оформленный в виде url. План откроется в отдельной закладке. Иногда бывает что план открывается не в графическом виде, а в виде xml-текста. Это, скорее всего, связано с тем что версия студии ниже чем сервера. Попробуйте пересохранить полученный xml в файл с расширением sqlplan, предварительно удалив из первой строки упоминания «Version» и «Build», а затем отдельно открыть его. Если и это не помогает — напоминаю, что 2016 студия официально доступна бесплатно на сайте MS.

Очевидно, полученный план будет «оценочным», т.к. запрос еще выполняется. Но некоторую статистику по выполнению получить всё равно можно. Используем представление sys.dm_exec_query_stats с фильтром по нашим хэндлам.

Допишем в конец предыдущего запроса

После выполнения, в результатах получим информацию о шагах выполняемого запроса: сколько раз они выполнялись и какие ресурсы потрачены. Информация в статистику попадает после выполнения — при первом выполнении там, к сожалению, пусто. Статистика не привязана к пользователю, а ведется в рамках всего сервера — если разные пользователи выполняют один и тот же запрос — статистика будет суммарная по всем.

Пример 3: А можно всех посмотреть

Давайте объединим рассмотренные системные представления и функции в одном запросе. Это может быть удобно для оценки ситуации в целом.

Запрос выводит список активных сессий и тексты их запросов. Для системных процессов, напоминаю, обычно запрос отсутствует, но заполнено поле «command». Видна информация о блокировках и ожиданиях. Можете попробовать скрестить этот запрос с примером 1, чтобы еще и отсортировать по нагрузке. Но будьте аккуратны — тексты запросов могут оказаться очень большими. Выбирать их массово может оказаться ресурсоемко. Да и трафик будет большим. В примере я ограничил получаемый запрос первыми 500 символами, а получение плана не стал делать.

Примеры запросов выложил на гитхаб.

Заключение

Было бы ещё неплохо, получить Live Query Statistics для произвольной сессии. По заявлению производителя, на текущий момент, постоянный сбор статистики требует значительных ресурсов и поэтому, по умолчанию, отключен. Включить не проблема, но дополнительные манипуляции усложняют процесс и уменьшают практическую пользу. Возможно, попробуем это сделать в отдельной статье.

В этой части мы рассмотрели анализ действий пользователей. Попробовали несколько способов: используя возможности самой студии, используя профайлер, а также прямые обращения к системным представлениям. Все эти способы позволяют оценить затраты на выполнение запроса и получить план исполнения. Ограничиваться одним из них не нужно — каждый способ удобен в своей ситуации. Пробуйте комбинировать.

В этой статье мы рассмотрим популярные инструменты, T-SQL запросы и скрипты для обнаружения и решения различных возможных проблем с производительностью SQL Server. Эта статья поможет вам разобраться, когда вашему SQL Server недостаточно ресурсов (памяти, CPU, IOPs дисков), найти блокировки, выявить медленные запросы. Посмотрим какие есть встроенные инструменты и бесплатные сторонние скрипты и утилиты для анализа состояния Microsoft SQL Server.

Инструменты для диагностики SQL Server

Если вы правильно диагностировали проблему, то половина работы уже сделана. Рассмотрим какие инструменты обычно используются системным администратором для диагностики различных проблем в SQL Server:

Обнаружение и решение проблем с производительностью SQL Server

Самой распространенной проблемой с которой сталкивается системный администратор, работающий с SQL Server, это жалобы пользователей на производительность запросов и самого сервера: “тормозит”, “долго выполняется запрос“, и так далее.

Прежде всего нужно убедиться, что серверу хватает ресурсов. Рассмотрим, как в SQL Server быстро проанализировать использование памяти, CPU, дисков и наличие блокировок.

Анализ использования оперативной памяти SQL Server

Для начала нужно определить сколько памяти доступно SQL Server. Для этого запустите SSMS (SQL Server Management Studio), зайдите на сервер и зайдите в свойства сервера (ПКМ по названию сервера в Обозревателе объектов).

Сам по себе доступный объём RAM вам ничего не скажет. Нужно сравнить это число с используемой памятью в Диспетчере Задач и самим движком SQL Server с помощью DMV.

В Диспетчере задач, во вкладке Подробности, найдите sqlservr.exe и посмотрите сколько оперативной памяти использует этот процесс.

Если на сервере, например, 128 GB оперативной памяти, а процесс sqlservr.exe использует 60 GB и ограничений по RAM у SQL Server нет, то оперативной памяти вам хватает.
Если SQL Server использует 80-90% RAM от заданной или максимальной, то в таком случае нужно смотреть DMV. Имейте в виду, что sqlservr.exe не сможет использовать всю оперативную память. Если на сервере 128 GB, то sqlservr.exe может использовать только 80-90% (100-110 GB), так как остальная память резервируется для операционной системы.

Имейте в виду, что процесс SQL Server’a не отдаёт оперативную память обратно в систему. Например, ваш SQL Server обычно использует 20 GB памяти, но при месячном отчете он увеличивает потребление до 100 GB, и даже когда вычисление отчета закончится и сервер будет работать в прежнем режиме, процесс SQL Server’a всё равно будет использовать 100 GB до перезагрузки службы.

Даже если вы уверены, что оперативной памяти серверу хватает, не будет лишним точно знать объём потребляемой RAM.

Узнать реальное использование RAM можно с помощью Dynamic Management Views. DMV это административные вьюверы (представления). С помощью DMV можно диагностировать практически любую проблему в SQL Server.

Посмотрим sys.dm_os_sys_memory, для удобства используем запрос:

Рассмотрим каждый выводимый параметр:

Все эти данные полезны, если вы хотите точно определить сколько ваш SQL Server потребляет RAM. Чаще всего это используют, если есть подозрения что для экземпляра выделено слишком много оперативной памяти.

Если Вам нужно убедиться, что серверу хватает RAM, вы можете смотреть только на поля system_low_memory_signal_state, system_high_memory_signal_state и system_memory_state_desc. Если system_low_memory_signal_state = 1, то серверу явно не хватает оперативной памяти.

Загрузка процессора в SQL Server

Нагрузку на процессор определить проще, так как это можно сделать в Диспетчере задач. Чтобы узнать текущую нагрузку на процессор, найдите в Диспетчере задач процесс sqlservr.exe

Если вы хотите узнать нагрузку за прошедшее время, можно воспользоваться запросом:

В результате мы получим поминутную статистику использования процессора.

Анализ нагрузки на диск SQL Server

Посмотрим на загрузку дисков в операционной системе. Для этого запустите resmon.exe.

Нам нужна вкладка Disk. В секции Disk Activity отображаются файлы, к которым идёт обращение, и их скорость read/write на текущий момент. Отфильтруйте эту секцию по Total (кликните на Total). На самом верху будут файлы, которые на данный момент максимально используют диск. В случае с SQL Server это может быть полезно чтобы определить какая база больше всего нагружает диск на текущий момент.

В секции Storage отображаются все диски в системе. В этой секции нам нужны 2 параметра – Active Time и Disk Queue. Active Time в процентах отображает нагрузку на диск, то есть если вы видите на диске C:\ Active Time равный 90, это значит что ресурс чтения/записи диска на текущий момент используется на 90%. Столбец Disk Queue отображает очередь обращений к диску, и если значение очереди не равно нулю, то диск загружен на 100% и не справляется с нагрузкой. Так же если Active Time близок к 100, то диск используется практически на пределе своих возможностей по скорости.

Просмотр блокировок в SQL Server

После того как мы убедились, что серверу хватает ресурсов, можно переходить к просмотру блокировок.

Блокировки можно посмотреть через Activity Monitor в SSMS, но мы воспользуемся T-SQL, так как этот вариант более удобен и нагляден. Выполняем запрос:

Этот запрос возвращает список блокировок в виде дерева. Это удобно в работе, так как обычно, если возникает одна блокировка, она провоцирует за собой другие. Аналогично в Activity Monitor или в выводе sp_who2 можно увидеть поле “Blocked By”.

Если запрос ничего не вернул, то блокировок нет.

Если запрос вернул какие-то данные, то нужно проанализировать цепочку.

HEAD значит что этот запрос является причиной всех остальных блокировок ниже по дереву. 64 – это идентификатор процесса (SPID). После этого пишется тело запроса, который вызвал блокировку. Если у вас хватает ресурсов сервера, то скорее всего дело в самом запросе и во взаимном обращении к каким-то объектам. Для того чтобы сказать точнее, нужно анализировать конкретный запрос, который вызвал блокировку.

Политики SQL Server

Даже когда у вас всё работает хорошо и жалоб нет, на самом деле может быть много проблем, которые всплывут позже. Для этого в SQL Server есть политики.

Политика в SQL Server это, грубо говоря, проверка правила на соответствие заданному значению. Например, с помощью политик вы можете убедиться, что на всех базах на сервере выключен Auto Shrink. Рассмотрим пример импорта и выполнения политики

В SSMS, подключитесь к серверу, на котором хотите выполнять политики (Management -> раздел Policy Management).

Импортируем файл Database Auto Shrink.xml. Жмём Evaluate

На экземпляре node1 две базы данных, test1 и test2. На test2 включен autoshrink. Посмотрим детали.

Политика определила включенный параметр AutoShrink, в описании обычно пишется объяснения к правилам. В данном случае дается объяснение почему auto shrink лучше отключать.

Политики могут выполняться либо по расписанию, либо по требованию (разово). Результаты выполнения политики можно посмотреть в журнале политик.

При установке SQL Server нужно выбирать только используемые компоненты СУБД, и указывать настройки в соответствии с конфигурацией “железа” вашего сервера. Всегда следите чтобы серверу хватало ресурсов, и чтобы на сервере не было блокировок

Самым мощным инструментом для диагностики SQL Server является T-SQL и DMV. Так же рекомендуется построить круглосуточный мониторинг над SQL Server и над обслуживающей его инфраструктурой для обнаружения всех возможных проблем.

Если сбои системы, синие экраны BSoD или иные проблемы при работе Windows 10, 8.1 или Windows 7 наводят вас на мысли о том, что имеются какие-либо проблемы с оперативной памятью компьютера, может иметь смысл выполнить её проверку, а начать можно со встроенного средства диагностики проверки памяти Windows.

В этой инструкции подробно о способах запустить средство проверки памяти средствами Windows, причём даже в тех случаях, когда вход в систему невозможен, а также о возможных вариантах действий в случае, если в результате теста средство диагностики памяти сообщает о том, что были обнаружены проблемы оборудования. На схожую тему: Устранение неполадок Windows 10.

Как запустить средство проверки памяти в Windows 10 и предыдущих версиях системы

В случае, если операционная система запускается, вход в неё и работа возможны, вы можете использовать один из следующих вариантов запуска средства проверки памяти:

Найти нужный пункт в разделе «Средства администрирования Windows» меню «Пуск».
Нажать клавиши Win+R на клавиатуре, ввести mdsched.exe и нажать Enter.
Открыть панель управления, выбрать пункт «Администрирование» и запустить «Средство проверки памяти Windows».
Использовать поиск в панели задач Windows 10, начав вводить «Средство проверки памяти». Или встроенные средства поиска в предыдущих версиях ОС.
Вручную запустить файл C:\Windows\System32\MdSched.exe

Если же ситуация осложняется тем, что Windows не запускается, вход в неё невозможен, либо сразу после него происходят сбои, можно использовать следующие способы запуска средства диагностики оперативной памяти:

Загрузить компьютер или ноутбук с загрузочной флешки с Windows 10 или другой версией Windows, можно и с загрузочного диска. На экране программы установки нажать клавиши Shift+F10 (Shift+Fn+F10 на некоторых ноутбуках), ввести mdsexe в открывшейся командной строке и нажать Enter. После выбора в утилите проверки пункта «Выполнить перезагрузку и проверку», загружайте компьютер не с флешки, а с обычного загрузочного HDD или SSD.
Средство проверки памяти можно запустить из среды восстановления Windows 10 — нажав кнопку «Дополнительные параметры» на синем экране с ошибкой или, находясь на экране блокировки Windows 10 (с выбором имени пользователя) нажать по изображенной справа внизу кнопке «Питания», а затем, удерживая Shift, нажать «Перезагрузка». В среде восстановления выбираем «Поиск и устранение неисправностей» — «Дополнительные параметры» — «Командная строка». А в ней, как и в предыдущем случае используем команду mdsched.exe.
Если у вас есть подготовленный диск восстановления Windows, запуск можно осуществить, загрузившись с него.

Использование средства проверки памяти Windows и просмотр результатов

После запуска средства проверки памяти вам будет предложено перезагрузить компьютер, после согласия, процесс будет выглядеть следующим образом:

Начнётся проверка оперативной памяти, которая может занять продолжительное время. Может показаться, что средство диагностики зависло: на всякий случай подождите в такой ситуации 5-10 минут. Если же действительно произошло зависание, не исключено что есть проблемы с оборудованием, вероятно — с оперативной памятью, но не обязательно.
Если в ходе проверки нажать клавишу F1 (или Fn+F1, если F1 не срабатывает), вы попадёте в настройки средства диагностики памяти Windows. Здесь можно выбрать набор тестов (по умолчанию — обычный), использование кэша, и число проходов. Переключение между разделами настроек выполняется клавишей Tab, изменение параметров — стрелками и вводом цифр (для числа проходов), применение параметров — клавишей F10. После изменения настроек тест перезапускается.
В ходе проверки вы будете видеть информацию вида «Неполадки пока не обнаружены» или «Были обнаружены проблемы оборудования».

После завершения проверки компьютер будет автоматически перезагружен. Дальнейшие шаги — просмотр результатов.

После перезагрузки в случае Windows 10 вы можете увидеть уведомление в области уведомлений, сообщающее о результате проверки памяти. Но оно отображается не всегда.
Можно зайти в просмотр событий, для этого нажимаем Win+R, вводим eventvwr.msc и нажимаем Enter. Там открываем раздел «Журналы Windows» — «Система», находим пункты, где в столбце «Источник» указано MemoryDiagnostics-Results и просматриваем результаты.

Учитывайте, что ошибки, «вылеты», синие экраны и зависания не всегда связаны с проблемами оперативной памяти: если средство диагностики показывает, что всё в порядке, есть и иные возможные причины: отключенный файл подкачки, проблемы с HDD или SSD (или с их подключением, например — неисправный кабель), сторонние антивирусы или, наоборот, вредоносные программы, неправильная работа драйверов оборудования.

Что делать, если были обнаружены проблемы оборудования в средстве диагностики памяти

К сожалению, средство диагностики не сообщает о том, какие именно проблемы были обнаружены в ходе проверки, а лишь рекомендует обратиться к производителю оборудования. Что можно сделать:

Отключить любые опции ускорения памяти (изменение частоты, таймингов и другие) при наличии соответствующих опций в БИОС или ПО производителя материнской платы или ноутбука.
Попробовать проверить планки памяти по одной, в других слотах на материнской плате для того, чтобы выяснить, появляются ли проблемы только с одним конкретным модулем памяти или в одном конкретном разъеме.
Использовать другие утилиты для проверки оперативной памяти при необходимости.
Прочитать документацию к материнской плате ПК — возможно, это какая-то несовместимость с памятью с конкретными характеристиками (если вы недавно добавили новые модули памяти или только что самостоятельно собрали компьютер).
Иногда может помочь обновление БИОС.

Видео инструкция

Если вы разобрались, чем была вызвана именно ваша проблема, буду благодарен комментарию к статье: возможно, для кого-то он окажется полезным.

Изо всех компонентов компьютера оперативная память наиболее часто становится причиной сбоев. Для диагностики памяти существует множество различных программ, однако, как правило, в нужный момент их не оказывается под рукой. Специально на такой случай в Windows имеется встроенная утилита для проверки оперативной памяти.

Запустить ее очень просто, достаточно нажать сочетание клавиш Win+R и выполнить команду mdsched.

Можно выбрать немедленную перезагрузку и запуск проверки, а можно отложить проверку до следующего запуска компьютера.

Проверка запускается сразу после перезагрузки. Можно оставить настройки по умолчанию, а можно нажать F1 и изменить их.

Для проверки доступны три набора тестов:

Дополнительно можно включить\отключить использование кэша и выбрать количество количество повторений теста (от 0 до 15). По умолчанию тест запускаются в два прохода, если указать 0, то тест будет отрабатывать до тех пор, пока его не остановят вручную.

Переключение между настройками осуществляется клавишей TAB, а клавиша F10 запускает проверку с выбранными настройками.

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

Если же ошибок не будет, то после окончания тестов компьютер будет перезагружен и в панели задач появится уведомление об отсутствии ошибок.

Утилиту для проверки оперативной памяти очень удобно использовать, поскольку она всегда под рукой и не требует загрузки дополнительного ПО. Утилита присутствует во всех более-менее актуальных операционных системах, начиная Windows Vista и заканчивая Windows 10.

Читайте также: