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
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/shm
zgł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/shm
wynosi 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,lsof
aby upewnić się, że nie są w użyciu.Możesz również zwiększyć limit rozmiaru, używając:
(Na marginesie, używasz raczej starego jądra dla Arch Linux - obecna wersja to 4.12.8, chyba że używasz linux-lts.)
źródło
/run
system plików wymieniony w pytaniu wymaga jedynie 788 KB (+ trochę narzutu) pamięci. Instancje tmpfs przeważnie są darmowe pod każdym względem, naprawdę.