Memory failure retry что это

MSI MPG B550 GAMING PLUS Краткое Руководство онлайн [171/176] 579706

39 UEFI BIOS Memory Try It Disabled Позволяет улучшить совместимость памяти и производительность путем выбора наиболее оптимального пресета Этот пункт доступен только в случае если установлен модуль памяти с поддержкой данной функции Memory Failure Retry Enabled Включение или отключение функции перезагрузки при неудачных попыток загрузки Memory Retry Memory Failure Retry Count 2 Устанавливает предел количества попыток загрузки Memory Retry При достижении заданного количества неудачных попыток загрузки Memory Retry настройки памяти восстанавливаются до последних рабочих параметров Данный пункт отображается когда функция Memory Failure Retry установлена в Enabled Advanced DRAM Con guration Нажмите Enter для входа в подменю Пользователь может настроить тайминги для каждого канала памяти Система может работать нестабильно или не загружаться после изменения таймингов памяти Если система работает нестабильно пожалуйста очистите данные CMOS и восстановите настройки по умолчанию см перемычка очистки данных CMOS раздел кнопки для очистки данных CMOS и вход в BIOS чтобы загрузить настройки по умолчанию DigitALL Power sub menu Нажмите Enter для входа в подменю в котором вы можете настроить защитные условия для напряжения тока температуры процессора CPU Voltages control Auto Эти параметры позволяют вам задать напряжения связанные с процессором При установке в Auto BIOS установит напряжения автоматически Вы также можете настроить напряжения вручную DRAM Voltages control Auto Эти параметры позволяют вам задать напряжения связанные с памятью При установке в Auto BIOS установит напряжения автоматически Вы также можете настроить напряжения вручную Memory Changed Detect Enabled Включение или выключение предупреждающих сообщений при загрузке системы когда память были заменены Enabled Система выдает предупреждение во время загрузки Требуется загрузить настройки по умолчанию для новых устройств Disabled Выключение этой функции и сохранение текущих настроек BIOS CPU Speci cations sub menu Нажмите Enter для входа в подменю В этом подменю представлена информация об установленном процессоре Для просмотра этой информации в любое время нажмите на кнопку F4 Это значение нельзя изменять MEMORY Z sub menu Нажмите Enter для входа в подменю В подменю выделены все параметры и тайминги установленной памяти Для просмотра этой информации в любое время нажмите на кнопку F5

Memory failure retry что это

• В этой теме выбираем материнскую плату для компьютера и обсуждаем сопутствующие вопросы. Остальные компоненты в соответствующих темах
• Если компьютер собираете для игр, обсуждение необходимо вести в теме Сборка Игрового ПК
• Если компьютер собираете для работы, обсуждение необходимо вести в теме Сборка не игрового ПК / Компьютер для работы
• Если нужно собрать максимально дешевый компьютер, то обсуждение в теме Сборка супербюджетного ПК
• Вопросы по улучшению существующего компьютера в теме Апгрейд / Улучшение вашего ПК
• Обсуждение в каком конкретно магазине купить компоненты для компьютера осуществляем в теме Где купить запчасти для ПК и прочей техники, нюансы покупки в зарубежных магазинах обсуждаются тут: Клуб любителей зарубежного шоппинга, вопросы гарантийного обслуживания и прочие юридические моменты тут: Сервисное обслуживание, обмен и возврат ПК и иной техники
  — тут решаем возникшие неполадки с «железом» ПК

• Модель процессора
• Модель оперативной памяти, количество планок
• Модель корпуса
• Необходимый функционал (количество портов USB, наличие определенных интерфейсов, возможность разгона и т.д)
• Бюджет, магазин, город

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

Сообщение отредактировал ninja88 — 09.09.21, 21:19

Материнская плата ASUS

Батарейка на материнской плате быстро садится. Родная работала 2 года, потом за последние 4 месяца заменял 2 раза. С начало время на часах сбивается на час назад, потом чуть больше, доходит до

Как вариант, может помочь обновление Биос.

• В этой теме выбираем материнскую плату для компьютера и обсуждаем сопутствующие вопросы. Остальные компоненты в соответствующих темах
• Если компьютер собираете для игр, обсуждение необходимо вести в теме Сборка Игрового ПК
• Если компьютер собираете для работы, обсуждение необходимо вести в теме Сборка не игрового ПК / Компьютер для работы
• Если нужно собрать максимально дешевый компьютер, то обсуждение в теме Сборка супербюджетного ПК
• Вопросы по улучшению существующего компьютера в теме Апгрейд / Улучшение вашего ПК
• Обсуждение в каком конкретно магазине купить компоненты для компьютера осуществляем в теме Где купить запчасти для ПК и прочей техники.
  — тут решаем возникшие неполадки с «железом» ПК

• Модель процессора
• Модель оперативной памяти, количество планок
• Модель корпуса
• Необходимый функционал (количество портов USB, наличие определенных интерфейсов, возможность разгона и т.д)
• Бюджет, магазин, город

Сообщение отредактировал WSonic — 02.12.17, 11:10

Прошу помощи, подсказки, мать: asus z97-pro wifi ac

не везёт с ней как утопленнику, дважды слетал биос, (v.02.01)
теперь отвалилась звуковая на плате,
собрался поставить встраиваемую PCI-Express,
драйвера встали, в диспетчере устройств видно,
при загрузке компа, комп СРАЗУ УХОДИТ В БИОС,
(выдергиваю карту- НОРМАЛЬНАЯ ЗАГРУЗКА ВИНДЫ),

ПОЧИТАЛ НА РАЗНЫХ ФОРУМАХ, НАПИСАНО: отключите в биосе внутреннюю звуковую карту,
включите встраиваемую PCI-Express.

Memory management в Windows 10 (и синий экран). Как можно попытаться исправить проблему

Здравствуйте!

Можно ли самому себе (со скуки) быстро «насоздавать» лишних проблем с ПК. 👀 Легко! Один мой знакомый в попытках ускорить систему, почти «убил» ее стабильность — начала появляться ошибка со стоп-кодом «Memory management» при попытке включить ПК и загрузить ОС Windows (пример на фото ниже 👇).

Собственно, мне пришлось ему немного помочь (само собой, так и появилась эта заметка).

Вообще, этот стоп-код переводится на русский как «Управление памятью» (но не всегда проблема напрямую связана с ОЗУ). Как бы там ни было, здесь (ниже) я приведу несколько рекомендаций, которые в ряде случаев (не всегда!) помогают устранить сию проблему.

Синий экрана со стоп-кодом Memory management // фото с проблемного ПК

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

ШАГ 1

Для начала 👉 обратите внимание после чего стала появляться эта ошибка, не подключали ли вы накануне новое оборудование, не устанавливали ли драйвера, программы и т.д. и т.п.?

Совет банален : отключите это новое оборудование (удалите программу, установленную накануне). Установите «старый» драйвер, при котором система работала стабильно.

Кроме этого , можно попробовать откатить систему 👉 к точке восстановления (на ту дату, когда Windows «вела» себя стабильно). Для этого нужно нажать на WIN+R, и использовать команду rstrui.

Выбор точки для отката системы

ШАГ 2

Далее посоветовал бы 👉 проверить плашки ОЗУ ( прим. : оперативную память). Причем, желательно перед этим выключить ПК и вынуть все плашки из слотов, кроме одной из них (и именно с ней провести тест). Затем, подобный тест провести с другой плашкой (возможно, что есть неисправность конкретно с одной из них).

Как провести тест :

1. нажать сочетание Win+R, чтобы появилось окно «выполнить» ;
2. ввести команду mdsched и нажать Enter. Должно появиться окно, с предложением провести тест ОЗУ. Пример ниже. 👇

👉 В помощь!

Тест ОЗУ (RAM): проверка оперативной памяти на ошибки — см. пошаговую инструкцию

Средство проверки памяти Windows

После перезагрузки ПК — запустится проверка памяти. Основное, куда нужно смотреть — вкладка «Состояние» : если с памятью все в порядке — должен быть статус «Неполадки пока не обнаружены» .

Пример проверки плашки

ШАГ 3

Этот шаг больше актуален для ПК, где в BIOS можно задавать соотв. настройки.

Далее я бы посоветовал приглядеться 👉 к частоте, на которой работает память (2400 / 2666 / 3200 Mhz и пр.). В Windows 10, кстати, частоту (на которой работает память) можно посмотреть в диспетчере задач (Ctrl+Alt+Del). 👇

Диспетчер задач — память

Некоторые плашки при загрузке XMP профиля (это задается в BIOS) , скажем для поднятия с 2400 Mhz до 3200 Mhz — начинают вести себя нестабильно: время от времени из-за этого вылетают «синие экраны» с перезагрузкой ПК. (чаще всего такое наблюдал на плашках от AMD и китайских «no-name»)

Я бы вообще, порекомендовал 👉 зайти в BIOS и 👉 сбросить настройки в оптимальные (после ничего не менять, кроме раздела BOOT, если того требует загрузка ОС).

ASRock UEFI — загружаем XMP профиль

👉 Важно!

В некоторых случаях (это редко, но бывает) возможно есть проблема «несовместимости»* ОЗУ и мат. платы (*официально совместимы, но на практике постоянно сбои. ).

Например, сталкивался с этим у производителей мат. плат AsRock и определенных плашек ОЗУ от AMD: в отдельности друг от друга работают вполне стабильно, но «вместе» — ошибки.

Мотив : по возможности, попробуйте заменить все свои плашки памяти на одну от другого производителя. Будет ли появл. синий экран.

ШАГ 4

В Windows 8/10 драйверы для большинства оборудования 👉 устанавливаются автоматически (с одной стороны — это хорошо; но с другой — часто драйвера ставятся не самые «подходящие». В результате получаем ошибки и «вылеты» синих экранов).

Что я бы посоветовал:

1. загрузить драйверы с офиц. сайта (особенно это касается драйверов для видеокарты, мат. платы, чипсета, звуковой карты, сетевых адаптеров. Точные модели ваших «железок» можно узнать в AIDA, например). Если у вас ноутбук — скачивайте с сайта производителя ноутбука (т.е. с сайта ASUS, Lenovo и пр., а не AMD, nVidia. );
2. затем отключите компьютер от интернета и произведите установку «родных драйверов»;
3. после, отключите в Windows авто-обновление драйверов. О том, как это сделать — 👉 см. в этой заметке;
4. подключите снова компьютер к интернету и проверьте работу. Будут ли снова сыпаться ошибки со стоп-кодом Memory management.

Кстати, как вариант, можно воспользоваться спец. утилитами для поиска и обновления драйверов. Например, 👉 Driver Booster, помимо всего прочего, может помочь найти и установить недостающие пакеты Net FrameWork, Visual C++ и пр.

Driver Booster — найдено 4 устаревших драйвера, и 1 игровой компонент // пример работы программы

ШАГ 5

Следующее, что посоветовал бы — это проверить работу ПК 👉 с помощью LiveCD-флешки. Это позволит нам хотя бы понять, не связана ли проблема с текущей ОС (с ее системными ошибками, сбоями, конфликтами драйверов и пр.).

Кроме этого, на LiveCD-флешке есть программа OCCT (на том LiveCD, который порекомендовал я). И с помощью нее можно запустить довольно «жесткий тест», который поможет 👉 проверить стабильность работы БП, ЦП, видеокарты и пр.

OCCT (программа для тестирования ПК) — вкладка с напряжениями

Если, загрузившись с LiveCD, синие экраны «пропали» и компьютер работает стабильно, на мой взгляд можно попробовать:

1. установить новую ОС Windows в свободное место жесткого диска (👉 это можно сделать без удаления данных и текущей копии ОС). Причем, я бы посоветовал взять версию 👉 Windows LTSC (она без Store, Edge, Cortana, OneDrive и пр.);
2. попробовать произвести загрузку «проблемной» Windows без «сторонних» служб. Чтобы это сделать : нажмите Win+R, и используйте команду msconfig. Далее в списке служб отключите все, кроме служб от Microsoft. См. скриншот ниже. 👇

Конфигурация системы — отключение служб

ШАГ 6

Если всё вышеприведенное не дало результатов — могу лишь порекомендовать ко всему прочему выполнить общие рекомендации при появлении синего экрана . Их я приводил в одной своей инструкции (ссылочка ниже).

👉 В помощь!

Синий экран в Windows 10: «На вашем ПК возникла проблема. » (а за ним перезагрузка компьютера).

PS

Всё же (я настаиваю 😉) в первую очередь при появл. стоп-кода Memory management — нужно перепроверять ОЗУ (в т.ч. с заменой плашек), драйвера (на мат. плату, чипсет, видеокарту, сетевые карты), настройки и версию BIOS (возможно стоит произвести обновление). В подавляющем большинстве случаев — причина в «этом». ☝

Решение проблем неправильного использования памяти в Node.js

Недавно в компании Reside Real Estate столкнулись с проблемами: в самые ответственные моменты начал падать Node.js-сервер. Подозрение пало на память. Сотрудники компании прибегли к временным мерам, что позволило избавить от неудобств пользователей, и занялись поисками источника проблем. В результате им удалось найти и устранить неполадки.

Типы проблем с памятью

▍ Утечка памяти

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

В низкоуровневых языках вроде C утечки памяти часто возникают в ситуации, когда память выделяют, например так: buffer = malloc(num_items*sizeof(double)); , но не освобождают после того, как память больше не нужна: free(buffer); .

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

▍ Чрезмерное использование памяти

В ситуации чрезмерного использования памяти программа занимает гораздо больше памяти, чем ей нужно для решения возложенной на неё задачи. Например, такое может возникнуть тогда, когда ссылки на большие объекты хранят дольше, чем нужно для правильной работы программы, что предотвращает уничтожение этих объектов сборщиком мусора. Подобное случается и тогда, когда в памяти держат большие объекты, которые попросту не нужны программе (это вызывает одну из двух основных проблем, которые мы рассмотрим ниже).

Выявление проблем с памятью

Наши проблемы с памятью проявляли себя вполне очевидным образом, в основном — в виде этого мрачного сообщения из журнала:

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

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

Временное решение проблемы

Часто, когда что-то случилось, нет времени на то, чтобы понять суть проблемы и всё исправить. У нас его точно не было. К счастью, есть способы увеличения объёма памяти, выделенной процессу Node. У движка V8 имеется стандартное ограничение памяти равное примерно 1.5 Гб на 64-битных компьютерах. Даже если вы запускаете процесс Node на компьютере, имеющем гораздо больше RAM, это роли не играет, если только вы не увеличите этот лимит. Для того, чтобы увеличить лимит, можно передать процессу Node ключ max_old_space_size . Выглядит это так:

Параметр $SIZE задаётся в мегабайтах и, теоретически, может быть любым числом, которое имеет смысл на конкретном компьютере. В нашем случае был использован параметр 8000, который, с учётом особенностей работы сервера, позволил выиграть достаточно времени на исследования. Кроме того, мы увеличили динамическую память. Мы пользуемся Heroku, там это делается просто.

Также мы воспользовались сервисом Twilio, настроили его так, чтобы нас оповещали каждый раз, когда на сервер приходит запрос, требующий особенно много памяти. Это позволило нам наблюдать за запросом и перезапускать сервер после его завершения. Такое решение неидеально, но для того, чтобы наши пользователи не сталкивались с отказами, мы были готовы на всё, даже на круглосуточные дежурства без выходных.

Отладка

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

▍ Снепшот кучи

«Утечка памяти» — это проблема, которая выражается в постоянно растущем размере кучи. В результате куча оказывается слишком большой для продолжения нормальной работы сервера. Поэтому в самом начале исследования нужно сделать несколько снепшотов (снимков состояния) кучи, с некоторым интервалом, и погрузиться в исследование этих снепшотов с использованием инструментов разработчика Chrome для того, чтобы понять, почему куча так велика и почему она растёт. Обратите внимание на то, что следует делать несколько снепшотов, через некоторое время, в результате можно будет изучить объекты, которые будут переходить из одного снепшота в другой. Эти объекты, вполне возможно, являются виновниками утечки памяти. Существует множество способов создать снепшот кучи.

▍ Использование heapdump для создания снепшотов кучи

Мы, для создания снимков кучи, пользовались heapdump. Этот npm-пакет оказался весьма полезным. Его можно импортировать в код и обращаться к нему в тех местах программы, где нужно делать снепшоты. Например, мы делали снепшот каждый раз, когда сервер получал запрос, который мог вызвать процесс, интенсивно использующий память. Тут же мы формировали имя файла, содержащее текущее время. Таким образом мы могли воспроизводить проблему, отправляя на сервер всё новые и новые запросы. Вот как это выглядит в коде:

▍ Использование удалённого отладчика Chrome для создания снепшотов кучи

Если вы работаете с Node 6.3. или с более поздней его версией, для создания снепшотов кучи можно использовать удалённый отладчик Chrome. Для того, чтобы это сделать, сначала запустите Node командой такого вида: node —inspect server.j s. Затем перейдите по адресу chrome://inspect . Теперь вы сможете удалённо отлаживать процессы Node. Чтобы сэкономить время, можете установить этот плагин Chrome, который автоматически откроет вкладку отладчика при запуске Node с флагом —inspect . После этого просто делайте снепшоты тогда, когда сочтёте это необходимым.

Средства удалённой отладки Chrome и создание снепшотов кучи

Загрузка снепшотов и определение типа проблемы с памятью

Следующий шаг заключается в загрузке снепшотов на закладке Memory (память) инструментов разработчика Chrome. Если вы использовали для создания снепшотов кучи удалённый отладчик Chrome, то они уже будут загружены. Если вы использовали heapdump, то вам понадобится загрузить их самостоятельно. Обязательно загружайте их в правильном порядке, а именно — в том, в котором они были сделаны.

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

Наша первая проблема с памятью выглядела, на закладке Memory инструментов разработчика Chrome, так, как показано ниже. Несложно заметить, что куча постоянно растёт. Это говорит об утечке памяти.

Куча увеличивается со временем — очевидная утечка памяти

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

Куча со временем не растёт — это не утечка памяти

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

Для выявления подобных проблем мы рекомендуем два способа, которые помогли нам обнаружить виновников проблемы — функцию и переменную. Это — запись профиля выделения памяти и создание снепшотов на сервере, находящемся под серьёзной нагрузкой.

Если вы используете версию Node 6.3 или более позднюю, вы можете записать профиль выделения памяти через удалённый отладчик Chrome, запустив Node с уже упоминавшимся ключом —inspect . Это даст сведения о том, как отдельные функции используют память с течением времени.

Запись профиля выделения памяти

Ещё один вариант заключается в отправке множества одновременных запросов к вашему серверу и в создании множества снепшотов во время обработки этих запросов (предполагается, что сервер работает асинхронно, как результат, некоторые снепшоты могут оказаться гораздо больше других, что укажет на проблему). Мы бомбардировали сервер запросами и делали снепшоты. Некоторые из них оказались очень большими. Исследованием этих снепшотов можно заняться для выявления источника проблемы.

Анализ снепшотов

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

Исследование утечки памяти — все функции указывают на наш сервис электронной почты

Показатель Retained Size — это размер памяти, освобождённой после того, как объект удалён вместе со своими зависимыми объектами, которые недостижимы из корневого объекта.

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

Так как мы были уверены в том, что перед нами утечка памяти, мы знали, что исследование стоит начать с поиска переменных с неподходящей областью видимости. Мы открыли файл index.js почтовой службы и тут же обнаружили переменную уровня модуля в верхней части файла.

Мы со всем этим разобрались, внесли необходимые изменения, протестировали проект ещё несколько раз и исправили в итоге утечку памяти.

Вторую проблему отлаживать было сложнее, но тут сработал тот же подход. Ниже показан профиль выделения памяти, который мы записали с использованием инструментов разработчика Chrome и ключа Node —inspect .

Поиск виновников чрезмерного использования памяти

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

Профиль выделения памяти привёл нас к одной из функций, recordFromSnapshot , она стала хорошей отправной точкой. Наше исследование снепшота кучи, которое не особенно отличалось от исследования, выполняемого при поиске утечки памяти, позволило обнаружить очень большой объект target . Это была переменная, объявленная внутри функции recordFromSnapshot . Эта переменная осталась от старой версии приложения, она была больше не нужна. Избавившись от неё, мы исправили ситуацию с чрезмерным использованием памяти и ускорили выполнение процесса, которое раньше занимало 40 секунд, до примерно 10 секунд. При этом процессу не требовалась дополнительная память.

Итоги

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