Memory alloc failed virtualalloc failed windows 10

Memory allocation for * bytes failed: причины и решения.

Прогресс и маркетинг дарят компьютерному пользователю стабильность в ценах на компьютерные составляющие и всё более оптимальную в подходе к этим составляющим операционную систему. Однако некоторых пользователей даже сегодня продолжает настигать “ошибка 2000-х” в виде аварийно захлопнувшегося приложения с сообщением Windows Memory allocation for * bytes failed. Так почему на фоне нередко переизбытка установленной RAM и запредельного по размерам pagefile.sys эта ошибка всё ещё досаждает некоторым из нас?

Проблема пришла к нам из тех времён, когда пользователи стали активно переходить с Windows XP на более современную Windows Vista и 7, пытаясь при этом сохранить прежнюю конфигурацию компьютера. Ошибка Memory allocation for * bytes failed – ни что иное как эхо ещё более коварной ошибки Unable to allocate memory, которая мучила владельцев “отстающих” сборок. Массовый переход производителей на 64-х битные версии процессоров, многоканальные проходы RAM решили проблему практически полностью. Однако…

СПРАВКА

К сожалению, вследствие ограниченного перевода локализаций Windows, пользователь не всегда способен правильно оценивать обстановку. А на неё Windows нередко прямо и указывает. В нашем случае ошибка Memory allocation for * bytes failed говорит о том, что оперативной памяти в указанном размере было отказано в выделении для этого приложения. Это значит, что отвечающая за перераспределение памяти процедура Управления памятью (Memory Management) просто не справляется с обязанностями. Учитывая границы зависимости MM, которые включают и аппаратные компоненты компьютера (RAM, чипсет, тип хранилища – SSD) и уровень приложений (объекты и структуры данных), можно предположить, что корни проблемы именно у вас никогда уже не решатся переустановкой Windows.

Memory allocation for * bytes failed: аппаратные ограничения

Ниже следуют наиболее вероятные причины ошибки. Они налагаются со стороны именно физического уровня аппаратного обеспечения:

• доступная системе память (не общий объём памяти в планках, а именно доступной Windows) – память забита другими приложениями; на вновь запущенное свободных блоков просто не хватает
• ограничения в объёмах поддерживаемой памяти – планок RAM в компьютер можно напихать сколь угодно – но более 4 Гб 32-х битная версия не увидит. А ещё и встроенная видеокарта хочет кушать…
• фрагментация оперативной памяти – сопредельные блоки оперативной памяти выделяются вылетающему приложению неэффективно

Чуть подробнее…

Доступная память – самое простое объяснение. Если объём требуемой памяти превышает объёмы установленной, запросу со стороны программы системой будет отказано. Конечно, Windows и другие ОС сами себе создали уловку: они считают, что общая память складывается из нескольких факторов:

• Физическая память (видимые объёмы планок RAM)
• Виртуальная память (выделяемая системой часть на жёстком диске/флешке, куда системой будет записываться информация по нехватке RAM и программам, ожидающим – swapfile+pagefile)
• Свободная память из части общей RAM (памяти может быть много, но если она занята остальными процессами, приложению будет отказано в дополнительных блоках).

Этими показателями и объясняются очень многие “НО”, из-за которых Windows не “отстёгивает” память, которую программа просит.

Memory allocation for * bytes failed: решения

• выходите из фоновых приложений, закрывайте ненужные на данный момент программы; в Диспетчере задач – искомая вкладка Процессы:

• выбираем планки оперативной памяти – и в магазин за дополнительными или более объёмными

• не экономьте на объёмах виртуальной памяти. Доверьте системе самой выбрать нужный. Но смысла задавать файл подкачки запредельных размеров тоже не вижу – это медленная память; выделяемые объёмы на диске просто погаснут перед маленькой скоростью обмена с жёстким диском. На SSD скорости буду по-интереснее, но всё равно это уже не совсем то…
• если компьютер очень уж стар, а до планок RAM ещё нужно дойти, попробуйте Readyboost. Дешёвый способ попробовать подстегнуть память за счёт флешки. Для ветхих систем – это иногда настоящая палочка-выручалочка

• в то время, как место на диске для файла подкачки выставлено достаточно, на всякий случай одна из флешек в режиме Readyboost, захлопываем все приложения и отправляемся в Диспетчер задач, где выставляем приоритет выполнения для “проблемного” процесса максимальный до уровня, пока нестабильность системы не станет очевидна:

• дефрагментация диска и регулярное удаление файлов pagefile.sys и swapfile.sys (по мере появления проблем с производительностью и ошибок RAM). Помните, что оба файла – это пространство жёсткого диска со всеми вытекающими проблемами: уже упомянутые медленные скорости обмена и почти мгновенная фрагментация файловой структуры.

Memory allocation for * bytes failed: ограничения со стороны системы

Тот случай, когда памяти много, а толку мало. Размер адресного пространства для конкретного процесса априори небольшой. Так память распределяется виртуальным Менеджером памяти, о котором мы уже упомянули: создаётся цепочка адресов памяти, которая связана с конкретным адресным пространством. А у адресного пространства всегда ограниченные границы значений. Так, для 32-х битных систем – это всегда лишь 4 Гб. Но это, вопреки обычному мнению, ещё и не весь предел накладываемым ограничениям. Системные адреса в процессе сеанса наносятся на адресное пространство, тем самым ещё более занижая свободное место. Так что порой, вопреки заявленным минимальным требованиям к “железу”, операционная система Windows 7 (даже установленная “начисто”), например, оставит процессам не более 2–2,5 Гб оперативной памяти из 4-х Гб.

Memory allocation for * bytes failed: решения

И думать нечего: переходим на 64 бита. На всех платформах. А 32-х битные сборки пора перевозить в гараж. Тем более, у 64-х битных систем огромные преимущества в вопросах безопасности.

Memory allocation for * bytes failed: фрагментация памяти?

Отсюда начинается очень скользкая тема. Некогда популярные ремонтные утилиты нередко предлагали пользователям в числе прочего и такую функцию как дефрагментация оперативной памяти. Скользкая потому, что моё личное мнение таково: часто шкура выделки не стоит. При нормально работающей системе такие программы если не мешают, то просто бесполезны. На старых системах – да. С объёмом RAM 1,5 – 2 Гб – безусловно. Но сейчас даже смартфоны мощнее. И с такими характеристиками комфортно можно работать разве что в Windows Millenium. В том виде, как эта проблема существовала, она современных пользователей (с, прежде всего, достаточным объёмом памяти) уже не касается (кому интересно – подробности в ссылке): она целиком и полностью ложится на плечи разработчиков. И даже принудительная фрагментация оперативной памяти самой Windows во время загрузки программы-тяжеловеса не должна вызывать ошибки Memory allocation for * bytes failed. Однако… Проверьте, не использует ли ваша “проблемная” программа библиотеку Microsoft Foundation Classes (MFC).

Memory allocation for * bytes failed: решения

В нашем случае единственное – обновите версию Framework до последней. Неважно, что хочет программа. Версия .NET Framework 4 должна быть установлена. И позаботьтесь о том, чтобы обновления к Windows приходили в вашу систему вовремя.

Тестирование оперативной памяти с помощью memtest поможет вскрыть проблемы в связке “планка-оперативной-памяти -> слот DIMM”. Если ошибки с RAM продолжают преследовать вашу ОС даже после переустановки, время пускать в ход тяжёлую артиллерию.

Источник

xmr-stak-cpu настройка

topfor

Знающий

MEMOMRY ALLOC FAILED никак не смущает ?

Lexabush

Свой человек

Вложения

Знающий

If you set up the user rights properly (see above), and your system has 4-8GB of RAM (50%+ use), there is a significant chance that there simply won’t be a large enough chunk of contiguous memory because Windows is fairly bad at mitigating memory fragmentation.

If that happens, disable all auto-staring applications and run the miner after a reboot.

Говорит памяти не хватает.
Win64 ? Сколько памяти свободно во время запуска майнера ?

topfor

Знающий

topfor

Знающий

Знающий

Знающий

topfor

Знающий

С памятью пока не могу решить, завтра попробую доставить плашку, чтобы точно понять в этом ли причина. А на двух ядрах вроде получше стало: 105 хэшей было. Только в самом найсхэше постоянно нули. Конфиг щас такой:

«cpu_thread_num»: 2,
«cpu_threads_conf» : [
< "low_power_mode" : false, "no_prefetch" : false, "affine_to_cpu" : 1 >,
< "low_power_mode" : false, "no_prefetch" : false, "affine_to_cpu" : 2 >,
],
«use_slow_memory»: «warn»,
«nicehash_nonce»: true,
«pool_address»: «cryptonight.eu.nicehash.com:3355»,
«wallet_address»: «16JkpyByteaJG18rRRiGgopGvD48TJPJ8E.Bytea»,
«pool_password»: «x»,
«call_timeout»: 10,
«retry_time»: 10,
«verbose_level»: 4,
«h_print_time»: 180,
«httpd_port»: 4001,
«prefer_ipv4»: true

память очистил до 46% но не помогло, что еще можно попробовать?

Lexabush

Свой человек

С памятью пока не могу решить, завтра попробую доставить плашку, чтобы точно понять в этом ли причина. А на двух ядрах вроде получше стало: 105 хэшей было. Только в самом найсхэше постоянно нули. Конфиг щас такой:

«cpu_thread_num»: 2,
«cpu_threads_conf» : [
< "low_power_mode" : false, "no_prefetch" : false, "affine_to_cpu" : 1 >,
< "low_power_mode" : false, "no_prefetch" : false, "affine_to_cpu" : 2 >,
],
«use_slow_memory»: «warn»,
«nicehash_nonce»: true,
«pool_address»: «cryptonight.eu.nicehash.com:3355»,
«wallet_address»: «16JkpyByteaJG18rRRiGgopGvD48TJPJ8E.Bytea»,
«pool_password»: «x»,
«call_timeout»: 10,
«retry_time»: 10,
«verbose_level»: 4,
«h_print_time»: 180,
«httpd_port»: 4001,
«prefer_ipv4»: true

память очистил до 46% но не помогло, что еще можно попробовать?

Многие нарываются на ошибку «MEMORY ALLOC FAILED». Майнер при этом работает, но процентов на 20 медленнее. Решение простейшее:

Linux:
sudo sysctl -w vm.nr_hugepages=128
sudo echo «vm.nr_hugepages=128» >> /etc/sysctl.conf

Windows (перезагрузка обязательна; ntrights — утилита из resource pack):
ntrights -u %USERNAME% +r SeLockMemoryPrivilege
shutdown -r -f -t 00

Источник

MEMORY ALLOC FAILED: mlock failed despite everything looks okay #376

Comments

Copy link Quote reply

eLvErDe commented Oct 17, 2017

Here’s my start log:

So I still see issues regarding memory allocation. HOWEVER: I do have proper limits:

Btw, I think you should add this simple shell command to help users figuring out if everything is correctly setup in README.md

Btw, I’m nearly done packaging the whole app as a proper Debian/Ubuntu package. All you have to do is edit a simple config file to setup the pool address, everything else is configured automatically (using an homemade Python script to generate config.txt). Would you be interrested in it ?

Copy link Quote reply

bladepif commented Oct 18, 2017

Hello Same error for me.
My config is on https://pastebin.com/bjqXa0pG

Copy link Quote reply

bladepif commented Oct 18, 2017

Return with the command
Max locked memory 268435456 268435456 bytes

Copy link Quote reply

eLvErDe commented Oct 18, 2017

Here’re another logs showing the hugepage get’s used when starting xmr-stak-cpu (from /proc/meminfo) but still displaying some memory related errors.

Copy link Quote reply

bladepif commented Oct 18, 2017

I have recompile xmr-stak-cpu master branch using:

This was said in some other issue
The errors are away now and hashrate is the same as before.
So it looks fine but I wich somebody could explain the difference when -DHWLOC_ENABLE=ON or -DHWLOC_ENABLE=OFF. What should the hwloc bring? more hashrate?

Copy link Quote reply

Copy link Quote reply

eLvErDe commented Oct 18, 2017

But what’s required to enable this feature on a Linux system ?

Copy link Quote reply

bladepif commented Oct 19, 2017

So if I understand it right hwloc does not necessary make a difference, depending on the hardware and OS you use.

@eLvErDe my advise, check your hashrate how it is right now and recompile xmr-stak-cpu with the option -DHWLOC_ENABLE=OFF. then check you hashrate again and if there is not difference you can use this new compiled version. That’s the way I did it. I also tried the dev Branch but result was the same with and without this option in my case

Copy link Quote reply

eLvErDe commented Oct 19, 2017

Looking at libhwloc dependency I think it has absolutely no relation with my memory message. Moreover it seems used by the tool to generate optimized config.txt

Copy link Quote reply

Forage commented Nov 7, 2017

I have the same issue. This despite having set hugepages to 128 on Ubuntu 16.04, which is supposed to fix this error. What else could be causing this issue?

Copy link Quote reply

svenha commented Nov 7, 2017

Some limits (max memory size, virtual memory) can be too small. I needed to increase them to 64 GB. If this does not help, can you please post the output of ‘ulimit -a’?

Copy link Quote reply

cbesot commented Nov 11, 2017

Same problem form me.

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 66068
max locked memory (kbytes, -l) 262144
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 66068
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Copy link Quote reply

one-quaker commented Dec 21, 2017

Have same problem on 13 gtx 1060 gpu rig

Copy link Quote reply

Copy link Quote reply

one-quaker commented Dec 25, 2017

limits.conf + huge pages in sysctl.conf solve this error, thank you

Copy link Quote reply

bill-mcgonigle commented Dec 26, 2017

I get successful mlocks on Debian Stretch with:

even as an unprivileged user. Try those and reboot if you’re not getting this to work.

Two mysteries I still hit that might(?) be related to others’ troubles :

1. under a systemd unit it’s not working, even with:

set in the [Service].

1. my hashrate is exactly the same with or without getting the error (Ryzen 1700).