Processo no Arch Linux ficando sem memória a 7.6GB, apesar de 16GB de RAM, seguido por erros de barramento

Question

Eu tento usar um grande pedaço de memória em R, de um tamanho de cerca de 7,6 GB. Meu sistema tem 16 GB de RAM, então eu não esperava que isso fosse um problema. No entanto, R evita isso, e tentar contorná-lo leva a grandes quedas de R e vários outros aplicativos (navegadores da web). O sistema relatou problemas no barramento, mas eu não tenho mensagens de erro exatas desde que o sistema eventualmente falhou.

Minha pergunta é: o que aconteceu? Como posso evitar isso e alocar mais memória em R (ou qualquer aplicativo)?

Tenho a sensação de que isso pode estar relacionado a quanta memória é endereçável, não à memória teoricamente disponível.

Detalhes

Eu tentei usar um pedaço maior de memória em R, uma matriz com 1 bilhão de entradas, cerca de 7,6 GB. R não permite facilmente vetores / matrizes desse tamanho, embora não esteja claro para mim, por quê. (Isso resulta em Error: cannot allocate vector of size 7.6 Gb ) No entanto, R tem bibliotecas como bigmemory que supostamente são capazes de lidar com vetores grandes. Do intérprete de 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: 

So R caiu, mas pode ser salvo escolhendo 2 e cancelando a saída. Pode não ter sido muito inteligente tentar o mesmo novamente, mas de qualquer forma, aqui vamos nós:

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)

No log do diário, é assim:

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.

Consequências em todo o sistema

No momento, nem um ambiente de desktop nem aplicativos gráficos estavam sendo executados. Eu comecei o gerenciador de janelas e um navegador para procurar o que estava acontecendo. Para meu horror, descobri que nem o Firefox, nem o Opera nem o Chromium começariam. As mensagens de erro disseram algo sobre erros de barramento, mas eu não tenho mensagens de erro exatas desde que o sistema eventualmente caiu. É notável que outros aplicativos, mesmo os maiores, como o libreoffice, possam ser iniciados sem problemas. Será que isso tem algo a ver com os endereços necessários para estabelecer conexões de rede? Será que o sistema estava de alguma forma fora dos endereços depois que o R caiu? (Eu não entendo, no entanto, por que isso persistiria após o processo R morrer).

No log do diário, é semelhante a isso (rastreamentos longos da pilha truncados):

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)

Eu então tentei reiniciar o dbus (que também não foi o movimento mais inteligente e travou o sistema).

Outros aspectos

Antes do sistema travar, eu também percebi o seguinte:

[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 ~]$ 

Por que os sistemas de arquivos virtuais (dev, run, tmpfs) são todos de tamanho 7.6GB, exatamente o que R não alocaria?

Eu verifiquei que é possível alocar até 6,7 GB em R, mas em algum lugar abaixo de 7,6 GB há um limite. Não há memória máxima definida em R ou no sistema:

[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

... e no interpretador 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

Software

A versão R é 3.4.1; o sistema é o Arch Linux.

[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

    

Answer 1

Esta é uma das poucas ocasiões em que discordo de grawity , cujas respostas são sempre esclarecedoras, para muitos e também certamente para mim.

O motivo é que o preenchimento de / dev / shm é não causado por algum outro processo, para que possa ser facilmente liberado para uso pelo > R , mas é causado pelo módulo big.memory dentro do próprio R / dev / shm equivale a matar R .

O manual do pacote bigmemory indica, na página 1:

Description: Create, store, access, and manipulate massive matrices. Matrices are allocated to shared memory and may use memory-mapped files.

Isso esclarece um ponto importante: você não pode esperar usar toda a sua memória usando big.memory , apenas a parte alocada para / dev / shm , que é tipicamente metade da memória total que você tem disponível. Se você quiser aumentar ou diminuir shm , modifique a linha relevante em / etc / fstab e reinicie.

Podemos seguramente assumir que o preenchimento de / dev / shm é devido a R . Na verdade, o post do OP afirma claramente que não havia outros programas em execução no momento,

At this time, neither a desktop environment nor any graphical applications were running.

, então é difícil imaginar o que mais ( isto é, , além de R ) engolir um pedaço tão grande de memória compartilhada.

Na verdade, também é fácil entender a raiz do problema. Primeiro de tudo, sua matriz

bx <- big.matrix(45070,45070)

tem 45070 x 45070 > 2 bilhões de elementos. Em segundo lugar, de acordo com o manual R ,

R has no single precision data type. All real numbers are stored in double precision format

e depois

All R platforms are required to work with values conforming to the IEC 60559 (also known as IEEE 754) standard.

....

In IEEE 754-2008/IEC60559:2011 this is called ‘binary64’ format.

e o artigo da Wikipedia no formato binary64 afirma claramente:

Double-precision floating-point format is a computer number format that occupies 8 bytes (64 bits) in computer memory.

Assim, seus mais de 2 bilhões de elementos, cada um ocupando 8 bytes, gostariam de ocupar mais de 16 bilhões de bytes de memória, o que é aproximadamente o dobro do seu / dev / shm (< em> big.memory gostaria de armazená-los, veja acima), tem disponível. Daí a falha e a mensagem de erro:

terminate called after throwing an instance of 'boost::interprocess::interprocess_exception' what(): No space left on device

Esta mensagem de erro, das bibliotecas Boost C ++ , pertence a uma classe de funções que:

Boost.Interprocess offers some basic classes to create shared memory objects and file mappings and map those mappable classes to the process' address space.

Quanto ao seu sistema falhar após o core dump R , é bem explicado por grawity , em que / dev / shm não foram limpas, e todos os processos que usam memória compartilhada (como tudo usando bibliotecas dinâmicas, por exemplo) falharão devido à falta de espaço no dispositivo: sua opção mais fácil é reinicializar.

Quais são suas opções? Primeiro, talvez você possa instalar 32GiB de memória, o que iria forçar sua situação atual. Ou, você pode ver se sua matriz realmente requer tantos elementos: por exemplo, matrizes simétricas contêm apenas um pouco mais da metade dos elementos de uma matriz não-simétrica, e você só precisa aumentar / dev / shm um pouco. Ou talvez você esteja lidando com uma matriz esparsa, que seria ainda mais fácil de comprimir do que uma matriz simétrica.

Em outras palavras, você terá que olhar para alguns dos detalhes da matriz e encontrar uma solução adaptada à sua situação concreta.

    

Answer 2

Os sistemas de arquivos tmpfs crescem sob demanda, então o "tamanho total" que você vê é apenas o limite de capacidade - a menos que especificado de outra forma no momento da montagem, o limite padrão é igual a 50% da memória física. (Isso não significa que o tmpfs está bloqueado na memória física; ele pode ser trocado).

No entanto, observe que um sistema de arquivos, /dev/shm , está relatando 7,6 GB usado (isto é, preenchido até o limite). Esse local é onde os segmentos SHM (memória compartilhada - um recurso de comunicação entre processos) são mantidos, embora às vezes os programas criem arquivos diversos diretamente também.

Os segmentos SHM são persistentes; Se um programa sair sem explicitamente removê-lo, ele ficará por perto. Portanto, se suas execuções anteriores continuarem configurando o SHM e depois travando, isso pode facilmente ocupar metade da sua RAM e deixar apenas ~ 8 GB para novos programas.

(E vice-versa, como a capacidade padrão de /dev/shm é 50% da memória física, o tamanho total de todos os segmentos SHM é limitado a 7,6 GB. Duvido que seja relevante aqui - ficaria muito surpreso se um programa legitimamente precisava de um segmento SHM tão grande.)

Para limpar / dev / shm, você pode a) reinicializar, ou b) cuidadosamente remover arquivos encontrados lá usando o antigo rm . Mas primeiro use sempre lsof para garantir que eles não estejam em uso.

Alternativamente, aumente o limite de tamanho usando:

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

(Como uma nota lateral, você está executando um kernel bastante antigo para o Arch Linux - a versão atual é 4.12.8, a menos que você execute o linux-lts.)