Frage zu SWAP | Sie ist permanent voll | Muss das sein?

Uridium · Montag um 18:25

Swap macht auch bei viel Ram in gewissen Fällen durchaus Sinn, insbesondere wenn man z.B. verhältnismäßig viel Ram für VMs benutzt. Bei Paravirtualisierung und anderen Kernelfunktionen (Device Memory, Drivers, etc) ist es wichtig, dass der Speicher nicht fragmentiert, weil das zu einer abgelehnten Anforderung führen kann, wenn kein ausreichend großer zusammenhängender Speicherbereich vorhanden ist. Im Userspace ist das eher egal, da alles auf den 'virtual address space' gemappt wird.

Auch ist das Linux Speichermanagement ein recht eigenartiges Konstrukt. Programmierer neigen dazu grundsätzlich zu viel Speicher anzufordern (kann ja nicht schaden...), weshalb der Kernel mehr (virtuellen) Speicher genehmigt als physikalisch vorhanden ist (overcommitment). Sollte die spekulative Rechnung nicht aufgehen, kommt der OOM (out-of-memory manager) ins Spiel und kickt Prozesse nach dem 'oom_score' aus dem Speicher. Das Lustige ist, dass das auch das Programm sein kann, das den Speicher in diesem Moment ~~angefordert hat~~ belegen will, den Kernel damit in Bedrängnis bringt, jener den OOM zu Hilfe holt und dann das Programm kickt. Auch hier kann Swap durch Vergrößerung des virtuellen Speichers entgegenwirken.

foofoobar · Montag um 18:30

MonteDrago schrieb:
Also @DHC dann will ich mal versuchen etwas Licht reinzubringen.😉

Ich empfehle stattdessen das Studium der Ausgabe von "sar -h -r 5" und der Erklärung der Werte in der manpage.

Uridium schrieb:
Swap macht auch bei viel Ram in gewissen Fällen durchaus Sinn, insbesondere wenn man z.B. verhältnismäßig viel Ram für VMs benutzt. Bei Paravirtualisierung und anderen Kernelfunktionen (Device Memory, Drivers, etc) ist es wichtig, dass der Speicher nicht fragmentiert, weil das zu einer abgelehnten Anforderung führen kann, wenn kein ausreichend großer zusammenhängender Speicherbereich vorhanden ist. Im Userspace ist das eher egal, da alles auf den 'virtual address space' gemappt wird.

Das kriegt man auch mit normalen User-Space-Prozessen hin, in solchen Fällen fragt man den Support des Herstellers nach entsprechenden Parameteränderungen für das memory-management.

Uridium schrieb:
Auch ist das Linux Speichermanagement ein recht eigenartiges Konstrukt. Programmierer neigen dazu grundsätzlich zu viel Speicher anzufordern (kann ja nicht schaden...), weshalb der Kernel mehr (virtuellen) Speicher genehmigt als physikalisch vorhanden ist (overcommitment). Sollte die spekulative Rechnung nicht aufgehen, kommt der OOM (out-of-memory manager) ins Spiel und kickt Prozesse nach dem 'oom_score' aus dem Speicher. Das Lustige ist, dass das auch das Programm sein kann, das den Speicher in diesem Moment angefordert hat belegen will, den Kernel damit in Bedrängnis bringt, jener den OOM zu Hilfe holt und dann das Programm kickt.

Overcommit kann man abschalten, es gibt aber auch so beschissene (Enterprise)Anwendungen die ganz wunderbar mit permanent >200% overcommit laufen.

Wahrlich blöd isses wenn der oom-killer das balloning oder den multipathd oder ähnliches killt :-)

DHC · Montag um 19:24

MonteDrago schrieb:
Wenn dir Debian bei der Installation nur eine 2GB Swap macht, dann hast du der VM wahrscheinlich auch nur 2GB Ram zugestanden

Das war tatsächlich so.
Ich habe der VM nun 8 GB RAM genehmigt.

Es hat sich etwas getan, was die die einzelnen Programme, Programmteile betrifft, die den meisten RAM (%MEM) benutzen.
Auch Swap wurde etwas genutzt.

Code:

top - 19:20:53 up 18:47,  1 user,  load average: 0,28, 0,12, 0,03
Tasks: 199 total,   1 running, 198 sleeping,   0 stopped,   0 zombie
%CPU(s):  0,5 us,  1,1 sy,  0,0 ni, 98,4 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:   7947,8 total,   3789,9 free,   1243,3 used,   3189,7 buff/cache
MiB Swap:   2048,0 total,   1280,5 free,    767,4 used.   6704,6 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
  15383 firma     20   0  378580 144280   4960 S   0,0   1,8   0:00.38 [celeryd: celer
  15382 privat    20   0  376480 144032   5124 S   0,0   1,8   0:00.38 [celeryd: celer
   4181 35002     20   0 4672664 120804  12328 S   0,5   1,5   5:27.48 java
   4324 firma     20   0  348732 120272  11744 S   0,0   1,5   2:38.05 [celeryd: celer
   3224 privat    20   0  348720 117576  10528 S   0,0   1,4   2:44.80 [celeryd: celer
   3138 35002     20   0 4672664 113216  12136 S   0,5   1,4   5:52.36 java
   3230 privat    20   0  347788  86752   9748 S   0,0   1,1   0:14.26 [celery beat] -
   4331 firma     20   0  347960  86720  11168 S   0,0   1,1   0:14.12 [celery beat] -
   4000 35002     20   0 4664488  61096   9088 S   0,0   0,8   3:09.12 java
   2858 35002     20   0 4664488  58468   8636 S   0,5   0,7   3:35.23 java
    424 root      20   0   67612  23608  22988 S   0,0   0,3   0:02.94 systemd-journal
    949 root      20   0   87776  15320  14604 S   0,0   0,2   0:02.84 winbindd
    961 root      20   0   95100  14816  14572 S   0,0   0,2   0:00.36 smbd
  15129 root      20   0   20176  13060  11068 S   0,0   0,2   0:00.05 sshd-session

Ich habe noch ein swapfile mit 16 GB eingerichtet, dass aktuell aber nicht aktiv ist. Das kann ich bei Bedarf aktivieren.

Ich vermute in dem Fall, dass die Nutzung der Weboberfläche von Paperless so massiv Ressourcen zieht.
Und einmal gestartet, erholt sich das Ganze nicht mehr, selbst wenn man sich in der Weboberfläche abmeldet und das Tab dazu schließt.

foofoobar · Montag um 19:30

DHC schrieb:
Ich vermute in dem Fall, dass die Nutzung der Weboberfläche von Paperless so massiv Ressourcen zieht.
Und einmal gestartet, erholt sich das Ganze nicht mehr, selbst wenn man sich in der Weboberfläche abmeldet und das Tab dazu schließt.

Das ist mittlerweile ziemlich normal, und genau deswegen ist es gut das diese Ressourcen im swap landen.
Lass mal die sar cmds von mir hier währenddessen laufen:

Code:

sar -h -rWS 10

andy_m4 · Montag um 19:37

Uridium schrieb:
weshalb der Kernel mehr (virtuellen) Speicher genehmigt als physikalisch vorhanden ist (overcommitment)

Ergänzung:
Wobei man konfigurieren kann, ob der Memory-Manager overcommitment macht:
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

Uridium schrieb:
ener den OOM zu Hilfe holt und dann das Programm kickt. Auch hier kann Swap durch Vergrößerung des virtuellen Speichers entgegenwirken.

Ja. Genau. Weil meistens will man das ja auf keinen Fall, das einem der OOM-Killer die Entscheidung abnimmt.

DHC · Montag um 19:41

foofoobar schrieb:
Lass mal die sar cmds von mir hier währenddessen laufen:
sar -h -rWS 10

Geht nicht.
Liegt wohl daran, dass da ein Paket nicht installiert ist.
Ich habe Debian 13 Core-Installation. Kein Desktop, nichts. Nur Standardkomponenten und SSH-Server. Und dann nachträglich einige benötigte Pakete installiert.

Code:

@Paperless:~$ systemctl status sysstat
Unit sysstat.service could not be found.
@Paperless:~$ apt search sysstat
isag/stable 12.7.5-2 all
  Interaktive grafische Darstellung der Systemaktivität

libsysstat-qt6-1/stable 1.1.0-1 amd64
  Qt-based interface to system statistics

libsysstat-qt6-1-dev/stable 1.1.0-1 amd64
  Qt-based interface to system statistics (dev)

pgcluu/stable 4.0-1 all
  PostgreSQL performance monitoring and auditing tool

recap/stable 2.1.0-1 all
  Generates reports of various information about the server

sysstat/stable 12.7.5-2 amd64
  Linux-Werkzeuge zur Messung der Systemleistung

Code:

@Paperless:~$ sar -h -rWS 10
Linux 6.12.63+deb13-amd64 (Paperless)   26.01.2026      _x86_64_        (2 CPU)

20:00:55     pswpin/s pswpout/s
20:01:05         0,00      0,00

20:00:55    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
20:01:05         3,0G      6,2G      1,2G     15,9%     29,8M      3,4G      4,3G     16,5%      1,2G      3,3G     45,5M

20:00:55    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
20:01:05        17,3G    757,4M      4,1%    143,4M     18,9%

20:01:05     pswpin/s pswpout/s
20:01:15         0,00      0,00

20:01:05    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
20:01:15         3,0G      6,2G      1,2G     15,9%     29,9M      3,4G      4,3G     16,5%      1,2G      3,3G    292,0k

20:01:05    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
20:01:15        17,3G    757,4M      4,1%    143,3M     18,9%

20:01:15     pswpin/s pswpout/s
20:01:25         0,00      0,00

20:01:15    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
20:01:25         3,0G      6,2G      1,2G     15,9%     29,9M      3,4G      4,3G     16,5%      1,2G      3,3G    180,0k

20:01:15    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
20:01:25        17,3G    757,4M      4,1%    143,3M     18,9%

20:01:25     pswpin/s pswpout/s
20:01:35         0,00      0,00

20:01:25    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
20:01:35         3,0G      6,2G      1,2G     15,9%     29,9M      3,4G      4,3G     16,5%      1,2G      3,3G    188,0k

20:01:25    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
20:01:35        17,3G    757,4M      4,1%    143,3M     18,9%

20:01:35     pswpin/s pswpout/s
20:01:45         0,00      0,00

20:01:35    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
20:01:45         3,0G      6,2G      1,2G     15,9%     29,9M      3,4G      4,2G     16,5%      1,2G      3,3G     84,0k

20:01:35    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
20:01:45        17,3G    757,4M      4,1%    143,3M     18,9%

20:01:45     pswpin/s pswpout/s
20:01:55         0,00      0,00

20:01:45    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
20:01:55         3,0G      6,2G      1,2G     15,9%     29,9M      3,4G      4,2G     16,5%      1,2G      3,3G     36,0k

20:01:45    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
20:01:55        17,3G    757,4M      4,1%    143,3M     18,9%

20:01:55     pswpin/s pswpout/s
20:02:05         0,00      0,00

20:01:55    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
20:02:05         3,0G      6,2G      1,2G     15,9%     29,9M      3,4G      4,2G     16,5%      1,2G      3,3G     36,0k

20:01:55    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
20:02:05        17,3G    757,4M      4,1%    143,3M     18,9%

foofoobar · Montag um 19:58

So sieht das auf einem ziemlich minimalen debian13 aus:

Code:

$ sar
-bash: sar: command not found
$ sudo apt -y install sysstat
Installing:                  
  sysstat

Installing dependencies:
  libsensors-config  libsensors5

Suggested packages:
  lm-sensors  isag

Summary:
  Upgrading: 0, Installing: 3, Removing: 0, Not Upgrading: 0
  Download size: 677 kB
  Space needed: 2.090 kB / 3.051 MB available

Get:1 http://deb.debian.org/debian trixie/main amd64 libsensors-config all 1:3.6.2-2 [16,2 kB]
Get:2 http://deb.debian.org/debian trixie/main amd64 libsensors5 amd64 1:3.6.2-2 [37,5 kB]
Get:3 http://deb.debian.org/debian trixie/main amd64 sysstat amd64 12.7.5-2 [623 kB]
Fetched 677 kB in 0s (2.279 kB/s)
Preconfiguring packages ...
Selecting previously unselected package libsensors-config.
(Reading database ... 82128 files and directories currently installed.)
Preparing to unpack .../libsensors-config_1%3a3.6.2-2_all.deb ...
Unpacking libsensors-config (1:3.6.2-2) ...
Selecting previously unselected package libsensors5:amd64.
Preparing to unpack .../libsensors5_1%3a3.6.2-2_amd64.deb ...
Unpacking libsensors5:amd64 (1:3.6.2-2) ...
Selecting previously unselected package sysstat.
Preparing to unpack .../sysstat_12.7.5-2_amd64.deb ...
Unpacking sysstat (12.7.5-2) ...
Setting up libsensors-config (1:3.6.2-2) ...
Setting up libsensors5:amd64 (1:3.6.2-2) ...
Setting up sysstat (12.7.5-2) ...
Creating config file /etc/default/sysstat with new version
update-alternatives: using /usr/bin/sar.sysstat to provide /usr/bin/sar (sar) in auto mode
Created symlink '/etc/systemd/system/sysstat.service.wants/sysstat-collect.timer' → '/usr/lib/systemd/system/sysstat-collect.timer'.
Created symlink '/etc/systemd/system/sysstat.service.wants/sysstat-rotate.timer' → '/usr/lib/systemd/system/sysstat-rotate.timer'.
Created symlink '/etc/systemd/system/sysstat.service.wants/sysstat-summary.timer' → '/usr/lib/systemd/system/sysstat-summary.timer'.
Created symlink '/etc/systemd/system/multi-user.target.wants/sysstat.service' → '/usr/lib/systemd/system/sysstat.service'.
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for libc-bin (2.41-12) ...
$ sar
Cannot open /var/log/sysstat/sa26: No such file or directory
Please check if data collecting is enabled
$ sar -r 5
Linux 6.12.57+deb13-amd64 (deb13)     01/26/2026     _x86_64_    (6 CPU)

07:54:11 PM kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
07:54:16 PM  12489804  12492040    179580      1,38     19584    220164    102048      0,73    157924    110824       168
07:54:21 PM  12491988  12494208    177420      1,37     19592    220164    102048      0,73    157996    110824        68
^C
Average:     12490896  12493124    178500      1,38     19588    220164    102048      0,73    157960    110824       118
$
$ cat /usr/lib/systemd/system/sysstat-collect.timer
# /usr/lib/systemd/system/sysstat-collect.timer
# (C) 2014 Tomasz Torcz <tomek@pipebreaker.pl>
#
# sysstat-12.7.5 systemd unit file:
#        Activates activity collector every 10 minutes

[Unit]
Description=Run system activity accounting tool every 10 minutes

[Timer]
OnCalendar=*:00/10

[Install]
WantedBy=sysstat.service
$

Ergänzung (Montag um 20:12)

Leg dich wieder hin, du hast kein Speicherproblem!

Ergänzung (Montag um 20:20)

andy_m4 schrieb:
Ja. Genau. Weil meistens will man das ja auf keinen Fall, das einem der OOM-Killer die Entscheidung abnimmt.

Die Alternative ist das es das Programm erwischt was gerade in dem Moment Speicher anfordert wo nix mehr da ist. Und das ist noch zufälliger als der oom-Killer.

andy_m4 · Montag um 20:21

foofoobar schrieb:
Die Alternative ist das es das Programm erwischt was gerade in dem Moment Speicher anfordert wo nix mehr da ist.

Die Alternative ist (wie angedeutet), das man solche Situationen versucht zu vermeiden.

foofoobar · Montag um 20:36

@andy_m4 Donald Knuth sagt: Jedes nicht triviale Programm hat mindestens einen Fehler.

DHC · Montag um 21:09

foofoobar schrieb:
Leg dich wieder hin, du hast kein Speicherproblem!

Jetzt auf einmal nicht mehr.
Siehe erster Post. Da sah das Ganze noch ganz anders aus.
Ich habe aktuell beide Weboberflächen offen und habe da auch schon so einiges gemacht.
Ich werden gleich mal beide Instanzen mit mehreren Dokus zum konsumieren gleichzeitig füttern.

Die letzten Tage war es eben anders, warum auch immer.

Aktuell habe ich halt noch zusätzlich ein swapfile aktiv. Ob das daran liegt. Keine Ahnung,
Ich kann ja noch mal alles neu starten und schauen ob sich wieder etwas ändert.

swapfile muss aktuell manuell aktiviert werden.

Ich habe kein Problem alles noch mal neu zu installieren. Ich habe die beiden Instanzen aktuell ja noch nicht im Produktiveinsatz.
Dann mache ich die Partitionierung manuell. Swap dann entsprechend groß wählen. Speicher habe ich mehr als genug. Das ist kein Problem.

Ergänzung (Montag um 21:12)

Beide Instanzen werden gerade mit jeweils 20 PDFs gleichzeitig gefüttert.
Der Ressourcenverbrauch hält sich absolut in Grenzen.

Code:

top - 21:11:31 up 20:37,  2 users,  load average: 4,27, 1,55, 0,63
Tasks: 219 total,   1 running, 217 sleeping,   0 stopped,   1 zombie
%CPU(s): 96,1 us,  3,6 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,2 si,  0,2 st
MiB Spch:   7947,8 total,   3315,1 free,   2197,5 used,   2712,5 buff/cache
MiB Swap:  18432,0 total,  17658,8 free,    773,2 used.   5750,3 avail Spch

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
  18337 privat    20   0  988544 704904  18936 S 107,6   8,7   0:17.76 [celeryd: celer
   3258 privat    20   0 1064148 193704  18824 S   0,3   2,4   0:49.90 granian asginl
   4362 firma     20   0 1353380 130992  18776 S  14,5   1,6   1:22.99 granian asginl
   4324 firma     20   0  348732 120528  11724 S   0,3   1,5   2:54.80 [celeryd: celer
   3224 privat    20   0  348720 117540  10524 S   0,0   1,4   3:00.84 [celeryd: celer
   4181 35002     20   0 4672664 113960  11824 S   0,0   1,4   5:58.82 java
   3138 35002     20   0 4672664 102452  11660 S   0,3   1,3   6:26.99 java
   3230 privat    20   0  347788  86688   9748 S   0,0   1,1   0:14.46 [celery beat] -
   4331 firma     20   0  347960  86584  11144 S   0,0   1,1   0:14.33 [celery beat] -
  16031 root      20   0 2320140  64832  43516 S   0,3   0,8   0:55.16 podman
   4000 35002     20   0 4664488  58980   8616 S   0,3   0,7   3:29.79 java
   2858 35002     20   0 4664488  51704   8124 S   0,0   0,6   3:55.38 java

Ab und zu geht der Ressourcenverbrauch (RAM) hoch, fällt aber wieder ab auf Minimum.

Code:

top - 21:15:39 up 20:42,  2 users,  load average: 2,32, 2,33, 1,19
Tasks: 222 total,   2 running, 220 sleeping,   0 stopped,   0 zombie
%CPU(s): 29,5 us, 25,7 sy,  0,0 ni, 34,1 id, 10,2 wa,  0,0 hi,  0,3 si,  0,2 st
MiB Spch: 65,0/7947,8   [||||||||||||||||||||||||||||||||||||||||||||||                          ]
MiB Swap:  5,4/18432,0  [||||                                                                    ]

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     ZEIT+ BEFEHL
  20475 privat    20   0 4465908   3,7g  55964 R  78,5  48,2   0:12.58 [celeryd: celer
   4362 firma     20   0 1353348 172640  19232 S   0,3   2,1   2:13.23 granian asginl
   3258 privat    20   0 1064148 161952  18824 S   0,3   2,0   0:59.01 granian asginl
  20424 firma     20   0  378544 144352   4964 S   0,0   1,8   0:00.39 [celeryd: celer
   4324 firma     20   0  348732 120732  11720 S   0,0   1,5   3:00.75 [celeryd: celer
   3224 privat    20   0  348720 117736  10524 S   0,0   1,4   3:02.00 [celeryd: celer
   4331 firma     20   0  347960  86296  11168 S   0,0   1,1   0:14.33 [celery beat] -
   3230 privat    20   0  347788  80684   9772 S   0,0   1,0   0:14.46 [celery beat] -
  16031 root      20   0 2320140  61416  42220 S   1,0   0,8   0:57.38 podman

Das war vorher nicht so.

foofoobar · Montag um 21:31

DHC schrieb:
Ich habe kein Problem alles noch mal neu zu installieren. Ich habe die beiden Instanzen aktuell ja noch nicht im Produktiveinsatz.
Dann mache ich die Partitionierung manuell. Swap dann entsprechend groß wählen. Speicher habe ich mehr als genug. Das ist kein Problem.

Du kannst auch einfach weitere swap devices hinzufügen, einfach mehrere in die fstab eintragen, dann kannst dir den Heckmeck sparen.

Und stell mal den Timer für sar auf eine Minute runter und aktiviere die Aufzeichnung:

https://wiki.debian.org/sysstat

Dann kann man sich nachträglich vernünftig anglotzen was passiert ist.

P.S:

Code:

free -h; echo; ps aux --sort=-vsz | head -n 10
free -h; echo; ps aux --sort=-rss | head -n 10

DHC · Montag um 21:49

foofoobar schrieb:
P.S:
free -h; echo; ps aux --sort=-vsz | head -n 10 free -h; echo; ps aux --sort=-rss | head -n 10

free ~~geht bei mir auch nicht oder gehört das auch zu~~ sysstat?
Letztens hatte ich das schon mal eingetippt. Wurde nicht gefunden.
Da muss ich erst mal schauen, zu welchem Paket das gehört.
EDIT: Geht nun doch.

Ergänzung (Montag um 21:50)

foofoobar schrieb:
einfach mehrere in die fstab eintragen

Das sagst du so leicht.
Da muss ich erst mal nachschauen, wie man das macht.
EDIT: Erledigt. War ja recht einfach.

JumpingCat · Montag um 21:53

DHC schrieb:
free geht bei mir auch nich

DHC schrieb:
Ich habe Debian 13 Core-Installation

Übertreib es nicht mit dem Minimalismus :-)

Code:

user@host:~$ dpkg -S /usr/bin/free
procps: /usr/bin/free
user@host:~$ dpkg -L procps | grep bin
/bin
/bin/kill
/bin/ps
/sbin
/sbin/sysctl
/usr/bin
/usr/bin/free
/usr/bin/pgrep
/usr/bin/pidwait
/usr/bin/pmap
/usr/bin/pwdx
/usr/bin/skill
/usr/bin/slabtop
/usr/bin/tload
/usr/bin/top
/usr/bin/uptime
/usr/bin/vmstat
/usr/bin/w
/usr/bin/watch
/usr/bin/pkill
/usr/bin/snice

Da sind noch einige nette Tools drin versteckt.

DHC · Montag um 21:56

@JumpingCat
Es geht ja nun.
Wurde wohl irgendwann bei einer Paketinstallation mitinstalliert.
Ich habe es nicht direkt installiert.

Suche

Frage zu SWAP | Sie ist permanent voll | Muss das sein?

Uridium

Commander

foofoobar

Rear Admiral

DHC

Commander

foofoobar

Rear Admiral

andy_m4

Admiral

DHC

Commander

foofoobar

Rear Admiral

andy_m4

Admiral

foofoobar

Rear Admiral

DHC

Commander

foofoobar

Rear Admiral

DHC

Commander

JumpingCat

Rear Admiral

DHC

Commander

Ähnliche Themen

Passend zum Thema

Bericht GeForce Now App für Linux Streaming macht viel spielbar, was bisher nicht lief

Remote-Software AnyDesk 7.1.3 Update erhöht Stabilität bei Linux und Raspberry Pi

Linux-News der Woche Neue CachyOS-ISO und wichtiges Vulkan-Update