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

872
0range

Я пытаюсь использовать большой кусок памяти в 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
1

2 ответа на вопрос

3
grawity

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

Тем не менее, обратите внимание, что одна файловой системы /dev/shm, сообщают 7,6 GB использовал (т.е. заполнен до предела). Это место, где хранятся сегменты 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.)

Под «ростом по требованию» он подразумевает все, что файловой системе `/ run`, указанной в вопросе, требуется всего 788 КБ (+ некоторые накладные расходы) памяти. На самом деле экземпляры tmpfs в основном бесплатны. Daniel B 7 лет назад 0
Я считаю, что это не совсем правильно: пакет bigmemory на самом деле ** использует ** разделяемую память для обработки больших матриц, и это то, что заполняет ее до краев, и в конечном итоге вызывает сбой. Пожалуйста, прочитайте мой ответ ниже. MariusMatutiae 7 лет назад 0
3
MariusMatutiae

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

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

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

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

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

Можно смело предположить, что начинка из / разработчика / ГИМ из - за 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 (): на устройстве не осталось места

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

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

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

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

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

Что такое «шинные процессы»? grawity 7 лет назад 0
Ах я вижу. Но ... Несмотря на то, что библиотеки являются общими в памяти, это не имеет ничего общего с / dev / shm - для этого ядро ​​напрямую использует пейджинг. Папка / dev / shm предназначена исключительно для функций POSIX "shm" IPC. grawity 7 лет назад 0
Ах я вижу. Но ... Несмотря на то, что библиотеки являются общими в памяти, это не имеет ничего общего с / dev / shm - для этого ядро ​​напрямую использует пейджинг. Папка / dev / shm предназначена исключительно для функций POSIX "shm" IPC. grawity 7 лет назад 0

Похожие вопросы