Cannot allocate kernel buffer linux

fork: Cannot allocate memory

Что творится с серваком? Несколько лет работал а тут такое. Раза с 20 зашел по ssh на все команды fork: Cannot allocate memory, но если долго пытаться то команды выполняются. Свободной памяти много. В чем проблема? Может быть в физическом повреждении RAM?

OS, ядро, dmesg, сколько процессов ? Может баг в ядре который ребутом полечится

А процессов сколько?

Debian 7.11 3.2.0-4-amd64 процессов 146 в dmesg чисто, ребут был.

/proc/meminfo и /proc/sys/vm/overcommit_memory покажи

3.2.0 — както стремно (уже 84 багфикса было для 3.2 ветки).

А что в /proc/slabinfo ? И сколько всего потоков ?

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

Окей, а теперь покажи пожалуйста ulimit -a

Хм, тоже вроде никакого криминала(у меня например, некоторые параметры даже ниже по дефолту). Ну и наконец выхлоп ps aux на какой-нибудь pastebin бы не помешал

Update: вот тут чуть подробнее расписали возможные проблемы

Ищите процесс (процессы) которые запросили большое количество RAM (можно в top Shift+M и смотреть у кого большой VIRT)

Вообще не интересно самый жирный это

И кто у нас 21776? Чинится ли всё, если его прибить?

Насколько я понял 21776 процесс запросил 36G RAM

Да действительно прибил 21776 и все наладилось. Но вот что странно запросил он 35.0g а использовал всего 2.5g. Притом своп пустой на запросы памяти сыпется Cannot allocate memory. Почему?

Есть подозрение что дело в overcommit и бажном процессе, который сделал malloc на overдохрена памяти

top — 21:32:03 up 5:36, 2 users, load average: 0.14, 0.19, 0.18
Tasks: 138 total, 1 running, 137 sleeping, 0 stopped, 0 zombie
%Cpu(s): 13.5 us, 0.8 sy, 0.0 ni, 85.3 id, 0.2 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 32878740 total, 10601464 used, 22277276 free, 62572 buffers
KiB Swap: 16768892 total, 0 used, 16768892 free, 6246996 cached

Это ты шифруешься так, что ли? Я понимаю там логины пользователей еще скрывать, но что у тебя такого сверхсекретного в именах процессов? 🙂

И еще, ты так и не ответил что именно за процесс был под pid 21776.

Логично. Процесс кривой но нужный, раньше столько МЕМа не заказывал.

Это что бы холивар не разводить. Java это была java :)))

Не дай бохъ узнают, шо java (подкодит по кол-ву символов) крутит. 😉

Вариантов тут немного: либо фиксить поведение процесса(патчить, писать багрепорты и/или накатывать новую версию), либо переключать overcommit в режим 2.

ОСТОРОЖНО: неправильные настройки overcommit могут к чертям сломать тебе систему, пока не откатишь в зад. Например, у меня при дефолтных 50% overcommit_ratio на десктопе с 4G RAM напрочь отказывались запускаться ЛЮБЫЕ приложения на java(даже hello world).

Update: гы, как в воду глядел, начал писать коммент до того как увидел инфу про java 🙂

Крути настройки GC в java, ну или overcommit, но осторожно и желательно с локальным доступом(хотя SSH по идее прибивается OOM-Killer-ом в сааамую последнюю очередь, так что. )

Источник

InnoDB: Cannot allocate memory for the buffer pool [Solved]

Table of Contents

Recently we received a ticket where the client pointed out that his MySQL server was not starting. Upon investigation, we found out that the client used our MySQL Optimization tool to optimize and enhance MySQL performance. Our MySQL optimization tool set the value of innodb-buffer-pool-size size depending upon the available ram on the server. The current formula sets its value to 35% of the server ram. Which is fine for most cases, but in this case, it was not good, because there were some other processes in the client-server taking more ram, so there was not enough ram available to allocate for innodb-buffer-pool-size thus MySQL reports InnoDB: Cannot allocate memory for the buffer pool as error in MySQL log file.

Depending upon the MySQL version you might also receive innodb fatal error cannot allocate memory for the buffer pool as an error, which is the same error with a different description.

If doing this is too much for you, you can sign up with us and let our experts do this for you. Contact us to get started.. We also help our customers with MySQL optimizations.

What is InnoDB Buffer Pool (innodb_buffer_pool_size) and why it is important?

InnoDB Buffer is the space in memory used by MySQL to hold many of its InnoDB data structures. Such as caches, buffers, indexes, and even row data. And then innodb_buffer_pool_size is the MySQL directive that controls its value. This is one of the most significant directive in MySQL perspective and should be set with care if you want to improve your MySQL performance.

In this tutorial we will see how we can calculate and set optimal value for innodb_buffer_pool_size depending on the available memory on your system and then we will discuss on how to solve InnoDB: Cannot allocate memory for the buffer pool error in case you run into it at a later point in time.

70% – 80% of the Available Ram

Normally if your server is only dedicated for MySQL it is recommended to set innodb_buffer_pool_size value to 70-80% of the available ram. So for example, if your server has 8GB of ram, you can calculate the value of innodb_buffer_pool_size using this formula

But in case if your server has a very large amount of ram such as 256GB, then you can further enhance it to 90% as well. Because if your server is only being used for MySQL, the rest of the ram will go in waste, so you can increase or decrease this value depending upon the available ram or your needs.

If doing this is too much for you, you can sign up with us and let our experts do this for you. Contact us to get started.. We also help our customers with MySQL optimizations.

Optimal value with CyberPanel

When you are using CyberPanel then 70-80% ram cannot be allocated for innodb_buffer_pool_size size, because there are many other things running and there must be some room for them to breathe. Otherwise, if you set a large value for innodb_buffer_pool_size you will start receiving InnoDB: Cannot allocate memory for the buffer pool or innodb fatal error cannot allocate memory for the buffer pool as an error. This means there is not enough ram available and MySQL cannot start now. Which is why our optimization tool set it to 35% of the available ram.

But sometimes 35% is not good as well. For example, you have lots of websites and they are continuously forking PHP processes and you are also using FTP and DNS server. Then you either need to further go down with the value of innodb_buffer_pool_size.

Fixing the InnoDB: Cannot allocate memory for the buffer pool error

Now let see how we can fix this error, let say you have used or MySQL Optimization tool, and now MySQL is not starting. First, make sure that this is the reason your MySQL is not starting. You can open the MySQL logfile located at /var/lib/mysql/mysqld.log. This location is set by our optimization tool, if you are not using our tool, you can find MySQL log file depending upon your configuration, and you must see the following lines somewhere in the log file

2019-06-11 10:52:09 140525444196608 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-06-11 10:52:09 140525444196608 [Note] InnoDB: The InnoDB memory heap is disabled
2019-06-11 10:52:09 140525444196608 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-06-11 10:52:09 140525444196608 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-06-11 10:52:09 140525444196608 [Note] InnoDB: Compressed tables use zlib 1.2.7
2019-06-11 10:52:09 140525444196608 [Note] InnoDB: Using Linux native AIO
2019-06-11 10:52:09 140525444196608 [Note] InnoDB: Using SSE crc32 instructions
2019-06-11 10:52:09 140525444196608 [Note] InnoDB: Initializing buffer pool, size = 358.0M
InnoDB: mmap(393183232 bytes) failed; errno 12
2019-06-11 10:52:09 140525444196608 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2019-06-11 10:52:09 140525444196608 [ERROR] Plugin ‘InnoDB’ init function returned error.
2019-06-11 10:52:09 140525444196608 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.

Pay close attention to the bold lines, we are now sure that MySQL failed at InnoDB: Initializing buffer pool. Now open /etc/my.cnf and find innodb-buffer-pool-size = xxxM. Now set the value of this directive to something lower such as 50MB just for test and restart MySQL using systemctl restart mysql. However, you can play with various values and make sure you get the optimal value for your configuration.

If doing this is too much for you, you can sign up with us and let our experts do this for you. Contact us to get started.. We also help our customers with MySQL optimizations.

Источник

Как победить cannot allocate memory for the buffer pool в MYSQL?

Не могу победить mysql.
Раз в сутки или чаще мускул ложится.
Памяти много, 32 гб, нагрузки мизер на сервере.

Mysqltuner но это совсем свежак, прямо после перезагрузки данные

• Вопрос задан более трёх лет назад
• 10761 просмотр

Размер глобальных буферов (key_buffer_size + tmp_table_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size).

Размер буфера одного подключения (read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size).

Так же не забываем последнее умножить на max_connections и сумма всего этого хозяйства в идиале не должна привышать вашу память.

у вас буфер innodb_buffer_pool_size=10G а это уже треть памяти

160109 22:37:20 InnoDB: Initializing buffer pool, size = 10.0G
InnoDB: mmap(686817280 bytes) failed; errno 12
и забрать он из не смог
Вы прям уверенны, что в этот момент никто не занимает память?

Shing: Хех, так к вам раз в сутки прибегает поисковик и начинает долбить, что то на пхп где лимит под запрос 512mb а то и больше, вот память и улетает. Они как раз раз в сутки бегают в среднем. Проверьте access.log во время падения, на 99% уверен, что именно поисковики вы там и уведите.

посмотрите, что у вас тут на не упавшем сервере [[0;32mOK[0m] InnoDB buffer pool / data size: 10.0G/42.7M

Снизил пока до 3 Гб innodb pool, посмотрим что будет, может еще уменьшу позже
InnoDB buffer pool / data size: 3.0G/42.7M

В log/httpd/access_log вообще только такое
»
127.0.0.1 — — [07/Jan/2016:16:00:01 +0300] «GET /server-status HTTP/1.0» 200 26861 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:05:02 +0300] «GET /server-status HTTP/1.0» 200 27000 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:10:02 +0300] «GET /server-status HTTP/1.0» 200 27116 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:15:01 +0300] «GET /server-status HTTP/1.0» 200 26946 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:20:01 +0300] «GET /server-status HTTP/1.0» 200 26920 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:25:01 +0300] «GET /server-status HTTP/1.0» 200 27207 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:30:01 +0300] «GET /server-status HTTP/1.0» 200 26923 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:35:02 +0300] «GET /server-status HTTP/1.0» 200 26978 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:40:02 +0300] «GET /server-status HTTP/1.0» 200 27126 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:45:02 +0300] «GET /server-status HTTP/1.0» 200 26904 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:50:01 +0300] «GET /server-status HTTP/1.0» 200 27120 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:16:55:01 +0300] «GET /server-status HTTP/1.0» 200 27064 «-» «Wget/1.12 (linux-gnu)»
127.0.0.1 — — [07/Jan/2016:17:00:01 +0300] «GET /server-status HTTP/1.0» 200 27426 «-» «Wget/1.12 (linux-gnu)»

Источник

SIOCSIFFLAGS: Cannot allocate memory

Affects		Status	Importance	Assigned to	Milestone
​	linux (Ubuntu) Edit

Bug Description

Binary package hint: gnome-system-tools

$ sudo ifconfig eth0 down
user@ubuntu:

$ sudo ifconfig eth0 up
SIOCSIFFLAGS: Cannot allocate memory

[ 8255.927028] ifconfig: page allocation failure. order:3, mode:0x4020
[ 8255.927032] Pid: 27488, comm: ifconfig Tainted: P 2.6.35-22-generic #35-Ubuntu
[ 8255.927034] Call Trace:
[ 8255.927042] [ 253>] __alloc_ pages_slowpath+ 0x583/0x590
[ 8255.927045] [ 3fa>] __alloc_ pages_nodemask+ 0x19a/0x1f0
[ 8255.927049] [ 1be>] ? _raw_spin_ lock+0xe/ 0x20
[ 8255.927053] [ b02>] kmalloc_ large_node+ 0x62/0xb0
[ 8255.927055] [ 67c>] __kmalloc_ node_track_ caller+ 0x13c/0x1f0
[ 8255.927059] [ cc6>] ? __netdev_ alloc_skb+ 0x36/0x60
[ 8255.927061] [ 9b3>] __alloc_ skb+0x83/ 0x170
[ 8255.927063] [ cc6>] __netdev_ alloc_skb+ 0x36/0x60
[ 8255.927076] [ 1fc>] rtl8169_ rx_fill+ 0xbc/0x260 [r8169]
[ 8255.927080] [ 010>] ? swiotlb_ map_page+ 0x0/0xf0
[ 8255.927084] [ e63>] rtl8169_ init_ring+ 0x73/0xb0 [r8169]
[ 8255.927088] [ 141>] rtl8169_ open+0x1b1/ 0x460 [r8169]
[ 8255.927092] [ 287>] __dev_open+ 0xa7/0xf0
[ 8255.927094] [ 6d1>] __dev_change_ flags+0xa1/ 0x180
[ 8255.927097] [ 198>] dev_change_ flags+0x28/ 0x70
[ 8255.927100] [ ea3>] devinet_ ioctl+0x5a3/ 0x600
[ 8255.927103] [ 2b0>] inet_ioctl+ 0x90/0xb0
[ 8255.927106] [ b40>] sock_do_ ioctl+0x30/ 0x60
[ 8255.927108] [ cb9>] sock_ioctl+ 0x79/0x2b0
[ 8255.927111] [ 95d>] vfs_ioctl+0x3d/0xd0
[ 8255.927114] [ 231>] do_vfs_ ioctl+0x81/ 0x340
[ 8255.927117] [ f2e>] ? do_page_ fault+0x15e/ 0x350
[ 8255.927119] [ 571>] sys_ioctl+0x81/0xa0
[ 8255.927122] [ 0f2>] system_ call_fastpath+ 0x16/0x1b
[ 8255.927124] Mem-Info:
[ 8255.927125] Node 0 DMA per-cpu:
[ 8255.927128] CPU 0: hi: 0, btch: 1 usd: 0
[ 8255.927129] CPU 1: hi: 0, btch: 1 usd: 0
[ 8255.927130] Node 0 DMA32 per-cpu:
[ 8255.927132] CPU 0: hi: 186, btch: 31 usd: 139
[ 8255.927134] CPU 1: hi: 186, btch: 31 usd: 170
[ 8255.927136] Node 0 Normal per-cpu:
[ 8255.927138] CPU 0: hi: 186, btch: 31 usd: 156
[ 8255.927139] CPU 1: hi: 186, btch: 31 usd: 55
[ 8255.927143] active_anon:255390 inactive_anon:61872 isolated_anon:0
[ 8255.927144] active_file:263758 inactive_ file:332763 isolated_file:0
[ 8255.927145] unevictable:611 dirty:1311 writeback:0 unstable:0
[ 8255.927146] free:24044 slab_reclaimabl e:26025 slab_unreclaima ble:5189
[ 8255.927146] mapped:34777 shmem:3120 pagetables:7667 bounce:0
[ 8255.927148] Node 0 DMA free:15844kB min:28kB low:32kB high:40kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15708kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimabl e:0kB slab_unreclaima ble:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[ 8255.927156] lowmem_reserve[]: 0 3511 4016 4016
[ 8255.927159] Node 0 DMA32 free:79576kB min:7072kB low:8840kB high:10608kB active_ anon:971492kB inactive_ anon:196064kB active_ file:939140kB inactive_ file:1196304kB unevictable:32kB isolated(anon):0kB isolated( file):132kB present:3595360kB mlocked:32kB dirty:4212kB writeback:0kB mapped:122344kB shmem:11492kB slab_reclaimabl e:89052kB slab_unreclaima ble:14388kB kernel_stack:2456kB pagetables:28708kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 8255.927167] lowmem_reserve[]: 0 0 505 505
[ 8255.927170] Node 0 Normal free:864kB min:1016kB low:1268kB high:1524kB active_anon:50068kB inactive_ anon:51424kB active_ file:115892kB inactive_ file:134616kB unevictable:2412kB isolated(anon):0kB isolated(file):0kB present:517120kB mlocked:0kB dirty:1032kB writeback:0kB mapped:16764kB shmem:988kB slab_reclaimabl e:15048kB slab_unreclaima ble:6360kB kernel_stack:696kB pagetables:1960kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 8255.927178] lowmem_reserve[]: 0 0 0 0
[ 8255.927181] Node 0 DMA: 1*4kB 0*8kB 2*16kB 2*32kB 2*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15844kB
[ 8255.927189] Node 0 DMA32: 18581*4kB 232*8kB 198*16kB 3*32kB 0*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 79700kB
[ 8255.927196] Node 0 Normal: 130*4kB 13*8kB 13*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 864kB
[ 8255.927204] 600192 total pagecache pages
[ 8255.927205] 0 pages in swap cache
[ 8255.927207] Swap cache stats: add 0, delete 0, find 0/0
[ 8255.927208] Free swap = 261116kB
[ 8255.927209] Total swap = 261116kB
[ 8255.942071] 1048560 pages RAM
[ 8255.942073] 34508 pages reserved
[ 8255.942075] 587854 pages shared
[ 8255.942076] 539747 pages non-shared

Источник