Prozess on on Arch Linux läuft bei 7.6 GB trotz 16 GB RAM, gefolgt von Busfehlern, zu wenig Speicher

909
0range

Ich versuche, einen großen Speicherplatz in R mit einer Größe von etwa 7,6 GB zu verwenden. Mein System verfügt über 16 GB RAM, daher habe ich nicht erwartet, dass dies ein Problem sein wird. R verhindert dies jedoch, und der Versuch, es zu umgehen, führt zu massiven Abstürzen von R und verschiedenen anderen Anwendungen (Webbrowsern). Das System hat Busprobleme gemeldet, aber ich habe keine genauen Fehlermeldungen, da das System schließlich abgestürzt ist.

Meine Frage ist: Was ist passiert? Wie kann ich dies verhindern und mehr Speicherplatz in R (oder einer anderen Anwendung) zuweisen?

Ich habe das Gefühl, dass es damit zusammenhängt, wie viel Speicher adressiert werden kann, und nicht der theoretisch verfügbare Speicher.

Einzelheiten

Ich habe versucht, einen größeren Speicherbereich in R zu verwenden, eine Matrix mit 1 Milliarde Einträgen, etwa 7,6 GB. Vektoren / Matrizen dieser Größe lassen sich von R nicht ohne weiteres zulassen, obwohl mir nicht klar ist, warum. (Daraus ergibt sich Error: cannot allocate vector of size 7.6 Gb) R hat jedoch Bibliotheken wie Bigmemory, die angeblich in der Lage sind, mit großen Vektoren umzugehen. Vom R-Dolmetscher:

> 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:

Also stürzte R ab, aber es kann gespeichert werden, indem Sie 2 wählen und den Abbruch abbrechen. Es war vielleicht nicht sehr klug, das gleiche noch einmal zu versuchen, aber trotzdem, los geht'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)

Aus dem Journal-Protokoll sieht es so aus:

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.

Systemweite Konsequenzen

Zu diesem Zeitpunkt wurden weder eine Desktop-Umgebung noch grafische Anwendungen ausgeführt. Ich habe den Fenstermanager und einen Browser gestartet, um nachzusehen, was passiert ist. Zu meinem Entsetzen fand ich heraus, dass weder Firefox noch Opera oder Chromium starten würde. Die Fehlermeldungen besagten etwas über Busfehler, aber ich habe keine genauen Fehlermeldungen, da das System schließlich abgestürzt ist. Es ist bemerkenswert, dass andere Anwendungen, auch größere, wie libreoffice, problemlos gestartet werden können. Könnte es sein, dass dies etwas mit Adressen zu tun hat, die zum Herstellen von Netzwerkverbindungen benötigt werden? Könnte es sein, dass das System nach dem Absturz von R aus irgendeinem Grund keine Adressen mehr hatte? (Ich verstehe jedoch nicht, warum dies nach dem Tod des R-Prozesses bestehen bleiben würde.)

Aus dem Journal-Protokoll sieht es folgendermaßen aus (lange Stapelspuren abgeschnitten):

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)

Ich habe dann versucht, dbus neu zu starten (was auch nicht der klügste Schritt war, und stürzte das System ab).

Weitere Aspekte

Bevor das System abstürzte, erkannte ich auch Folgendes:

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

Warum sind die virtuellen Dateisysteme (dev, run, tmpfs) alle in der Größe 7,6 GB, genau was R nicht zuordnen würde?

Ich habe bestätigt, dass es möglich ist, bis zu 6,7 GB in R zuzuteilen, aber irgendwo unter 7,6 GB gibt es ein Limit. In R oder im System ist kein maximaler Speicher eingestellt:

[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

... und im R-Dolmetscher:

> 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

R-Version ist 3.4.1; Das System ist 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
1

2 Antworten auf die Frage

3
grawity

Die Dateisysteme von tmpfs wachsen bei Bedarf, daher ist die "Gesamtgröße" nur das Kapazitätslimit. Sofern nicht beim Einhängen anders angegeben, beträgt das Standardlimit 50% des physischen Speichers. (Dies bedeutet nicht, dass tmpfs im physischen Speicher gesperrt ist; es kann ausgelagert werden.)

Beachten Sie jedoch, dass ein Dateisystem, /dev/shm7,6 GB verwendet (dh bis zum Limit gefüllt) meldet . An diesem Speicherort werden SHM-Segmente (Shared Memory - eine Funktion zur Kommunikation zwischen Prozessen) aufbewahrt, obwohl Programme dort manchmal auch verschiedene Dateien direkt erstellen.

SHM-Segmente sind persistent. Wenn ein Programm beendet wird, ohne sie explizit zu entfernen, bleibt es in der Nähe. Wenn also Ihre vorherigen Läufe weiterhin SHM einrichteten und dann abstürzten, könnte dies leicht die Hälfte Ihres Arbeitsspeichers füllen und nur noch ~ 8 GB neuen Programmen überlassen.

(Und umgekehrt, da die Standardkapazität /dev/shm50% des physischen Speichers beträgt, ist die Gesamtgröße aller SHM-Segmente auf 7,6 GB begrenzt. Ich bezweifle, dass dies hier relevant ist - ich wäre sehr überrascht, wenn ein Programm ein SHM-Segment dazu legitimiert hätte groß.)

Um / dev / shm zu bereinigen, könnten Sie a) einen Neustart durchführen oder b) die dort gefundenen Dateien vorsichtig mit Hilfe von old entfernen rm. Aber zuerst immer verwendenlsof Sie, um sicherzustellen, dass sie nicht verwendet werden.

Erhöhen Sie alternativ die Größenbegrenzung mit:

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

(Als Randbemerkung betreiben Sie einen ziemlich alten Kernel für Arch Linux - die aktuelle Version ist 4.12.8, sofern Sie nicht linux-lts ausführen.)

Mit "grow on demand" meint er alles, was für das in der Frage angegebene `/ run'-Dateisystem nur 788 KB (+ etwas Overhead) Speicher benötigt. tmpfs-Instanzen sind in Bezug auf alles wirklich kostenlos. Daniel B vor 6 Jahren 0
Ich glaube, das ist nicht ganz richtig: Das Bigmemory-Paket ** verwendet ** tatsächlich Shared Memory für die Handhabung der großen Matrizen. Dies ist, was es bis zum Rand ausfüllt und letztendlich den Absturz verursacht. Bitte lesen Sie meine Antwort unten. MariusMatutiae vor 6 Jahren 0
3
MariusMatutiae

Dies ist eine der wenigen Gelegenheiten, bei denen ich mit der Großartigkeit nicht einverstanden bin, deren Antworten immer aufschlussreich sind, für viele und auch für mich sicherlich.

Der Grund dafür ist, dass die Füllung aus / dev / shm ist nicht von einem anderen Prozess verursacht, so dass es leicht für die Verwendung durch das befreit werden können R - Paket, sondern wird es durch das verursacht big.memory Modul innerhalb R selbst! So befreien / dev / shm ist gleichbedeutend mit der Tötung R .

Das Bigmemory-Pakethandbuch heißt auf Seite 1:

Beschreibung : Erstellen, Speichern, Zugreifen und Bearbeiten massiver Matrizen. Matrizen werden dem gemeinsam genutzten Speicher zugewiesen und können speicherzugeordnete Dateien verwenden.

Dies verdeutlicht einen wichtigen Punkt: Sie können nicht erwarten, dass Sie Ihren gesamten Speicher verwenden, indem Sie big.memory verwenden, nur den Teil, der / dev / shm zugewiesen ist. Dies ist in der Regel die Hälfte des gesamten verfügbaren Speichers. Wenn Sie shm vergrößern oder verkleinern möchten, ändern Sie die entsprechende Zeile in / etc / fstab und führen Sie einen Neustart durch.

Wir können sicher davon ausgehen, dass das Auffüllen von / dev / shm auf R zurückzuführen ist . Tatsächlich heißt es in der OP-Stelle eindeutig, dass zu diesem Zeitpunkt keine anderen Programme laufen.

Zu diesem Zeitpunkt wurden weder eine Desktop-Umgebung noch grafische Anwendungen ausgeführt.

Daher ist es schwer vorstellbar, was sonst ( dh abgesehen von R ) einen so großen Teil des gemeinsamen Speichers verschluckt.

In der Tat ist es auch leicht, die Wurzel des Problems zu verstehen. Zuallererst deine Matrix

bx <- big.matrix (45070,45070)

hat 45070 x 45070 > 2 Milliarden Elemente. Zweitens gemäß der R Handbuch ,

R hat keinen Datentyp mit einfacher Genauigkeit. Alle reellen Zahlen werden im doppelten Genauigkeitsformat gespeichert

und dann

Alle R-Plattformen müssen mit Werten arbeiten, die der Norm IEC 60559 (auch als IEEE 754 bekannt) entsprechen.

....

In IEEE 754-2008 / IEC60559: 2011 wird dies als 'binary64' Format bezeichnet.

und der Wikipedia-Artikel über das binary64-Format besagt eindeutig:

Das Fließkommaformat mit doppelter Genauigkeit ist ein Computernummernformat, das 8 Byte (64 Bit) im Computerspeicher belegt.

Daher möchten Ihre mehr als 2 Milliarden Elemente, die jeweils 8 Bytes einnehmen, mehr als 16 Milliarden Bytes an Speicher beanspruchen, was ungefähr doppelt so groß ist wie Ihr / dev / shm (wo big.memory sie speichern möchte, siehe oben) ) hat zur Verfügung. Daher der Absturz und die Fehlermeldung:

terminate aufgerufen, nachdem eine Instanz von "boost :: interprocess :: interprocess_exception" geworfen wurde what (): Kein Platz mehr auf dem Gerät

Diese Fehlermeldung von den Boost C ++ Bibliotheken, bezieht sich auf eine Klasse von Funktionen, die:

Boost.Interprocess bietet einige grundlegende Klassen zum Erstellen von Shared Memory-Objekten und Dateizuordnungen und zum Zuordnen dieser zuweisbaren Klassen zum Adressraum des Prozesses.

Wenn Ihr System nach dem R- Core-Dump ausfällt, ist dies gut durch grawity zu erklären, da / dev / shm nicht bereinigt wurde und alle Prozesse, die Shared Memory verwenden (wie beispielsweise alles, was dynamische Bibliotheken verwendet), aufgrund von fehlschlagen Der Mangel an Speicherplatz auf dem Gerät: Am einfachsten ist ein Neustart.

Welche Möglichkeiten hast du? Zunächst können Sie vielleicht 32 GB Speicher installieren, was Ihre aktuelle Situation brutal erzwingen würde. Oder Sie sehen vielleicht, ob Ihre Matrix wirklich so viele Elemente benötigt: Symmetrische Matrizen enthalten beispielsweise nur etwas mehr als die Hälfte der Elemente einer nicht symmetrischen Matrix, und Sie müssen nur / dev / shm etwas vergrößern . Oder vielleicht haben Sie es mit einer spärlichen Matrix zu tun, die noch einfacher zu komprimieren wäre als eine symmetrische Matrix.

Mit anderen Worten, Sie müssen sich einige Details der Matrix ansehen und eine auf Ihre konkrete Situation zugeschnittene Lösung finden.

Was sind "Busprozesse"? grawity vor 6 Jahren 0
Ah ich sehe. Aber ... Auch wenn Bibliotheken im Speicher gemeinsam genutzt werden, hat dies nichts mit / dev / shm zu tun - der Kernel verwendet das Paging direkt dafür. Der Ordner / dev / shm ist ausschließlich für die IPC-Funktionen von POSIX "shm" bestimmt. grawity vor 6 Jahren 0
Ah ich sehe. Aber ... Auch wenn Bibliotheken im Speicher gemeinsam genutzt werden, hat dies nichts mit / dev / shm zu tun - der Kernel verwendet das Paging direkt dafür. Der Ordner / dev / shm ist ausschließlich für die IPC-Funktionen von POSIX "shm" bestimmt. grawity vor 6 Jahren 0

Verwandte Probleme