ubuntuusers.de

Hallo zusammen!

Aktuelle Gegebenheiten:

~$ inxi -F
System:    Host: x-PC Kernel: 4.0.4-040004-generic x86_64 (64 bit)
           Desktop: KDE 4.13.3 Distro: Ubuntu 14.04 trusty
Machine:   System: xxxxxxxxx product: N/A
           Mobo: xxxxxxxxxxx: Z77-xxxxxxxxxx
           Bios: xxxxxxxxxxxxxx v: xxxx date: xx/xx/xxxx
CPU:       Quad core Intel Core i7-3770K (-HT-MCP-) cache: 8192 KB 
           clock speeds: max: 3900 MHz 1: 1814 MHz 2: 1989 MHz
           3: 1951 MHz 4: 1647 MHz 5: 1663 MHz 6: 1907 MHz
           7: 1672 MHz 8: 1635 MHz
Graphics:  Card: NVIDIA GK110 [GeForce GTX 780]
           Display Server: X.Org 1.16.0 drivers: nvidia (unloaded: fbdev,vesa,nouveau)
           Resolution: 1920x1200@60.0hz
           GLX Renderer: GeForce GTX 780/PCIe/SSE2
           GLX Version: 4.5.0 NVIDIA 346.72
Audio:     Card-1 Intel 7 Series/C210 Series Family High Definition Audio Controller
           driver: snd_hda_intel
           Card-2 NVIDIA GK110 HDMI Audio driver: snd_hda_intel
           Sound: ALSA v: k4.0.4-040004-generic
Network:   Card: xxxxxxxxxxxxxx Gigabit Ethernet
           driver: xxxxxxx
           IF: eth0 state: up speed: 1000 Mbps duplex: full
           mac: xxxxxxxxxxxxxxx
Drives:    HDD Total Size: 512.1GB (6.4% used)
           ID-1: /dev/sda model: Samsung_SSD_840 size: 512.1GB
Partition: ID-1: / size: 454G used: 16G (4%) fs: ext4 dev: /dev/dm-1
           ID-2: /boot size: 236M used: 91M (41%) fs: ext2 dev: /dev/sda1
           ID-3: swap-1 size: 17.14GB used: 0.00GB (0%) fs: swap dev: /dev/dm-2
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 29.8C mobo: 27.8C gpu: 34C
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 280 Uptime: 55 min Memory: 1695.4/16008.9MB
           Client: Shell (bash) inxi: 2.2.21 
~$ 

~$ sudo parted -l
Modell: ATA Samsung SSD 840 (scsi)
Festplatte  /dev/sda:  512GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos

Nummer  Anfang  Ende   Größe  Typ       Dateisystem  Flags
 1      1049kB  256MB  255MB  primary   ext2         boot
 2      257MB   512GB  512GB  extended
 5      257MB   512GB  512GB  logical


Modell: Linux device-mapper (linear) (dm)
Festplatte  /dev/mapper/kubuntu--vg-swap_1:  17,1GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: loop

Nummer  Anfang  Ende    Größe   Dateisystem     Flags
 1      0,00B   17,1GB  17,1GB  linux-swap(v1)


Modell: Linux device-mapper (linear) (dm)
Festplatte  /dev/mapper/kubuntu--vg-root:  495GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: loop

Nummer  Anfang  Ende   Größe  Dateisystem  Flags
 1      0,00B   495GB  495GB  ext4


                                                                      Fehler: /dev/mapper/sda5_crypt: unbekannte Partitionstabelle

~$ 

Kann man für mein System, unter Berücksichtung der nachfolgend geschilderten Beobachtungen, überhaupt eine Empfehlung für einen vm.swappiness-Wert aussprechen?

Z.B.

~$ sysctl vm.swappiness
vm.swappiness = 25
~$ 

Und so richtig verstehe ich nicht, dass swap und Arbeitsspeicher sich bei mir scheinbar anders verhalten haben, als der Wert vm.swappiness = 60 vorgibt. Denn wenn ich es richtig verstehe, dann sagt dieser Wert aus, dass auf swap ausgelagert wird, wenn der Arbeitsspeicher zu 60% oder mehr ausgelastet ist. Beim wipen eines sehr großen Verzeichnisses (ca. 27GB) auf einer externen HDD wurde der Arbeitsspeicher relativ stark beansprucht.

Genauer gesagt war das Verhalten wiederkehrend so, dass der Arbeitsspeicher bis ca. 10GB noch freien Arbeitsspeicherplatz ausgelastet wurde. Dann aber swap "nur" zu 1% belegt wurde. Bzw. der Arbeitsspeicher, wenn er in etwa die 10GB freien Arbeitsspeicher unterschritten hatte, sofort wieder auf knapp 13GB freien Arbeitsspeicher angewachsen ist. Um anschließend wieder auf unter 10GB zu fallen. Und das hat sich bis zum Ende des wipens ständig wiederholt.

Allerdings verhält es sich nahezu gleich, wenn der Wert vm.swappiness = 25 eingestellt ist. Von ca. 14GB freien Arbeitsspeicher wird auch jetzt der Arbeitsspeicher bis zu ca. 10GB noch freien Speicherplatz ausgelastet. Der freie Arbeitsspeicher wächst dann wiederholt auf ca. 14GB an, bis der freie Arbeitsspeicher auf ca. 10GB gesunken ist. Allerdings wurde der Auslagerungsspeicher diesmal zu 0% beansprucht.

Jetzt scheint es ja irgendwie egal zu sein, mit welchen swappines-Wert mein System arbeitet. Denn das Verhalten ist nahezu identisch.

Aus der eigenen Beobachtung heraus stellt sich für mich die Frage, ob durch den Einsatz von Kernel 4.0.4 ein vm.swappiness-Wert überhaupt Einfluss auf mein System nimmt. Denn wirklich ausgelagert wird ja nicht auf swap, so wie es vm.swappiness eigentlich vorgibt.

Nicht das wir uns falsch verstehen, wenn nicht auf den Datenträger ausgelagert wird, habe ich hier nicht unbedingt etwas auszusetzen, eher im Gegenteil. Es verhält sich aber scheinbar anders, als vm.swappiness nach bisherigen Verständis vorgeben möchte.

Gruß Andi

optimq schrieb:

Und so richtig verstehe ich nicht, dass swap und Arbeitsspeicher sich bei mir scheinbar anders verhalten haben, als der Wert vm.swappiness = 60 vorgibt. Denn wenn ich es richtig verstehe, dann sagt dieser Wert aus, dass auf swap ausgelagert wird, wenn der Arbeitsspeicher zu 60% oder mehr ausgelastet ist.

Nein, das ist kein Prozentwert. Wo immer du das her hast, es ist falsch.

Arbeitsspeicher ist dafür da genutzt zu werden. Leerer Arbeitsspeicher sieht zwar schick aus ist aber Verschwendung, also du hast Resourcen, die du nicht nutzt. 100% voller Arbeitsspeicher ist je nach Situation besser als 5% belegter Arbeitsspeicher. Die Speicherverwaltung von Linux nutzt so viel Arbeitsspeicher wie sie bekommen kann, gibt diesen Platz aber auch wieder frei, wenn andere Prozesse Speicher benötigen. Dabei muss die Speicherverwaltung ständig entscheiden, welche Daten von welchem Prozess (unter umständen auch von längst beendeten Prozessen) freigegeben werden und ob diese Daten einfach verworfen werden (der Prozess würde dann beendet), oder ob sie nach swap ausgelagert werden.

swappiness ist ein Faktor, der in diese Entscheidung mit einfließt. Eine art Gewichtung, wie wahrscheinlich es ist, dass das System sich für „Auslagern nach swap“ entscheidet. Mit einem Prozentsatz des belegten Arbeitsspeichers hat das nichts zu tun.

In der Regel will man swappen übrigens vermeiden, weil das Festplattenspeicher ist – der ist im Vergleich zum RAM unglaublich langsam.

Beim wipen eines sehr großen Verzeichnisses (ca. 27GB) auf einer externen HDD wurde der Arbeitsspeicher relativ stark beansprucht.

Und das ist schlimm, weil …?

~jug

Danke jug für Deine Rückmeldung!

Nein, das ist kein Prozentwert. Wo immer du das her hast, es ist falsch.

Auf der Suche nach Informationen für den optimalen Wert von vm.swappiness, mit möglichst ähnlichen Bedingungen, führte mich mein Weg im Netz über etliche Seiten. Die 60% sind durch die Seite http://www.nickles.de/forum/linux-contra-monopole/2015/ist-swap-notwendig-539115416.html hängengeblieben.

Danke, dass Du das berichtigt hast! Auch wenn ich so den vm.swappiness-Wert nicht wirklich greifen kann. Als Prozent-Wert wäre es für mich nachvollziehbar gewesen. So habe ich nur die Information, bei vm.swappiness = 0, besser gesagt bei vm.swappiness = 1, nur Auslagern, wenn es sich nicht vermeiden lässt. Und bei vm.swappiness = 100 soll der Arbeitsspeicher möglichst nicht belastet werden.

Die Werte dazwischen geben also nur eine mehr oder weniger starke Tendenz in die eine oder andere Richtung. Und da es sich nun ja nicht um %-Werte handelt, macht es einen optimalen Wert für mein System zu finden um so schwerer.

Kann ich denn u.U. die Arbeitsgeschwindikeit von meinem Rechner, möglichst breitgefächert, durch einen bestimmten vm.swappiness-Wert erhöhen? Ich freue mich wenn der Arbeitsspeicher verwendet wird. Denn dazu ist er da. 😉 Und von den mehr oder weniger Speicher-Modulen, ist der Arbeitsspeicher nun mal mit Abstand der schnellste.

jug schrieb:

optimq schrieb:

Beim wipen eines sehr großen Verzeichnisses (ca. 27GB) auf einer externen HDD wurde der Arbeitsspeicher relativ stark beansprucht.

Und das ist schlimm, weil …?

jug, ich habe nicht geschrieben, dass es schlimm ist, ganz im Gegenteil. Ich zitiere mich mal:

Nicht das wir uns falsch verstehen, wenn nicht auf den Datenträger ausgelagert wird, habe ich hier nicht unbedingt etwas auszusetzen, eher im Gegenteil.

Gruß Andi

optimq schrieb:

Kann ich denn u.U. die Arbeitsgeschwindikeit von meinem Rechner, möglichst breitgefächert, durch einen bestimmten vm.swappiness-Wert erhöhen?

Nein. Es gibt keinen magischen „mach alles schneller“-Knopf. Gäbe es einen, dann wäre der wohl per Voreinstellung schon gedrückt. Du kannst also davon ausgehen, dass der Standardwert für swappiness schon für den Großteil der Anwender sehr sinnvoll gewählt ist.

Schneller wird dein System durch drei Faktoren:

• Mehr RAM,

• Schnellere Festplatte (Zugriffszeiten) und

• schnellerer Prozessor.

Dabei kommt es ein wenig darauf an, was du mit dem System machst – unterschiedliche Programme bzw. Aufgaben haben unterschiedliche Flaschenhälse. Bei manchen Prozessen wird der Prozessor mehr belastet, bei anderen werden viele Daten auf der Festplatte verändert und da liegt der limitierende Faktor. Wieder andere Aufgaben brauchen viel RAM und wenn du Multimedia/Video machst, kann eventuell eine Grafikkarte helfen. Am meisten hilft aber mehr RAM, weil das in der Regel erlaubt mehr Prozesse parallel laufen zu lassen.

~jug

Danke!

Das bedeutet dann auch, dass die verschiedensten Tipps eher Blödsinn sind!? Wie z.B. vm.swappiness = 60 ist eher für Server gedacht und vm.swappiness = 50 für Desktop-Rechner oder je mehr RAM, um so geringer kann ich den vm.swappiness-Wert wählen.

Und weil ich keine bestimmte Anwendung bevorzuge oder häufiger einsetze, ist also egal, ob der Standardwert vm.swappiness = 60 ist oder aktuell

~$ cat /etc/sysctl.conf
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#
# vm.swappiness hinzugefügt am 29.05.2015
vm.swappiness = 25



#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

~$ 

eingetragen ist?

Gruß Andi

optimq schrieb:

Genauer gesagt war das Verhalten wiederkehrend so, dass der Arbeitsspeicher bis ca. 10GB noch freien Arbeitsspeicherplatz ausgelastet wurde. Dann aber swap "nur" zu 1% belegt wurde. Bzw. der Arbeitsspeicher, wenn er in etwa die 10GB freien Arbeitsspeicher unterschritten hatte, sofort wieder auf knapp 13GB freien Arbeitsspeicher angewachsen ist. Um anschließend wieder auf unter 10GB zu fallen. Und das hat sich bis zum Ende des wipens ständig wiederholt.

Allerdings verhält es sich nahezu gleich, wenn der Wert vm.swappiness = 25 eingestellt ist. Von ca. 14GB freien Arbeitsspeicher wird auch jetzt der Arbeitsspeicher bis zu ca. 10GB noch freien Speicherplatz ausgelastet. Der freie Arbeitsspeicher wächst dann wiederholt auf ca. 14GB an, bis der freie Arbeitsspeicher auf ca. 10GB gesunken ist. Allerdings wurde der Auslagerungsspeicher diesmal zu 0% beansprucht.

Du hast sehr viel Arbeitsspeicher (im Verhältnis zu dem Ansprüchen deiner Programme). Daher ist das Verhalten fast gleich. Erst, wenn der Speicher wirklich zur Neige geht, kommt die Swappiniess ins Spiel. "swappiness = 25" ist bei Dir sicher nicht verkehrt, wenn der Auslagerungsspeicher dann gar nicht genutzt wird.

Mit dem Befehl

free -h

kannst Du den den RAM genauer analysieren. Was als "frei", "Puffer" und "Cache" angegeben wird steht "im Notfall" noch zur Verfügung. Das ist wesentlich mehr als die Belegung vermuten lässt.

optimq schrieb:

Das bedeutet dann auch, dass die verschiedensten Tipps eher Blödsinn sind!?

Ich persönlich habe da noch nie etwas dran verändert und würde da auch nichts dran verändern. Schon gar nicht, wenn kein Verständnis dafür vorhanden ist, was dieser Wert eigentlich tut. Ich würde also dringend dazu raten, beim Default zu bleiben.

Hier ist übrigens eine ziemlich gute Erklärung, was der Kernel überhaupt mit dem Arbeitsspeicher macht und wie er swap genau verwendet. Etwas ausführlicher als ich oben beschrieben habe (aber immer noch vereinfacht). http://askubuntu.com/a/184221

~jug

Hallo Thomas Do und Danke!

free -h nutze ich ungern, da nicht alle Werte an den richtigen Stellen stehen, bzw. die mehr oder weniger Speicher-Orte (Gesamt, Belegt...) zu eng geschrieben sind. Irgendwo habe ich das auch schon mal erwähnt. Wie hier z.B. die 2,0G unter Frei. Das ist totaler Blödsinn. Dorthin gehören die 13G.

~$ free -h
             Gesamt Belegt Frei Gemeinsam Puffer Cache
Speicher:        15G       2,0G        13G        95M        52M       785M
-/+ Puffer/Cache:       1,2G        14G
Auslagerungsdatei:        15G         0B        15G
~$ 

Und da ich nicht sehr häufig viel RAM benötige, besser gesagt RAM verwendet wird, brauche ich mir nicht unbedingt Sorgen, dass bei vm.swappiness = 25 und vielen geöffneten Anwendungen der falsche RAM-Speicher freigegeben wird. Und bei vm.swappiness = 0 oder 1, ist die Gefahr vielleicht größer. Oder stellt sich das Problem bei 16GB RAM gegenüber z.B. 4GB RAM eher nicht?

Und wenn ich Dich richtig verstehe, dann sind die vm.swappiness = 25 bei 16GB RAM nicht so verkehrt gewählt, da einerseits relativ viel RAM zur Verfügung steht. Und andererseits trotzdem noch ausgelagert werden kann.

Wie schon angedeutet, ist es schade, dass der Wert hinter dem = keine Prozentangabe ist und so nicht wirklich greifbar ist. Von daher belasse ich, auf Grund Deiner diesbezüglichen vermutlichen Erfahrungen, zunächst die vm.swappiness = 25.

Danke Thomas Do! ☺

Gruß Andi

* Vielleicht gibt es auch noch andere Meinungen und Erfahrungswerte.