Процесс в Arch Linux не хватает памяти на 7,6 ГБ, несмотря на 16 ГБ ОЗУ с последующими ошибками шины

Question

Я пытаюсь использовать большой кусок памяти в R, размером около 7,6 ГБ. Моя система имеет 16 ГБ ОЗУ, поэтому я не ожидал, что это станет проблемой. Однако R предотвращает это, и попытка обойти это приводит к массовым сбоям R и различных других приложений (веб-браузеров). Система сообщила о проблемах с шиной, но у меня нет точных сообщений об ошибках, так как система в конечном итоге потерпела крах.

Мой вопрос: что случилось? Как я могу предотвратить это и выделить больше памяти в R (или любом приложении)?

У меня такое ощущение, что это может быть связано с тем, сколько памяти адресуемо, а не с памятью, которая теоретически доступна.

подробности

Я попытался использовать больший кусок памяти в R, матрицу с 1 млрд записей, около 7,6 ГБ. R не легко допускает векторы / матрицы такого размера, хотя мне не понятно, почему. (Это приводит к Error: cannot allocate vector of size 7.6 Gb). Однако в R есть такие библиотеки, как bigmemory, которые предположительно способны работать с большими векторами. От переводчика R:

> library(bigmemory)
Loading required package: bigmemory.sri
> bx <- big.matrix(45070,45070)

 *** caught bus error ***
address 0x7ff75ffac000, cause 'non-existent physical address'

Traceback:
 1: .Call("bigmemory_CreateSharedMatrix", PACKAGE = "bigmemory",     row, col, colnames, rownames, typeLength, ini, separated)
 2: CreateSharedMatrix(as.double(nrow), as.double(ncol), as.character(colnames),     as.character(rownames), as.integer(typeVal), as.double(init),     as.logical(separated))
 3: big.matrix(45070, 45070)

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection:

Итак, R потерпел крах, но его можно сохранить, выбрав 2 и отменив выход. Возможно, было бы не очень умно попробовать то же самое снова, но в любом случае, здесь мы идем:

Selection: 2
Save workspace image? [y/n/c]: c
> bx <- big.matrix(45070,45070)
terminate called after throwing an instance of 'boost::interprocess::interprocess_exception'
  what():  No space left on device
Aborted (core dumped)

Из журнала журнала это выглядит так:

Aug 23 14:49:25 system systemd-coredump[426]: Process 423 (R) of user 1000 dumped core.

                                           Stack trace of thread 423:
                                           #0  0x00007ff94bab18c0 raise (libc.so.6)
                                           #1  0x00007ff94bab2f72 abort (libc.so.6)
                                           #2  0x00007ff94774d035 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6)
                                           #3  0x00007ff94774ac46 _ZN10__cxxabiv111__terminateEPFvvE (libstdc++.so.6)
                                           #4  0x00007ff947749b49 __cxa_call_terminate (libstdc++.so.6)
                                           #5  0x00007ff94774a538 __gxx_personality_v0 (libstdc++.so.6)
                                           #6  0x00007ff9474b3ee3 _Unwind_RaiseException_Phase2 (libgcc_s.so.1)
                                           #7  0x00007ff9474b470e _Unwind_Resume (libgcc_s.so.1)
                                           #8  0x00007ff945279da6 _ZN21SharedMemoryBigMatrix7destroyEv (bigmemory.so)
                                           #9  0x00007ff9452a7762 _Z15CreateRAMMatrixI21SharedMemoryBigMatrixEP7SEXPRECS2_S2_S2_S2_S2_S2_S2_ (bigmemory.so)
                                           #10 0x00007ff94528d79c bigmemory_CreateSharedMatrix (bigmemory.so)
                                           #11 0x00007ff94c11a33a n/a (libR.so)
                                           #12 0x00007ff94c11a8c6 n/a (libR.so)
                                           #13 0x00007ff94c158fb8 Rf_eval (libR.so)
                                           #14 0x00007ff94c15ba3b n/a (libR.so)
                                           #15 0x00007ff94c158d5b Rf_eval (libR.so)
                                           #16 0x00007ff94c15adce n/a (libR.so)
                                           #17 0x00007ff94c150963 n/a (libR.so)
                                           #18 0x00007ff94c158938 Rf_eval (libR.so)
                                           #19 0x00007ff94c15adce n/a (libR.so)
                                           #20 0x00007ff94c158b02 Rf_eval (libR.so)
                                           #21 0x00007ff94c15cbc7 n/a (libR.so)
                                           #22 0x00007ff94c158d5b Rf_eval (libR.so)
                                           #23 0x00007ff94c181f92 Rf_ReplIteration (libR.so)
                                           #24 0x00007ff94c1823b1 n/a (libR.so)
                                           #25 0x00007ff94c182468 run_Rmainloop (libR.so)
                                           #26 0x000000000040074b main (R)
                                           #27 0x00007ff94ba9e4ca __libc_start_main (libc.so.6)
                                           #28 0x000000000040078a _start (R)
-- Subject: Process 423 (R) dumped core
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
-- 
-- Process 423 (R) crashed and dumped core.
-- 
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.

Общесистемные последствия

В это время ни настольная среда, ни графические приложения не работали. Я запустил диспетчер окон и браузер, чтобы посмотреть, что происходит. К моему ужасу, я обнаружил, что ни Firefox, ни Opera, ни Chromium не запускаются. В сообщениях об ошибках говорится что-то об ошибках шины, но у меня нет точных сообщений об ошибках, так как система в конечном итоге рухнула. Примечательно, что другие приложения, даже более крупные, такие как libreoffice, могут быть запущены без проблем. Может быть, это как-то связано с адресами, необходимыми для установления сетевых подключений? Может ли быть так, что после сбоя R система как-то потеряла адрес? (Я не понимаю, однако, почему это сохранится после того, как процесс R умер.)

Из журнала журнала это выглядит так (длинные трассировки стека усекаются):

Aug 23 15:16:19 system systemd-coredump[18050]: Process 18017 (firefox) of user 1000 dumped core.

                                             Stack trace of thread 18017:
                                             #0  0x00007ff72e679018 sem_init@@GLIBC_2.2.5 (libpthread.so.0)
                                    (...)

Aug 23 15:16:20 system systemd-coredump[18097]: Process 18062 (firefox) of user 1000 dumped core.

                                             Stack trace of thread 18062:
                                             #0  0x00007f2098a98018 sem_init@@GLIBC_2.2.5 (libpthread.so.0)
                                    (...)

Aug 23 15:16:21 system systemd-coredump[18144]: Process 18109 (firefox) of user 1000 dumped core.

                                             Stack trace of thread 18109:
                                             #0  0x00007f2d45410018 sem_init@@GLIBC_2.2.5 (libpthread.so.0)
                                    (...)
                                    (...)
                                    (...)

Aug 23 15:19:16 system systemd-coredump[19510]: Process 19370 (opera) of user 1000 dumped core.

                                             Stack trace of thread 19395:
                                             #0  0x0000000001c882f7 n/a (opera)
                                             #1  0x0000000001c890e9 n/a (opera)
                                    (...)

Aug 23 15:20:58 system systemd-coredump[20140]: Process 20136 (evas_image_load) of user 1000 dumped core.

                                             Stack trace of thread 20136:
                                             #0  0x00007fba4432babd __memset_avx2_erms (libc.so.6)
                                    (...)

Aug 23 15:30:11 system systemd-coredump[20990]: Process 20958 (WebKitWebProces) of user 1000 dumped core.

                                             Stack trace of thread 20958:
                                             #0  0x00007fc5dd5ed7d0 n/a (libpixman-1.so.0)
                                             #1  0x00007fc5dd5d273b n/a (libpixman-1.so.0)
                                    (...)

Aug 23 15:31:07 system systemd-coredump[22406]: Process 20936 (midori) of user 1000 dumped core.

                                             Stack trace of thread 22403:
                                             #0  0x00007f3a38d5b6df __memmove_avx_unaligned_erms (libc.so.6)
                                             #1  0x00007f3a39759e78 n/a (libwebkit2gtk-4.0.so.37)

Затем я попытался перезапустить dbus (что также не было самым умным ходом и сломало систему).

Другие аспекты

До сбоя системы я также понял следующее:

[user@system ~]$ df -h
Filesystem         Size  Used Avail Use% Mounted on
dev                7.6G     0  7.6G   0% /dev
run                7.6G  788K  7.6G   1% /run
/dev/mapper/root   412G   89G  324G  22% /
tmpfs              7.6G  7.6G     0 100% /dev/shm
tmpfs              7.6G     0  7.6G   0% /sys/fs/cgroup
/dev/sda1          2.0G   52M  1.8G   3% /boot
tmpfs              7.6G     0  7.6G   0% /tmp
tmpfs              1.6G     0  1.6G   0% /run/user/1000
[user@system ~]$ free -m
              total        used        free      shared  buff/cache   available
Mem:          15469         146        7438        7735        7884        7349
Swap:         14335           0       14335
[user@system ~]$

Почему виртуальные файловые системы (dev, run, tmpfs) имеют размер 7,6 ГБ, именно то, что R не выделит?

Я проверил, что можно выделить до 6,7 ГБ в R, но где-то ниже 7,6 ГБ есть ограничение. Максимальная память не установлена ни в R, ни в системе:

[user@system ~]$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 61833
max locked memory       (kbytes, -l) unlimited
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) 99
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 61833
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

... и в интерпретаторе R:

> Sys.getenv("R_MAX_MEM_SIZE")
[1] ""
> Sys.getenv()
COLUMNS                 235
DBUS_SESSION_BUS_ADDRESS
                        unix:path=/run/user/1000/bus
DESKTOP                 Enlightenment
DISPLAY                 :0.0
E_BIN_DIR               /usr/bin
E_CONF_PROFILE          standard
E_DATA_DIR              /usr/share/enlightenment
E_ICON_THEME            gnome
E_IPC_SOCKET            /run/user/1000/e-user@0/633
E_LIB_DIR               /usr/lib
E_LOCALE_DIR            /usr/share/locale
E_PREFIX                /usr
E_RESTART               1
E_SCALE                 1.000
E_START                 enlightenment_start
E_START_TIME            1503499246.8
E_TAINTED               NO
EDITOR                  vi
HOME                    /home/user
LANG                    en_GB.UTF-8
LD_LIBRARY_PATH         /usr/lib64/R/lib:/usr/lib/jvm/java-7-openjdk/jre/lib/amd64/server
LINES                   58
LN_S                    ln -s
LOGNAME                 user
M2                      /opt/maven//bin
M2_HOME                 /opt/maven/
MAIL                    /var/spool/mail/user
MAKE                    make
MAVEN_OPTS              -Xmx512m
MOZ_PLUGIN_PATH         /usr/lib/mozilla/plugins
PAGER                   /usr/bin/less
PANTS                   ON
PATH                    /opt/maven//bin:/home/user/Applications/.bin:/usr/bin:/opt/maven//bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
PWD                     /home/user
QT_QPA_PLATFORMTHEME    gtk2
QT_STYLE_OVERRIDE       gtk2
R_ARCH                  
R_BROWSER               /usr/bin/xdg-open
R_BZIPCMD               /usr/bin/bzip2
R_DOC_DIR               /usr/share/doc/R/
R_GZIPCMD               /usr/bin/gzip
R_HOME                  /usr/lib64/R
R_INCLUDE_DIR           /usr/include/R/
R_LIBS_SITE             
R_LIBS_USER             ~/R/x86_64-pc-linux-gnu-library/3.4
R_PAPERSIZE             a4
R_PDFVIEWER             /usr/bin/xdg-open
R_PLATFORM              x86_64-pc-linux-gnu
R_PRINTCMD              
R_RD4PDF                times,inconsolata,hyper
R_SESSION_TMPDIR        /tmp/RtmpXBvepb
R_SHARE_DIR             /usr/share/R/
R_SYSTEM_ABI            linux,gcc,gxx,gfortran,?
R_TEXI2DVICMD           /usr/bin/texi2dvi
R_UNZIPCMD              /usr/bin/unzip
R_ZIPCMD                /usr/bin/zip
SED                     /usr/bin/sed
SHELL                   /bin/bash
SHLVL                   3
TAR                     /usr/bin/tar
TERM                    xterm
USER                    user
WINDOWPATH              1
XAUTHORITY              /home/user/.Xauthority
XDG_CONFIG_DIRS         /usr/etc/xdg:/etc/xdg
XDG_DATA_DIRS           /usr/share/enlightenment:/usr/share:/usr/local/share:/usr/share
XDG_MENU_PREFIX         e-
XDG_RUNTIME_DIR         /run/user/1000
XDG_SEAT                seat0
E_PREFIX                /usr
E_RESTART               1
E_SCALE                 1.000
E_START                 enlightenment_start
E_START_TIME            1503499246.8
E_TAINTED               NO
EDITOR                  vi
HOME                    /home/user
LANG                    en_GB.UTF-8
LD_LIBRARY_PATH         /usr/lib64/R/lib:/usr/lib/jvm/java-7-openjdk/jre/lib/amd64/server
LINES                   58
LN_S                    ln -s
LOGNAME                 user
M2                      /opt/maven//bin
M2_HOME                 /opt/maven/
MAIL                    /var/spool/mail/user
MAKE                    make
MAVEN_OPTS              -Xmx512m
MOZ_PLUGIN_PATH         /usr/lib/mozilla/plugins
PAGER                   /usr/bin/less
PANTS                   ON
PATH                    /opt/maven//bin:/home/user/Applications/.bin:/usr/bin:/opt/maven//bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
PWD                     /home/user
QT_QPA_PLATFORMTHEME    gtk2
QT_STYLE_OVERRIDE       gtk2
R_ARCH                  
R_BROWSER               /usr/bin/xdg-open
R_BZIPCMD               /usr/bin/bzip2
R_DOC_DIR               /usr/share/doc/R/
R_GZIPCMD               /usr/bin/gzip
R_HOME                  /usr/lib64/R
R_INCLUDE_DIR           /usr/include/R/
R_LIBS_SITE             
R_LIBS_USER             ~/R/x86_64-pc-linux-gnu-library/3.4
R_PAPERSIZE             a4
R_PDFVIEWER             /usr/bin/xdg-open
R_PLATFORM              x86_64-pc-linux-gnu
R_PRINTCMD              
R_RD4PDF                times,inconsolata,hyper
R_SESSION_TMPDIR        /tmp/RtmpXBvepb
R_SHARE_DIR             /usr/share/R/
R_SYSTEM_ABI            linux,gcc,gxx,gfortran,?
R_TEXI2DVICMD           /usr/bin/texi2dvi
R_UNZIPCMD              /usr/bin/unzip
R_ZIPCMD                /usr/bin/zip
SED                     /usr/bin/sed
SHELL                   /bin/bash
SHLVL                   3
TAR                     /usr/bin/tar
TERM                    xterm
USER                    user
WINDOWPATH              1
XAUTHORITY              /home/user/.Xauthority
XDG_CONFIG_DIRS         /usr/etc/xdg:/etc/xdg
XDG_DATA_DIRS           /usr/share/enlightenment:/usr/share:/usr/local/share:/usr/share
XDG_MENU_PREFIX         e-
XDG_RUNTIME_DIR         /run/user/1000
XDG_SEAT                seat0
XDG_SESSION_ID          c1
XDG_VTNR                1
XMODIFIERS              @im=ibus

Программного обеспечения

Версия R 3.4.1; система Arch Arch.

[user@system ~]$ uname -a
Linux system 4.11.9-1-ARCH #1 SMP PREEMPT Wed Jul 5 18:23:08 CEST 2017 x86_64 GNU/Linux

score 3 · Answer 1 · 2011-03-09T19:38:42

Файловые системы tmpfs растут по требованию, поэтому "общий размер", который вы видите, является лишь пределом емкости - если не указано иное во время монтирования, предел по умолчанию равен 50% физической памяти. (Это не означает, что tmpfs заблокирован в физической памяти; его можно выгружать.)

Тем не менее, обратите внимание , что одна файловой системы /dev/shm сообщают 7,6 ГБ используется (т.е. заполнен до предела). Это место, где хранятся сегменты SHM (разделяемая память - функция межпроцессного взаимодействия), хотя иногда программы также напрямую создают разные файлы.

Сегменты SHM устойчивы; если программа выходит без явного удаления, они останутся без изменений. Так что, если ваши предыдущие прогоны продолжали настраивать SHM, а затем приводить к сбою, это могло бы легко заполнить половину вашей оперативной памяти и оставить только ~ 8 ГБ для новых программ.

(И наоборот, поскольку емкость /dev/shm по умолчанию составляет 50% физической памяти, общий размер всех сегментов SHM ограничен 7,6 ГБ. Я сомневаюсь, что это уместно здесь - я был бы очень удивлен, если программа законно нужна сегмент SHM, который большой.)

Чтобы очистить /dev /shm, вы можете а) перезагрузиться или б) аккуратно удалить найденные там файлы, используя обычный старый rm . Но сначала всегда используйте lsof чтобы убедиться, что они не используются.

Или увеличьте ограничение размера, используя:

mount -o remount,size=90% /dev/shm

(Как примечание, вы используете довольно старое ядро для Arch Linux - текущая версия 4.12.8, если вы не используете linux-lts.)

score 3 · Accepted Answer · 2011-03-09T19:38:42

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

Причина в том, что заполнение /dev/shm не вызвано каким-либо другим процессом, поэтому его можно легко освободить для использования пакетом R , но вместо этого оно вызывается модулем big.memory внутри самого R ! Таким образом, освобождение /dev/shm равносильно убийству R.

На странице 1 руководства по пакету Bigmemory указано:

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

Это проясняет важный момент: вы не можете ожидать использования всей своей памяти с помощью big.memory, только той части, которая выделена для /dev/shm, что обычно составляет половину от общего объема доступной памяти. Если вы хотите увеличить или уменьшить shm, измените соответствующую строку в /etc/fstab и перезагрузите компьютер.

Можно смело предположить, что заполнение /dev/shm связано с R. На самом деле, в посте ОП четко говорится, что в то время не было запущено никаких других программ,

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

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

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

bx <- big.matrix(45070,45070)

имеет 45070 x 45070 > 2 миллиардов элементов. Во-вторых, согласно руководству R,

R не имеет данных с одинарной точностью. Все действительные числа хранятся в формате двойной точности

а потом

Все платформы R должны работать со значениями, соответствующими стандарту IEC 60559 (также известному как IEEE 754).

....

В IEEE 754-2008/IEC60559:2011 это называется форматом «binary64».

и статья в Википедии о формате бинарных 64 четко гласит:

Формат с плавающей запятой двойной точности - это формат чисел компьютера, который занимает 8 байтов (64 бита) в памяти компьютера.

Таким образом, ваши более 2 миллиардов элементов, каждый из которых занимает 8 байтов, хотели бы занимать более 16 миллиардов байтов памяти, что примерно в два раза больше, чем ваш /dev/shm (где big.memory хотел бы их хранить, см. Выше). ), есть в наличии. Отсюда вылет и сообщение об ошибке:

прерывание вызывается после создания экземпляра 'boost::interprocess::interprocess_exception' what(): на устройстве не осталось места

Это сообщение об ошибке из библиотек Boost C++ относится к классу функций, которые:

Увеличение.Interprocess предлагает несколько базовых классов для создания объектов общей памяти и сопоставлений файлов и сопоставления этих сопоставляемых классов с адресным пространством процесса.

Что касается сбоя вашей системы после дампа памяти R, это хорошо объясняется гравитацией, в которой /dev/shm не был очищен, и все процессы, которые используют разделяемую память (например, все, использующие динамические библиотеки), завершатся с ошибкой из-за нехватка места на устройстве: самый простой вариант - перезагрузить компьютер.

Какие у вас варианты? Во-первых, возможно, вы можете установить 32 гигабайта памяти, что приведет к серьезным затруднениям. Или вы можете увидеть, действительно ли ваша матрица требует так много элементов: например, симметричные матрицы содержат чуть больше половины элементов несимметричной матрицы, и вам просто нужно немного увеличить /dev/shm , Или, возможно, вы имеете дело с разреженной матрицей, которую было бы еще проще сжать, чем симметричной матрицей.

Другими словами, вам придется взглянуть на некоторые детали матрицы и найти решение, адаптированное к вашей конкретной ситуации.

Сейчас выбран русский

Процесс в Arch Linux не хватает памяти на 7,6 ГБ, несмотря на 16 ГБ ОЗУ с последующими ошибками шины

2 ответа2

Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux memory arch-linux r bus.

Процесс в Arch Linux не хватает памяти на 7,6 ГБ, несмотря на 16 ГБ ОЗУ с последующими ошибками шины

2 ответа2

Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux memory arch-linux r bus.

Похожие