Включение параметра «Блокировка страниц в памяти» (Windows) Enable the Lock Pages in Memory Option (Windows)

Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions) Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions)

Эта политика Windows определяет, какие учетные записи могут использовать процесс для сохранения данных в физической памяти, чтобы система не отправляла страницы данных в виртуальную память на диске. This Windows policy determines which accounts can use a process to keep data in physical memory, preventing the system from paging the data to virtual memory on disk.

Блокировка страниц в памяти может повысить производительность, если требуется подкачка памяти на диск. Locking pages in memory may boost performance when paging memory to disk is expected.

Для включения этой политики для учетной записи, используемой SQL Server SQL Server , воспользуйтесь средством «Групповая политика Windows» (gpedit.msc). Use the Windows Group Policy tool (gpedit.msc) to enable this policy for the account used by SQL Server SQL Server . Чтобы изменить эту политику, необходимо быть системным администратором. You must be a system administrator to change this policy.

Включение параметра «Блокировка страниц в памяти» To enable the lock pages in memory option

В меню Пуск выберите команду Выполнить. On the Start menu, click Run. В окне Открыть введите gpedit.msc. In the Open box, type gpedit.msc.

В консоли Редактор локальных групповых политик разверните узел Конфигурация компьютера, затем узел Конфигурация Windows. On the Local Group Policy Editor console, expand Computer Configuration, and then expand Windows Settings.

Разверните узлы Настройки безопасностии Локальные политики. Expand Security Settings, and then expand Local Policies.

Выберите папку Назначение прав пользователя . Select the User Rights Assignment folder.

Политики будут показаны на панели подробностей. The policies will be displayed in the details pane.

На этой панели дважды щелкните параметр Блокировка страниц в памяти. In the pane, double-click Lock pages in memory.

В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти щелкните Добавить пользователя или группу. In the Local Security Setting — Lock pages in memory dialog box, click Add User or Group.

В диалоговом окне Выбор пользователей, учетных записей служб или групп выберите учетную запись службы SQL Server. In the Select Users, Service Accounts, or Groups dialog box, select the SQL Server Service account.

Чтобы этот параметр вступил в силу, перезапустите службу SQL Server. Restart the SQL Server Service for this setting to take effect.

Disabled huge pages support if xmrig is launched from subfolder #67

Comments

YetAnotherRussian commented Aug 21, 2017 •

Hi there 🙂 You’ve just released v2.3.0 where you claim message about huge pages support fix.

I’ve just tested this one, and Win10 issue isn’t fixed (I have never reported this one though 🙁 )

System is Win10, G4600 CPU, 16Gb RAM, huge pages enabled.

Xmrig 1.0.1: available, enabled
Xmrig 2.0.1+: unavailable, disabled

Bat file is exactly the same:

xmrig.exe -o mine.aeon-pool.com:3333 —algo=cryptonight-lite —cpu-affinity 14 —print-time=5 —donate-level=3 -t 3 —av=2 -u qwerty -p x

It’s not only message display theme, but the actual hashrate drop. I use msvc compiles, but there’re no changes in gcc ones.

P.S. No issues found under Win7 on machines with similar (G4560 + 16Gb RAM) and other (i5-4570 + 32Gb RAM) config.

The text was updated successfully, but these errors were encountered:

xmrig commented Aug 21, 2017

There is no changes since version 1.0.0.
If all happen on same machine:
unavailable mean you not run miner as administrator, it required to use huge pages.
If you see available, disabled it means it fail to allocate huge pages, reboot should help.
Thank you.

YetAnotherRussian commented Aug 22, 2017 •

Lol, I’ve discovered the issue 🙂 Affect version(s) = 1.0+ That was windows desktop folder. Note that cmd watcher is absent as well.

Take a look at my screen capture.

Note: no malware, no spyware, just .mp4 file.

xmrig commented Aug 22, 2017 •

Please upload video somewhere else, for example attach to comment. To much popups on that site and I don’t know how download file from that site.

Mentioned message is just single line fix beb9af4

it regression since version 0.8, you still need run miner as admin and reboot or sign out required.

YetAnotherRussian commented Aug 22, 2017 •

Sorry, that’s it. Link removed.

I tried 2.3.0 as well, with reboot also, doesn’t help(

Launched 2.3.0 from «root» (C:) folder to avoid any issues, works OK.

xmrig commented Aug 22, 2017

It strange, did you try create directory with only English characters? I tried create directory with Russian characters, all work fine, don’t know how path can affect this feature.
Also you disable UAC? I don’t see UAC prompt. Maybe it can cause this issue.
Thank you.

YetAnotherRussian commented Aug 22, 2017 •

Russian/English folder name does not make sense. Yes, UAC is fully disabled, but I think it’s a «must have» for any rig 😀 It’s disabled through control panel native setting, not through any hacks (incl. registry tweaks or any tweaking software that may uninstall system components etc.). I’m using legit OEM win version, so no «custom builds», hacks or somethin.

No issues with other mining software that uses huge pages though :-/

Unse commented Dec 5, 2017 •

Прошу прощения, для лучшего понимания я буду на русском писать.

Шэф!
У меня примерно такая же беда, решил не открывать новый топик.
Есть 4 пк, в том числе даже с одинаковыми цпу, везде win 10 x64 pro.
На двух пк — свежеустановленная, на других — тоже самое, только установлено на год раньше.
Но все обновлены до одинаковых версий.

На своем старом пк я просто прописал своего пользователя в политиках блокировки страниц и запускаю xmrig БЕЗ прав администратор (вообще батником), при этом UAC включен, но все работает. xmrig пишет: «HUGE PAGES: available, enabled’.
И на втором пк тоже самое. Все перепроверил — без админа, с уаком, юзер в политиках, страницы доступны.

А вот на других двух, где винду только только установил — ну никак. И разные версии пробовал начиная с 2.4.0.
Пользователь ( Все, Пользователь, Пользователи, Администраторы, Гости, короче на самом деле кого я туда только не добавлял) в политиках добавлен.
Но! Если запускать НЕ ОТ администратора — страницы красные, недоступны, неактивированы.
Если от администратора — то доступны и активированы.

Системы хоть и в разное время устанавливалиьс из одного образа, цпу идентичные, памяти везде больше 12 гиг, настройки одинаковые.
Единственное различие между старыми и новыми — на старых я ВРУЧНУЮ прописывал пользователя в политиках блокировки страниц. (Т.к. тогда еще на xmr-stack сидел).
На обоих новых — я просто решил запустить с правами админа xmrig, чтобы он сам прописал пользователя.

Unse commented Dec 5, 2017 •

В общем я нашел ГДЕ проблема, но не знаю кто виноват =)

На обоих новых пк имя пользователя было «user».
Хохмы ради я сделал нового пользователя «tester», удалил всех из политик, по новой, чтоб наверняка, добавил в Блокировку Страниц двух пользователей: «user» и «tester».
Перезагрузился, зашел под «user»ом — страницы не доступны без админских прав.
Вышел, зашел под «tester»ом — страницы ДОСТУПНЫ БЕЗ админских прав.
Но виновата винда или хмринг — не знаю, извините.

upd: виновата скорее все таки винда. Потому что xmr-stack ведет себя аналогично абсолютно. Под «user» без админских прав не пользует страницы, под другим — пользует.

P.S. наверное надо было другую ветку все таки делать. Извиняюсь.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Преимущества и недостатки HugePages

Перевод статьи подготовлен для студентов курса «Администратор Linux».

Ранее я рассказал о том, как проверить и включить использование Hugepages в Linux.
Эта статья будет полезна, только если у вас действительно есть, где использовать Hugepages. Я встречал множество людей, которые обманываются перспективой того, что Hugepages волшебным образом повысят производительность. Тем не менее hugepaging является сложной темой, и при неправильном использовании он способен понизить производительность.

Часть 1: проверяем, что hugepages включены в Linux (оригинал здесь)

Проблема:
Необходимо проверить, включены ли HugePages в вашей системе.

Решение:
Оно довольно простое:

Вы получите что-то вроде этого:

Вы увидите список доступных опций (always, madvise, never), при этом текущая активная опция будет заключена в скобки (по умолчанию madvise).

madvise означает, что transparent hugepages включены только для областей памяти, которые явно запрашивают hugepages с помощью madvise(2).

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

never означает, что transparent hugepages не будут включаться даже при запросе с помощью madvise. Чтобы узнать больше, обратитесь к документации ядра Linux.

Как изменить значение по умолчанию

Вариант 1: Напрямую изменить sysfs (после перезагрузки параметр вернется к значению по умолчанию):

Вариант 2: Измените системное значение по умолчанию, перекомпилировав ядро с измененной конфигурацией (этот вариант рекомендуется только если вы используете собственное ядро):

• Чтобы поставить always по умолчанию, используйте:
• Чтобы поставить madvise по умолчанию, используйте:

Часть 2: Преимущества и недостатки HugePages

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

Обратите внимание, что мы говорим о 64-х разрядных x86 системах, работающих на Linux, и что я просто предполагаю, что система поддерживает transparent hugepages (так как не является недостатком то, что hugepages не подменяются), как это случается практически в любой современной среде Linux.

В ссылках ниже я прикреплю больше технического описания.

Виртуальная память

Если вы программист C++, вы знаете, что у объектов в памяти есть конкретные адреса (значения указателя).

Однако эти адреса необязательно отражают физические адреса в памяти (адреса в ОЗУ). Они представляют собой адреса в виртуальной памяти. Процессор имеет специальный модуль MMU (memory management unit), который помогает ядру сопоставлять виртуальную память с физическим местоположением.

Такой подход имеет множество преимуществ, но самые основные из них:

• Производительность (по различным причинам);
• Изоляция программ, то есть ни одна из программ не может читать из памяти другой программы.

Что такое страницы?

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

Большинство страниц, с которыми вы имеете дело, указывают либо на ОЗУ, либо подменяются (swap), то есть хранятся на жестком диске или SSD. Ядро управляет физическим расположением каждой страницы. Если осуществляется доступ к подмененной странице, ядро останавливает поток, который пытается получить доступ к памяти, считывает страницу с жесткого диска/SSD в оперативную память, а затем продолжает выполнение потока.

Этот процесс прозрачен для потока, то есть он не обязательно читает напрямую с жесткого диска/SSD. Размер нормальных страниц – 4096 байт. Размер Hugepages – 2 мегабайта.

Буфер ассоциативной трансляции (TLB)

Когда программа обращается к некоторой странице памяти, центральный процессор должен знать, с какой физической страницы считывать данные (то есть иметь виртуальную карту адресов).

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

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

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

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

Hugepages приходят на помощь

Итак, что мы можем сделать, чтобы избежать переполнения TLB? (Мы предполагаем, что программе все еще нужен тот же объем памяти).

Вот тут-то и появляются Hugepages. Вместо 4096 байт, требующих всего одну запись в TLB, одна запись в TLB теперь может указывать на колоссальные 2 мегабайта. Будем предполагать, что TLB имеет 512 записей, здесь без Hugepages мы можем сопоставить:

Тогда как с ними мы можем сопоставить:

Именно поэтому Hugepages – это круто. Они могут повысить производительность без значительного приложения усилий. Но здесь есть существенные оговорки.

Подмена Hugepages

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

Предположим, у нас есть такая программа:

В этом случае ядру нужно будет подменить (прочитать) целых 2 мегабайта информации с жесткого диска/SSD только для того чтобы вы прочитали один байт. Что касается обычных страниц, с жесткого диска/SSD надо прочитать всего 4096 байт.

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

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

Аллокация в памяти

Если вы пишете на С, вы знаете, что вы можете запросить сколь угодно малые (или почти сколь угодно большие) объемы памяти из кучи с помощью malloc() . Допустим, вам нужно 30 байт памяти:

Программисту может показаться, что вы “запрашиваете” 30 байт памяти из операционной системы и возвращаете указатель на некоторую виртуальную память. Но на самом деле malloc () — это просто функция C, которая вызывает изнутри функции brk и sbrk для запроса или освобождения памяти из операционной системы.

Однако, запрашивать больше и больше памяти для каждой аллокации неэффективно; наиболее вероятно, что какой-либо сегмент памяти уже был освобожден (free()) , и мы можем повторно его использовать. malloc() реализует довольно сложные алгоритмы для повторного использования освобожденной памяти.

При этом для вас все происходит незаметно, так почему это должно вас волновать? А потому, что вызов free() не означает, что память обязательно возвращается сразу же операционной системе.

Существует такое понятие, как фрагментация памяти. В крайних случаях есть сегменты кучи, где используется только несколько байтов, в то время, как все, что находится между ними было освобождено (free()) .

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

Выборочное применение hugepages

После прочтения статьи, вы определили, какие части вашей программы могут извлечь выгоду из применения hugepages, а какие – нет. Так следует ли вообще включать hugepages?

К счастью, вы можете использовать madvise() , чтобы включить hugepaging только для тех областей памяти, где это будет полезно.

Для начала, проверьте, что hugepages работают в режиме madvise(), с помощью инструкции в начале статьи.

Затем, используйте madvise() , чтобы указать ядру, где именно использовать hugepages.

Обратите внимание, что этот метод — просто рекомендации ядру по управлению памятью. Это не означает, что ядро будет автоматически использовать hugepages для заданной памяти.

Обратитесь к документации (manpage) madvise, чтобы узнать больше об управлении памятью и madvise() , у этой темы невероятно крутая кривая обучения. Поэтому, если вы намереваетесь действительно хорошо разобраться в ней, подготовьтесь к чтению и тестированию в течение нескольких недель, прежде чем рассчитывать на хоть какой-то положительный результат.

Что почитать?

Есть вопрос? Напишите в комментариях!