Метрика загруженности процессора (CPU utiliztion) — это не то что вы думаете
Всем привет. Предлагаю вашему вниманию свой перевод поста «CPU Utilization is Wrong» из блога Брендана Грегга.
Как вы думаете, что значит нагрузка на процессор 90% на картинке ниже?
Вот что это значит на самом деле:
Stalled, то есть «приостановлено» значит, что в данный момент процессор не обрабатывает инструкции, обычно это означает, что он ожидает завершения операций ввода/вывода связанных с памятью (здесь и далее речь о RAM, а не дисковом вводе/выводе). Соотношение между «занято» и «приостановлено» (busy/stalled), которое я привел выше, это то что я обычно вижу в продакшене. Вероятно, что ваш процессор тоже большую часть времени находится в stalled состоянии, но вы об этом и не догадываетесь.
Что это значит для вас? Понимание того насколько много ваш процессор находится в приостановленном состоянии может помочь вам понять куда направить усилия по оптимизации производительности приложения: на ускорение кода или уменьшение числа операций ввода/вывода связанных с памятью. Всем кто заинтересован в оптимизации нагрузки на процессор, в особенности в облаках с настроенным автомасштабированием на основе нагрузки на CPU, будет полезно знать насколько долго процессор находится в приостановленном состоянии.
Что такое нагрузка на процессор на самом деле?
Метрика, которую мы называем нагрузкой на процессор (CPU utilization) на самом деле это «не-idle время», то есть время, которое процессор не выполняет idle-тред. Ядро вашей операционной системы (какую бы ОС вы не использовали) обычно следит за этим во время переключения контекста. Если не-idle тред запустился, а затем спустя 100 милисекунд остановился, то ядро посчитает, что процессор был использован в течение всего этого времени.
Эта метрика так же стара как и системы совместного использования времени (time sharing systems). В бортовом компьютере лунного модуля Apollo (это пионер среди систем совместного использования времени) idle-тред назывался «DUMMY JOB» и инженеры мониторили циклы выполняющие его в сравнении с реальными задачами, это было важной метрикой измерения нагрузки. (Я писал об этом ранее).
Что же с этой метрикой не так?
Со временем все становится только хуже. Долгое время производители процессоров увеличивали тактовые частоты своих процессоров быстрее чем производители памяти уменьшали задержки доступа к памяти (CPU DRAM gap). Примерно в 2005 году процессоры достигли частот в 3 GHz и с тех пор мощность процессоров растет не за счет увеличения тактовой частоты, а за счет большего числа ядер, гипертрединга и многопроцессорных конфигураций. Все это предъявляет еще больше требований к памяти. Производители процессоров пытались снизить задержки связанные с памятью за счет больших по размеру и более умных CPU-кешей, более быстрых шин и соединений. Но проблема со stalled-состоянием все еще не решена.
Как понять, что процессор на самом деле делает
Сделать это можно используя Performance Monitoring Counters (PMC-счетчики): хардверные счетчики, которые могут быть прочитаны с помощью Linux pref (пакет linux-tools-generic в Линуксе) и других утилит. Для примера понаблюдаем за всей системой в течение 10 секунд:
Ключевая метрика здесь instructions per cycle (insns per cycle: IPC, число инструкций за один цикл), которая показывает сколько в среднем инструкций было выполнено за каждый такт. Чем больше, тем лучше. В примере выше значение 0.78 кажется очень неплохим (нагрузка 78%?) до тех пор пока вы не узнаете, что максимальная скорость процессора это IPC 4.0. Такие процессоры называют 4-wide, это название пошло от особенностей пути извлечения/декодирования инструкций в процессоре (подробнее об этом в Википедии).
Существуют сотни PMC-счетчиков, которые позволяют детальнее разобраться с производительностью системы, например, посчитать число приостановленных циклов по типам.
В облаках
Если вы работаете в виртуальном окружении, то вероятно у вас нет доступа к PMC-счетчикам, это зависит от поддержки этой фичи гипервизором. Я недавно писал о том, что PMC-счетчики теперь доступны в AWS EC2 в виртуальных машинах базирующихся на Xen.
Как интерпретировать и что делать
Если ваш IPC 1.0, то вероятно, вы ограничены числом инструкций, которые может выполнять процессор. Попробуйте найти способ уменьшить число выполняемых инструкций: уменьшить число ненужной работы, кешировать операции и т.п. CPU flame графы — отличная утилита для этих целей. С точки зрения тюнинга железа, попробуйте использовать процессор с большей тактовой частотой и большим числом ядер и гипертредов.
Для моих правил выше я выбрал значение IPC 1.0, почему именно его? Я пришел к нему из своего опыта работы с PMC-счетчиками. Вы можете выбрать для себя другое значение. Сделайте два тестовых приложения, одно упирающееся по производительности в процессор, другое — в память. Посчитайте IPC для них и возьмите среднее значение.
Что инструменты мониторинга производительности должны сообщать вам?
Другие причины почему CPU utilization вводит в заблуждение
Проблема со stalled-циклами может быть не только в задержках связанных с памятью:
— изменение температуры может влиять на приостановленность процессора,
— турбобуст может менять тактовую частоту процессора,
— ядро варьирует частоту процессора с определенным шагом,
— проблема с усреднением: 80% нагрузки в течение минуты скроет кратковременный всплеск до 100%,
— спинлоки: процессор нагружен, имеет высокий IPC, но приложение ничего не делает.
Заключение
Нагрузка на процессор (CPU utilization) это обычно неправильно интерпретируемая метрика, так как она включает циклы, потраченные на ожидание ответа от основной памяти, которые могут доминировать в современных нагрузках. Вы можете понять что на самом деле стоит за %CPU используя дополнительные метрики, включая число инструкций за цикл (IPC). Если IPC 1.0, то в скорость процессора. Я писал про IPC в своем предыдущем посте, в том числе написал и о использовании PMC-счетчиках, необходимых для измерения IPC.
Инструменты мониторинга производительности, которые показывают %CPU должны показывать PMC-счетчики, чтобы не вводить пользователей в заблуждение. Например, они могут показывать %CPU с IPC и/или число instruction-retired и stalled циклов. Вооруженные этими метриками разработчики и админы могут решить как правильнее тюнинговать их приложения и системы.
Уменьшаю нагрев своей видеокарты и продляю ее ресурс путем модификации BIOS-a
Недавно достал с полки свою старенькую видеокарту GIGABYTE R9 280X 3Gb. Хорошо, что я не успел ее продать до повышения цен, да и вообще не успел ее продать. А то пришлось бы сейчас покупать, какую ни будь видеокарту по безумно высокой цене. Теперь она пригодилась самому для установки в компьютер. Так сказать, новое это хорошо забытое старое, вот и для меня она теперь в каком-то роде стала новой. Думаю, что еще у многих есть такие видеокарты.
реклама
Так вот, имеется в наличии видеокарта GIGABYTE R9 280X 3Gb, та еще «горячая штучка», нужно сказать. При больших нагрузках GPU нагревается до 90 градусов. Производитель для этой модели видеокарт декларирует такую температуру, как нормальную. Но, тем не менее, я хочу уменьшить температуру настолько, насколько это возможно, с сохранением ее устойчивой работы, при помощи модификации BIOS-a. А именно, в BIOS-е буду уменьшать напряжение питания GPU до ее неустойчивой работы, и на один шаг верну напряжение питания в сторону его увеличения. Проверку устойчивости работы видеокарты в режиме большой нагрузки GPU буду проводить с помощью программы «FurMark» (волосатый бублик). Ну и сразу скажу, что перед проведением модификации BIOS-a термопасту на GPU я уже заранее заменил, и систему охлаждения продул. На целесообразность этой затеи и ожидание хорошего результата меня натолкнула та мысль, что производитель устанавливает напряжение питания GPU с запасом, причем с таким, чтобы гарантированно обеспечивалась стабильная работа видеокарт даже с установкой в них GPU из неудачных партий (которые требуют для стабильной работы повышенного напряжения питания). Ну а если в видеокарту попадают «удачные» GPU, способные стабильно работать при более низком напряжении питания, то производитель не подбирает к ним индивидуальные напряжения, а использует то же напряжение, что и для видеокарт с «неудачными» GPU. Поэтому, если мне повезет, и в моей видеокарте окажется установлен «удачный» GPU, то я смогу значительно (я так надеюсь) снизить его напряжение питания, сохраняя при этом стабильную работу. Тем самым уменьшу тепловыделение и соответственно его температуру, и продлю ресурс его работы.
Перед началом работ нужно сохранить оригинальный BIOS, для его дальнейшей модификации. Для этого воспользуюсь программой «GPU-Z». Открываю ее, нажимаю кнопку со стрелочкой, указываю путь сохранения и сохраняю.
реклама
реклама
реклама
После окончания прошивки, прошивальщик просит перезагрузить компьютер. Соглашаюсь.
Теперь сравниваю температуру в «FurMark» при работе видеокарты со старым, родным BIOS-ом, и модифицированным.
Температура со старым, родным BIOS-ом составила 94 градуса, при скорости вращения вентиляторов системы охлаждения 100%.
Температура с модифицированным BIOS-ом составила 73 градуса, при скорости вращения вентиляторов системы охлаждения 83%.
Отсюда делаю вывод, что снижение напряжения питания GPU на 150 мВ, или 0.150 В. Привело к снижению температуры GPU на 21 градус, и снижению скорости вращения вентиляторов со 100% до 83%. Что, считаю очень хорошим результатом. И да, с GPU мне действительно очень повезло, он оказался очень даже «удачным».
Еще большой плюс этой видеокарты состоит в том, что она имеет два BIOS-а, и если вы прошили нерабочий BIOS, и видеокарта не запустилась, то выключаете компьютер, переключаетесь на резервный BIOS, загружаетесь с него. После этого при включенном компьютере переключаете на видеокарте переключатель на нерабочий BIOS, и перепрошиваете его.
Анализ ключевых показателей производительности — часть 3, последняя, про системные и сервисные метрики
Мы заканчиваем публикацию перевода по тестированию и анализу производительности от команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод спасибо Игорю Щегловитову из Лаборатории Касперского. Остальные наши статьи по теме тестирования можно найти по тегу mstesting
В первой статье цикла по анализу ключевых показателей производительности мы наладили контекст, теперь переходим к конкретным вещам. Во второй посмотрели на анализ пользовательских, бизнесовых показателей/метрик и показателей, необходимых к анализу внутри приложения. В этой, заключительной — про системные и сервисные (в т.ч. зависимых сервисов) метрики.
Итак,
Системные метрики.
Системные метрики позволяют определять, какие системные ресурсы используются и где могут возникать конфликты ресурсов. Эти метрики направлена на отслеживание ресурсов уровня машины, таких как память, сеть, процессор и утилизация диска. Эти метрики могут дать представление о внутренних конфликтах лежащих в основе компьютера.
Вы также можете отслеживать данные метрики для определения аспектов производительности – нужно понимать, если ли зависимость между системными показателями и нагрузкой на приложение. Возможно, вам потребуются дополнительные аппаратные ресурсы (виртуальные или реальные). Если при постоянной нагрузке происходит увеличение значений данных метрик, то это может быть обусловлено внешними факторами — фоновыми задачами, регулярно-выполняющимися заданиями, сетевой активностью или I/O устройства.
Как собирать
Вы можете использовать Azure Diagnostics для сбора данных диагностики для для отладки и устранения неполадок, измерения производительности, мониторинга использования ресурсов, анализа трафика, планирования необходимых ресурсов и аудита. После сбора диагностики ее можно перенести в Microsoft Azure Storage для дальнейшей обработки.
Другой способ для сбора и анализа диагностических данных — это использование PerfView. Этот инструмент позволяет исследовать следующие аспекты:
Изначально PerfView был предназначен для локального запуска, но теперь он может быть использован для сбора данных из Web и Worker ролей облачных сервисов Azure. Вы можете использовать NuGet-пакет AzureRemotePerfView для установки и запуска PerfView удаленно на серверах ролей, после чего скачать и проанализировать полученные данные локально.
Windows Azure Diagnostics и PerfView полезны для анализа используемых ресурсов “постфактум”. Однако, при применении таких практик как DevOps, необходимо мониторить “живые” данные производительности для обнаружения возможных проблем производительности еще до того, как они произойдут. APM-инструменты могут предоставлять такую информацию. Например, утилиты Troubleshooting tools для веб-приложений на портале Azure могут отображать различные графики, показывающие память, процессор и утилизацию сети.
На портале Azure есть “health dashboard”, показывающий общие системные метрики.
Аналогичным образом, панель Diagnostic позволяет отслеживать заранее настроенный набор наиболее часто используемых счетчиков производительности. Здесь вы можете определить специальные правила, при выполнении которых оператор будет получать специальные нотификации, например, когда значение счетчика сильно превысит определенное значение.
Веб-портал Azure может отображать данные о производительности в течении 7 дней. Если вам нужен доступ данных за более длительный период, то данные о производительности нужно выгружать напрямую в Azure Storage.
Websites Process Explorer позволяет вам просматривать детали отдельных процессов запущенных на веб-сайте, а также отслеживать корреляции между использованием различных системных ресурсов.
New Relic и многие другие APM имеют схожие функции. Ниже приведено несколько примеров.
Мониторинг системных ресурсов делится на категории, которые охватывают утилизацию памяти (физической и управляемой), пропускную способность сети, работу процессора и операции дискового ввода вывода (I/O). В следующих разделах описано, на что следует обратить внимание.
Использование физической памяти
Существует две основные причины ошибки OutOfMemory – процесс превышает выделенное для него пространство виртуальной памяти либо операционная система оказывается неспособной выделить дополнительную физическую память для процесса. Второй случай является самым распространенным.
Вы можете использовать описанные ниже счетчики производительности для оценки нагрузки на память:
Также следует учитывать, что большие объемы памяти могут привести к фрагментации (когда свободной физической памяти в соседних блоках недостаточно), поэтому система, которая показывает, что имеет достаточно свободной памяти, может оказаться не в состоянии выделить эту память для конкретного процесса.
Многие APM-инструменты предоставляют сведения об использовании процессами системной памяти без необходимости глубокого понимания о принципах работы памяти. На графике ниже показана пропускная способность (левая ось) и время отклика (правая ось) для приложения, находящегося под постоянной нагрузкой. Примерно после 6 минут производительность внезапно падает, и время отклика начинает “прыгать”, по прошествии нескольких минут происходит показателей.
Результаты нагрузочного тестирования приложения
Записанная с помощью New Relic телеметрия показывает избыточное выделение памяти, которое вызывает сбой операций с последующим восстановлением. Использованная память растет за счет файла подкачки. Такое поведение является классическим симптомом утечки памяти.
Телеметрия, показывающая избыточное выделение памяти
Примечание: В статье Investigating Memory Leaks in Azure Web Sites with Visual Studio 2013 содержится инструкция, показывающая как использовать Visual Studio и Azure Diagnostics для мониторинга использования памяти в веб-приложении в Azure.
Использование управляемой памяти
.NET приложения используют управляемую память, которая контролируется CLR (Common Language Runtime). Среда CLR проецирует управляемую память на физическую. Приложения запрашивают у CLR управляемую память, и CLR отвечает за выделение требуемой и освобождение неиспользуемой памяти. Перемещая структуры данных по блокам, CLR обеспечивает компоновку этого типа памяти, уменьшая тем самым фрагментацию.
Управляемые приложения имеют дополнительный набор счетчиков производительности. В статье Investigating Memory Issues содержится детальное описание ключевых счетчиков. Ниже описаны наиболее важные счетчики производительности:
Планирование GPU с аппаратным ускорением в Windows 10 действительно повышает производительность в играх
Функция «Планирование графического процессора с аппаратным ускорением» предназначена для улучшения планирования GPU и, как следствие, повышения производительности при запуске приложений и игр, использующих графический процессор.
Новая функция имеет некоторые ограничения: она доступна только в Windows 10 версии 2004 или выше, требует наличия современного графического процессора и драйверов, поддерживающих эту функцию. Опция становится доступной, только если система отвечает всем этим требованиям.
Как включить Планирование GPU с аппаратным ускорением
Вы можете проверить доступность функции планирования GPU на вашем устройстве следующим способом:
Microsoft рассказала о механизме работы новой функции планирования GPU в блоге Microsoft Dev. Компания объясняет, что эта функция «является существенным и фундаментальным изменением модели драйверов, и сравнивала нововведение с «перестройкой фундамента дома, в котором вы живете».
Компания собирается отслеживать производительность функции и продолжит работу над ней.
Пользователи Windows 10, особенно любители компьютерных игр, интересуются, стоит ли включать эту функцию уже сейчас или лучше ее активировать позже.
Тесты проводились в Doom Eternal, Read Dead Redemption 2 и Star Wars Jedi Fallen Order, с включенной и отключенной функцией планирования графического процессора с аппаратным ускорением.
Основной вывод тестирования: Планирование GPU с аппаратным ускорением действительно повышает производительность во всех случаях. В среднем, тестеры заметили увеличение на 1-2 кадра в секунду при запуске игры в разрешении 2560×1440 пикселей.
Неизвестно, будет ли улучшение производительности более скромным с менее мощным оборудованием, но Nvidia предполагает, что это может быть именно так.
Тем не менее, для геймеров имеет смысл включить планирование GPU при условии, что на машинах, на которых эта функция активирована, не наблюдается падение производительности.
Какая видеокарта установлена на вашем компьютере?
Оптимизация потребления видеокарт Nvidia при майнинге
Видеокарты Nvidia GTX 1050, 1060, 1070 и 1080, а также новые модели серии RTX отличаются простотой настройки майнинга, стабильностью работы и хорошим хешрейтом.
Для достижения более высокой рентабельности майнинга криптовалют за счет уменьшения потребления электричества, а также снижения износа видеокарт от перегрева и работы кулеров на повышенных оборотах, желательно осуществлять даунвольтинг (снижение вольтажа) ядра GPU.
Это особенно важно при майнинге на алгоритме Ethash (используется у эфира, эфира классик, UBIQ, Metaverse, Expanse и многих других монет).
Как уменьшить энергопотребление видеокарт Nvidia при майнинге
При настройке видеокарт нужно понимать, что каждые сто мегагерц частоты на ядре видеокарты при майнинге на алгоритме Ethash дают прирост/снижение хешрейта на уровне около 0,5 Mh/s. Для хорошей скорости майнинга эфира достаточно иметь частоту ядра GPU на уровне 1100-1200 мегагерц.
Каждая видеокарта имеет индивидуальные возможности по разгону и даунвольтингу. Это зависит от качества кристаллов в ядре GPU и памяти. Для уменьшения потребления на ядре GPU Нвидиа программным способом можно использовать две популярных утилиты:
Наилучшие результаты по снижению энергопотребления дает программа NvidiaInspector, которая позволяет понизить вольтаж ядра ниже 800 милливольт, в то время как MSI Afterburner без дополнительных ухищрений позволяет его снизить только до 800 милливольт. Снижение вольтажа ядра до 0,8 В уменьшает потребление на примерно 20%, а температуру видеокарты на 4-5 градусов при одном и той же скорости кулеров.
Тем не менее иногда нужно применять MSI Afterburner либо одновременно обе программы (для разных видеокарт своя программа), так как некоторые видеокарты (например, P106-100 майнинг эдишн от MSI) не управляются NvidiaInspector.
Некоторые программы майнеры позволяют менять напряжение на ядре непосредственно в командной строке для их запуска. Для использования этих возможностей нужно изучать особенности каждой программы, а вышеуказанные утилиты являются универсальными и могут работать без сбоев и дополнительных настроек с любыми майнерами.
Как оптимизировать энергопотребление с помощью MSI Afterburner
Понизить энергопотребление на видеокартах Nvidia с помощью MSI Afterburner можно двумя способами:
Снижение лимита энергопотребления (Power Limit) видеокарт Nvidia в MSI Afterburner
Это самый простой способ управления энергопотреблением видеокарт Нвидиа, который позволяет достичь неплохих результатов и оптимизировать потребление.
Для снижения потребления нужно уменьшать напряжение на ядре GPU до такого значения, когда еще обеспечивается стабильная работа майнера. Для алгоритмов, не требовательных к частоте ядра (Ethash, который раньше назывался Dagger Hashimoto), для снижения потребления можно сильнее уменьшать частоту ядра (до примерно 1100 МГц), что позволит еще больше снизить энергопотребление.
Для других алгоритмов может потребоваться повышенная частота ядра. Как правило, большинство видеокарт Nvidia могут выдержать увеличение частоты ядра на примерно 150 мегагерц (+150 Mhz), а памяти – до +500 мегагерц и выше (если повезет с чипами памяти).
Скриншот программы MSI Afterburner при downvolting видеокарты P106-100 (MSI GTX1060 6 Gb mining edition) с помощью понижения до 65% лимита по энергопотреблению (достигнуто напряжение на ядре 800 мВ):
После установки параметров разгона ядра и памяти с помощью ползунков частот, для снижения потребления видеокарт при майнинге нужно понизить TDP видеокарт.
Значение 100% Power Limit дает самый большой хешрейт при высоком потреблении, выделении тепла и шума от кулеров. Выставление этого значения в промежутке от 50 до 75% позволяет установить оптимальное напряжение на ядре при незначительном снижении хешрейта. Напряжение на ядре и его частота при этом будет автоматически колебаться для сохранения выставленного значения лимита, что будет отражаться и на хешрейте.
Скриншот Phoenix Miner при майнинге эфира в соло при 65% TDP:
Чтобы обеспечить стабильное напряжение на ядре, используют способ выставления постоянного напряжения и частоты на ядре на кривой (curve) зависимости напряжения и частоты ядра GPU.
Даунвольтинг видеокарт Nvidia с помощью «курвы»
При этом способе выставляют желаемый разгон видеопамяти ползунком в основном окне MSI Afterburner, оставляют 100% Power Limit, перемещают до упора влево частоту ядра (-400Mhz) и нажимают на график в виде трех столбцов в строке частоты ядра (Core Clock):
Появится окно, позволяющее регулировать зависимость частоты и напряжения на ядре видеокарты:
В появившемся окне перетягивают начало графика вольтажа ядра и частоты от значения 800 мВ до значения частоты на пару мегагерц выше максимальных значений графика:
Затем нажимают кнопку применить (Apply) в окне MSI Afterburner:
Стабильно выставленный график зависимости частоты и напряжения на ядре видеокарты Nvidia в программе MSI Afterburner (напряжение на ядре – 800 мВ при частоте ядра 1550 МГц) выглядит следующим образом:
Аналогичным образом можно выставить стабильное значение для любой частоты и напряжения, на которой видеокарта может работать.
Скриншот MSI Afterburner для видеокарты P106-100 со значением курвы 800 мВ при частоте ядра 1544 МГц:
Скриншот MSI Afterburner для видеокарты P106-100
Настройка скорости кулеров в MSI Afterburner
В MSI Afterburner также можно выставить график зависимости скорости кулера от температуры. Для этого нажимают на кнопку шестеренки в MSI Afterburner, выставляют нужную форму графика вращения кулеров в зависимости от температуры, и не забывают активировать кнопку автоматического применения этих значений (кнопка Auto должна стать зеленой).
Скриншот MSI Afterburner при настройке скорости вращения кулеров:
Значения разгона, даунвольтинга и скорости кулеров можно записать в профили разгона, которые будут автоматически загружаться при включении рига (при активации соответствующих пунктов в окне настроек программы):
Управление потреблением видеокарт Nvidia программами Nvidia Inspector и NVIDIA Profile Inspector
Главным преимуществом NvidiaInspector является возможность установки вольтажа GPU Core менее 800 мВ, что значительно уменьшает прожорливость видеокарт.
Обе эти программы требует наличия в операционной системе установленного NET Framework 2 и выше.
Для того, чтобы управлять напряжением ядра видеокарт компании Нвидиа с помощью утилит Нвидиа Инспектор и Нвидиа Профайл инспектор, на нужных GPU желательно отключить другие утилиты управления видеокартами, в том числе MSI Afterburner.
Скриншот NVIDIA Profile Inspector в разделе управления режимом CUDA — P2 State:
Кроме того, для увеличения хешрейта в программе NVIDIA Profile Inspector можно подкорректировать значение power management mode, выставив его в Prefer Maximum Performance. Для экономии электроэнергии это значение можно поставить в optimal или adaptive.
Скриншот NVIDIA Profile Inspector в разделе управления режимом Performance:
Программа Nvidia Inspector позволяет осуществить следующие действия:
Чтобы использовать NvidiaInspector, нужно создать пустой текстовый файл в той же папке, где она установлена. В его текстовой части нужно вставить следующие строки (для рига из 5 видеокарт, считаются от 0 до 4):
«nvidiaInspector.exe» %GPU0% %GPU1% %GPU2% %GPU3% %GPU4%
Затем меняют расширение этого файла в BAT, создают ярлык этого файла и помещают его в папку автозагрузки рига. Обычно это C:\Users\имя пользователя\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.
Для настройки пакетного файла для конкретного майнинг рига в нем устанавливают следующие параметры:
Скриншот окна утилиты Nvidia Inspector, которая управляет напряжением на ядре (Voltage = 650 мВ), частотой памяти и скоростью вентиляторов (для установки нужных значений используется запуск BAT-файла с нужными параметрами):
Скриншот BAT-файла для использования NvidiaInspector для рига с 6-ю видеокартами:
При правильном снижении напряжения на ядре можно значительно снизить потребление видеокарт, сохранив приемлемый хешрейт. Это особенно актуально сейчас, при низком биржевом курсе большинства криптовалют и общем снижении рентабельности майнинга.
При нестабильной работе рига нужно просматривать логи майнера, находить проблемную видеокарту и либо повышать напряжение на ее ядре, либо снижать разгон ядра и видеопамяти. Обычно при сильном разгоне по ядру зависает весь риг, а при переразгоне по памяти – только майнер.
