Frage zur SWAP-Größe

1 GB reicht aus. Bedenke mal wie langsam ein System würde, wenn 1GB Swap tatsächlich genutzt wird...

Die Regel "mindestens so viel wie RAM" kommt IMHO aus Zeiten wo RAM noch nicht gigabyteweise eingebaut wurde.

Ist heute allerdings nach wie vor dann interessant, wenn man suspend to disk machen will. Dafür nimmt Linux die Swap-Partition her und wenn der Ram dort nicht reinpasst wird das nix.

Zitat von Mreimer

Die Regel "mindestens so viel wie RAM" kommt IMHO aus Zeiten wo RAM noch nicht gigabyteweise eingebaut wurde.

Das stimmt nicht, früher hieß es, "Nimm doppelt soviel Swap wie RAM". Diese Regel ist veraltet.

Die Regel: "Nimm mindestens soviel wie du RAM hast" ist immer noch gültig. Der Grund ist, das beim S4 (Suspend 2 Disk) der RAM Inhalt komplett in den SWAP kopiert wird, und dafür muss der SWAP mindestens so groß sein wie der RAM. Verwendest du kein S4 sollte 1 GB Locker reichen. Ich hab z.B. auf einem meiner VDRs gar kein SWAP mehr, da ich auf der 16GB SSD einfach keinen Platz hab

Zitat von docadams

Der Hintergrund ist folgender: ich möchte yaVDR0.4pre1 gefahrlos testen und habe mir dafür einen 16GB-Stick zugelegt. Irgendwo hatte ich mal gelesen, dass diese Version eine Art RAM-Disk von Haus aus mitbringt, yaVDR also den Stick nicht gleich mit Logs "kaputt-schreibt".

Nein haben wir nicht. Es wird normal geloggt was das zeug hält

Zitat von traxanos

Nein haben wir nicht. Es wird normal geloggt was das zeug hält

aber gab's da nicht mal ein feature request, dass das logging in eine ramdisk könnte/sollte?

Ja - aber das wird zur 0.4 nichts. mehr - zum einen hat es keine Toppriorität - zum anderen ist es nicht trivial (logging in eine ramdisk hilft dir garnichts wenn gigabyteweise Logs erstellt werden!).

Also ist das Thema:
- was loggt alles
- wie baut man am besten ein das nur Fehler geloggt werden
- wie stellt man sicher das nix Amok läuft wenn zuviel geloggt wird
- wie baut man das alles so ein das das Einschalten einfach und sinnvoll ist, und evtl auch Leute die das feature nicht nutzen , einen Nutzen daraus ziehen.

Das muss ja nicht auf die Husche und schlecht gemacht werden Diskussion wie man es am besten macht und Zuarbeit für das Feature ist willkommen ! (aber nicht, benutz doch das und das ..)

Also, ich habe eine Zeit lang mein Desktop-System (4GB) komplett ohne Swap betrieben. Ich hatte dann aber gelegentlich mal Programmabstürze (Out of memory), wenn ich wirklich wirklich viele Programme mit Speicherhunger offen hatte. Habe dann nachträglich eine Swap-Datei hinzugefügt.
So könntest Du auch auch vorgehen. Man kann ja auch mehrere Swaps einhängen. Du könntest also zuerst ohne Swap, dann mit 1 GB oder 2GB testen.

Sollte ein Unix System den Page-Out Bereich dauerhaft benötigen, hat man eh ein Problem, das es zu lösen gilt, weil die Maschine dann unendlich viel langsamer wird. Bei einem VDR sollten man den SWAP eigentlich nur und ausschließlich für Suspend2Disk (S4) benötigen ...

Im kommerziellen Bereich gilt z.B. bis heute die Vorgabe bei SAP Installation, 3x Hauptspeicher + 512MB. Man beachte dabei, das diese Maschinen heute auch schon mal gediegen 256GB+ Hauptspeicher haben können ... aber dort setzt man das um, weil man sonst keinen Support bekommt und weil eine super langsame Installation zumindest noch die Transaktionen in die Datenbank schreiben kann, ein Out-of-Memory wäre hier absolut inakzeptabel ....

Bei MS Betriebssystemen (Desktop & Server) ist das Design ganz anders, da dort ab StartUp Teile des Betriebssystem-Kerns und anderen Services ausgelagert werden. Windows legt die Datei in der Größe des verfügbaren RAMs an und schreibt Suspend2Disk (Hibernation) in eine zweite Datei ...

Beachte Suspend2Disk (S4) per "pm-utils" setzt zwingend eine Swap-Partition vorraus, während "uswsusp" mit Swap-Dateien umgehen kann.

Regards
fnu

Zitat von docadams

Das ist zwar schade, aber OK. Der Stick wird ja hoffentlich durch die Logs nicht gleich in 2 Monaten kaputt geschrieben sein.

Hmm, da wäre ich vorsichtig ...

Aber ich habe da jetzt keine Erfahrung mit USB Sticks im VDR Dauerbetrieb, aber was wäre wenn man den Stick quasi als SSD behandelt und Online-Trim Support (discard) montiert?

Regards
fnu

usbs hab ich schon mehrfach früher kaput bekommen weil die eben keine waerwaving haben. ssd wäre daher definitive zu bevorzugen!

Zitat von traxanos

waerwaving

Nicht eher wearleveling? wearwaving sagt mir garnix...

Ich habe seit ca 4 Jahren auf keinem meiner Linux Rechner mehr ein SWAP eingerichtet. Meine Desktops laufen mit 2/4 GB
und die laufen ohne Probleme.

Meine VDRs laufen mit 1GB (Server) und 2GB (Client) auch ohne SWAP, werden aber auch per Shutdown herunter gefahren.
Auch ohne Probleme.

vdr-box

Zitat von fnu

Aber ich habe da jetzt keine Erfahrung mit USB Sticks im VDR Dauerbetrieb, aber was wäre wenn man den Stick quasi als SSD behandelt und Online-Trim Support (discard) montiert?

Gibt es überhaupt schon USB-Sticks, die TRIM unterstützen?

Vielleicht als Anregung: Ich hatte einmal damit experimentiert, /var/log/ auf eine btrfs- bzw. nilfs-Partition zu legen (alles andere auf ext4). Im Großen und Ganzen hat das auch prima geklappt. (Jedenfalls bis sich herausgestellt hat, dass mein Mainboard gelegentlich "vergisst", dass es vom USB-Stick booten soll ... :wand)

Von einer Art RAM-Disk für die Logs halte ich überhaupt nichts, denn wenn man sie mal braucht (insbesondere nach einem Crash), ist nichts mehr da. Aber im Notfall kann man die Logs ja immer noch auf die Video-Partition auslagern.

Zitat von docadams

Vielleicht kann man sie deaktivieren und nur bei Bedarf aktivieren?

Das ist ja das Problem: Ob man Bedarf hat, weiß man immer erst hinterher.

Aber nochmal etwas ausführlicher zu den Dateisystemen, das war gestern etwas sehr knapp formuliert:

nilfs hat den Vorteil, dass es ein "log-structured file system" ist, d.h. alle Änderungen im Dateisystem werden in einer einfachen Liste gespeichert. Die fängt am Anfang der Partition an und wird nach und nach bis zum Ende der Partition gefüllt, danach geht es wieder vorne los. Auch wenn Dateien geändert werden, wird nur ein entsprechender Vermerk am Ende der Liste angehängt. Für USB-Sticks bedeutet das, dass kein Sektor übermäßig beansprucht wird, sondern alle Sektoren gleichmäßig abgenutzt werden, was theoretisch die Lebenszeit verlängert.

btrfs (scheint gerade nicht erreichbar zu sein) hat unter Anderem den Vorteil, dass es Dateien vor dem Schreiben auf den Datenträger komprimieren kann, ohne dass der Benutzer etwas davon merkt. Theoretisch sollte das gerade für Log-Dateien gut geeignet sein, da die ja hauptsächlich aus viel sich wiederholendem Text bestehen. Da weniger geschrieben werden muss, verschleißt der Stick auch langsamer.

Hauptargumente gegen die beiden Dateisysteme (weiß nicht, ob sich das inzwischen geändert hat) sind mangelnde Stabilität und fehlendes fsck - wobei das in meinen Tests kein Problem war, weil ich die ja nur für /var/log/ benutzt hatte. Ein (großer) Vorteil ist allerdings, dass man nicht viel konfigurieren/skripten muss, sondern bloß eine zusätzliche Partition für die Logs benötigt. Leider hat mein Mainboard den Langzeittest nicht mitgemacht, sonst hätte ich mehr berichten können.

Zitat von docadams

Da ist Steffens Ansatz sinnvoll zu überlegen, was im Alltag an Loggs überhaupt notwendig ist.

Also ich finde sie unverzichtbar. Wenn bei mir der VDR mit nem Exitcode != 0 zurückkommt wird das Log (welches nur den aktuellen VDR Lauf beinhaltet) mit Wegesichert, dazu (wenn ein coredump erzeugt wurde) das dazugehörige Backtrace. Seit ich das habe brauche ich bei keinem Problem mehr zu raten wo es denn herkommt, IMHO unverzichtbar.

Son übliches "wir leiten jeden Müll in ein Logfile und rotieren alle 10 Tage" ist allerding IMHO völlig überflüssig, hat eh keiner Lust das zu lesen.

Also lieber an der Konfiguration arbeiten, dann hält sich das auch von der Menge her in Grenzen.

cu

Nur um noch ein wenig weiterzuspinnen.
- 2 grub Einträge : quiet und debug
- wenn mit quiet gebootet, dann geht vdr auf -l 1, andere komponenten ähnlich.
- die Logkonfiguration muss bei uns mal überprüft werden (Umleitung des VDR Logs in eine seperate Datei, logrotate)
- andere Komponenten müssen überprüft werden (xbmc ?, alles andere halt: empirisch nach Auftreten überprüfen und nach und nach anpassen)
- zum debuggen kann man auch vdr-dbg nachinstallieren und wenn man es aktiviert (/etc/default/vdr) werden bei Segfaults backtrace gezogen (das ist in der 0.4 bereits enthalten)

Das einzige was dem diametral entgegensteht ist "das andere Leben" .

Bei der Übung oben, bin ich mir sicher, das da eine Variante für Flasheinsatz mit busybox-syslogd "fast kostenlos" abfallen könnte.

Im realen Einsatz sehe ich keine Notwendigkeit zum ausführlichen Loggen solange dies einfach erreichbar ist im Fehlerfall.

Ich glaube fest daran das 99.9% der Leute , erst im zweiten oder dritten Fehlerfall überhaupt erst aktiv werden (es sei denn es geht nichts mehr, dann wird neuinstalliert und dann gefragt was es war ^^). Was Raum gibt den Debug erst zu aktivieren (in den Debugmodus umzubooten)