Przetwarzaj w Arch Linux z brakiem pamięci na poziomie 7,6 GB pomimo 16 GB pamięci RAM, a następnie wystąpią błędy magistrali

Próbuję użyć dużej części pamięci w R, o wielkości około 7,6 GB. Mój system ma 16 GB pamięci RAM, więc nie spodziewałem się, że będzie to problem. Jednak R zapobiega temu, a próba obejścia tego prowadzi do ogromnych awarii R i różnych innych aplikacji (przeglądarek internetowych). System zgłosił problemy z magistralą, ale nie mam dokładnych komunikatów o błędach, ponieważ system ostatecznie się zawiesił.

Moje pytanie brzmi: co się stało? Jak mogę temu zapobiec i przydzielić więcej pamięci w R (lub dowolnej aplikacji)?

Mam wrażenie, że może to być związane z ilością adresowalnej pamięci, a nie z pamięcią, która jest teoretycznie dostępna.

Detale

Próbowałem użyć większej części pamięci w R, macierzy z 1 miliardem wpisów, około 7,6 GB. R nie pozwala na łatwe wektory / macierze o tym rozmiarze, choć nie jest dla mnie jasne, dlaczego. (Powoduje to Error: cannot allocate vector of size 7.6 Gb) Jednak R ma biblioteki takie jak bigmemory, które podobno są w stanie radzić sobie z dużymi wektorami. Z tłumacza 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: 

Więc R rozbił się, ale można go uratować, wybierając 2 i anulując wyjście. Może nie było to zbyt mądre, aby spróbować ponownie, ale tak czy inaczej, zaczynamy:

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)

Z dziennika dziennika wygląda to tak:

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.

Konsekwencje dla całego systemu

W tej chwili nie działało ani środowisko pulpitu, ani żadna aplikacja graficzna. Uruchomiłem menedżera okien i przeglądarkę, aby sprawdzić, co się dzieje. Ku mojemu przerażeniu odkryłem, że ani Firefox, ani Opera, ani Chromium nie uruchomią się. Komunikaty o błędach mówiły coś o błędach magistrali, ale nie mam dokładnych komunikatów o błędach, ponieważ system ostatecznie się zawiesił. Warto zauważyć, że inne aplikacje, nawet te większe, takie jak libreoffice, można uruchomić bez problemów. Czy to możliwe, że ma to związek z adresami potrzebnymi do nawiązania połączeń sieciowych? Czy to możliwe, że po awarii R system nie miał adresów? (Nie rozumiem jednak, dlaczego miałoby to trwać po śmierci procesu R.)

Z dziennika dziennika wygląda to tak (obcięte ślady długiego stosu):

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)

Następnie spróbowałem zrestartować dbus (co również nie było najmądrzejszym ruchem i spowodowało awarię systemu).

Inne aspekty

Zanim system się zawiesił, zdałem sobie sprawę, że:

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

Dlaczego wirtualne systemy plików (dev, run, tmpfs) mają rozmiar 7,6 GB, dokładnie to, czego R nie przydzieliłby?

Sprawdziłem, że można przydzielić aż 6,7 GB w R, ale gdzieś poniżej 7,6 GB istnieje limit. Nie ustawiono maksymalnej pamięci w R ani w systemie:

[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

... i w tłumaczu 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

Oprogramowanie

Wersja R to 3.4.1; system to 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

To jedna z niewielu okazji, w których nie zgadzam się z grawitacją , której odpowiedzi są zawsze pouczające dla wielu, a także dla mnie na pewno.

Powodem jest to, że wypełnienie / dev / shm nie jest spowodowane przez jakiś inny proces, więc można go łatwo zwolnić do użycia przez pakiet R , ale zamiast tego jest spowodowane przez moduł big.memory wewnątrz samego R ! Więc uwalniając / dev / shm jest równoznaczne z zabijania R .

W podręczniku bigmemory znajduje się instrukcja na stronie 1:

Opis : Twórz, przechowuj, uzyskuj dostęp i manipuluj potężnymi matrycami. Macierze są przydzielane do pamięci współużytkowanej i mogą wykorzystywać pliki mapowane w pamięci.

Wyjaśnia to ważną kwestię: nie można oczekiwać, że wykorzystasz całą swoją pamięć, używając big.memory , tylko część przydzieloną do / dev / shm , która zazwyczaj stanowi połowę całkowitej dostępnej pamięci. Jeśli chcesz powiększyć lub zmniejszyć shm , zmień odpowiednią linię w / etc / fstab i uruchom ponownie.

Możemy spokojnie założyć, że wypełnienie się od / dev / shm wynika z badań . W rzeczywistości stanowisko PO wyraźnie stwierdza, że ​​w tym czasie nie były uruchomione żadne inne programy,

W tej chwili nie działało ani środowisko pulpitu, ani żadna aplikacja graficzna.

, Więc trudno sobie wyobrazić, co innego ( tzn oprócz R ) może być połykanie się taki duży fragment pamięci współdzielonej.

W rzeczywistości łatwo jest zrozumieć źródło problemu. Przede wszystkim twoja matryca

bx <- big.matrix (45070,45070)

ma 45070 x 45070 > 2 miliardy elementów. Po drugie, według instrukcji R ,

R nie ma żadnego typu danych o pojedynczej precyzji. Wszystkie liczby rzeczywiste są przechowywane w formacie podwójnej precyzji

i wtedy

Wszystkie platformy R muszą pracować z wartościami zgodnymi z normą IEC 60559 (znaną również jako IEEE 754).

....

W IEEE 754-2008 / IEC60559: 2011 nazywa się to formatem „binary64”.

a artykuł w Wikipedii na temat formatu binary64 wyraźnie stwierdza:

Format zmiennoprzecinkowy podwójnej precyzji to format liczb komputerowych, który zajmuje 8 bajtów (64 bity) w pamięci komputera.

Tak więc twoje ponad 2 miliardy elementów, każdy zajmujący 8 bajtów, chciałby zająć ponad 16 miliardów bajtów pamięci, co stanowi około dwa razy więcej niż twój / dev / shm (gdzie big.memory chciałby je przechowywać, patrz wyżej ), ma dostępne. Stąd awaria i komunikat o błędzie:

terminate wywoływane po zgłoszeniu wystąpienia „boost :: interprocess :: interprocess_exception” what (): Brak miejsca na urządzeniu

Ten komunikat o błędzie, z boost C ++ bibliotek , odnosi się do klasy funkcji, które:

Boost.Interprocess oferuje podstawowe klasy do tworzenia obiektów pamięci współużytkowanej i mapowań plików oraz mapowania tych klas mapowalnych na przestrzeń adresową procesu.

Jeśli chodzi o awarię systemu po zrzutie rdzenia R , dobrze to wyjaśnia grawitacja , ponieważ / dev / shm nie został wyczyszczony, a wszystkie procesy korzystające z pamięci współużytkowanej (jak na przykład wszystko korzystające z bibliotek dynamicznych) zakończą się niepowodzeniem z powodu brak miejsca na urządzeniu: najłatwiej jest zrestartować komputer.

Jakie masz opcje? Po pierwsze, być może uda ci się zainstalować 32GiB pamięci, co brutalnie wymusiłoby twoje obecne położenie. Albo, możesz sprawdzić, czy matryca rzeczywiście wymaga tak wiele elementów: na przykład, macierze symetryczne zawierać tylko trochę więcej niż połowa elementów niesymetrycznej matrycy, i wystarczy, aby powiększyć / dev / SHM trochę . A może masz do czynienia z macierzą rzadką, która byłaby jeszcze łatwiejsza do kompresji niż macierz symetryczna.

Innymi słowy, będziesz musiał spojrzeć na niektóre szczegóły matrycy i znaleźć rozwiązanie dostosowane do konkretnej sytuacji.

Systemy plików tmpfs rosną na żądanie, więc „całkowity rozmiar”, jaki widzisz, jest tylko limitem pojemności - chyba że w czasie montowania określono inaczej, domyślny limit wynosi 50% pamięci fizycznej. (Nie oznacza to, że tmpfs jest zablokowany w pamięci fizycznej; można go wymienić).

Zauważ jednak, że jeden system plików /dev/shmzgłasza 7,6 GB wykorzystanego (tj. Zapełnionego do granic możliwości). To miejsce, w którym przechowywane są segmenty SHM (pamięć współdzielona - funkcja komunikacji między procesami), chociaż czasami programy również bezpośrednio tam tworzą różne pliki.

Segmenty SHM są trwałe; jeśli program zakończy działanie bez wyraźnego ich usunięcia, pozostanie w pobliżu. Więc jeśli twoje poprzednie testy ciągle konfigurowały SHM, a następnie powodowały awarie, mogło to z łatwością wypełnić połowę pamięci RAM i pozostawić tylko ~ 8 GB nowym programom.

(I odwrotnie, ponieważ domyślna pojemność /dev/shmwynosi 50% pamięci fizycznej, całkowity rozmiar wszystkich segmentów SHM jest ograniczony do 7,6 GB. Wątpię, czy ma to znaczenie w tym przypadku - byłbym bardzo zaskoczony, gdyby program słusznie potrzebował segmentu SHM, który duży.)

Aby wyczyścić / dev / shm, możesz a) uruchomić ponownie komputer lub b) ostrożnie usunąć pliki znalezione tam przy użyciu zwykłego starego rm. Ale najpierw zawsze używaj, lsofaby upewnić się, że nie są w użyciu.

Możesz również zwiększyć limit rozmiaru, używając:

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

(Na marginesie, używasz raczej starego jądra dla Arch Linux - obecna wersja to 4.12.8, chyba że używasz linux-lts.)