/tmp bei Fedora vergrössern

[PCProfi]

Hallo Zusammen
Ich habe ein paar Fedora Maschinen, bei denen der /tmp (tmpfs) Bereich zu klein ist. Eine Neuinstallation des Betriebssystems soll mein Vorhaben nicht aufhalten.

Ich habe die neueste Fedora 15 Version: http://fedoraproject.org/de_CH/

Die endgültige Grösse sollte ca. 15 GB betragen.

 

[GrandTheft]

Hi,

was ist Deine Frage?
gt

 

[bu1137]

Wenn du dir nicht 30 GB RAM besorgen willst, lass /tmp doch einfach auf Festplatte sein. Also, nix tmpfs.

 

[PCProfi]

Wo kann ich die /tmp Grösse festlegen oder verändern um mit dieser auf ca. 15 GB zu gelangen? Momentane Grösse mit 2 GB ist zu klein für mein Vorhaben.

 

[GrandTheft]

@bu1137: Wieso? das geht doch auch ohne RAM derselben Größe. Ich glaub Du denkst tmpfs = ramfs, aber das ist != ramfs.

gt

Ergänzung (1. Juni 2011)

@PCProfi: Ist /tmp eine separate Partition? Wenn nein:

Wenn Du es in der fstab mit tmpfs mountest, kannst Du die option size=15000m benutzen, also z.B.

tmpfs /some/dir tmpfs size=15000m 0 0

grüße
gt

 

[bu1137]

@GrandTheft: tmpfs ist ein RAM filesystem. Ja, es kann swap benutzen. Aber, was soll das in diesem Fall bringen? Lieber direkt.

 

[PCProfi]

Nein es ist keine separate Partition. Ich werde das gerne testen. Danke.

Der Sinn darin liegt, dass diese Server von einem Storage Daten in Grösse zwischen 1-10 GB zu sich lokal kopieren und dann ca. 5-10h daran rechnen. Erst danach wird das ganze wieder zurück auf das Storage geschrieben.

 

[bu1137]

Tja, dann sag ich's nochmal: Do not use tmpfs.

 

[GrandTheft]

Nein es ist keine separate Partition. Ich werde das gerne testen. Danke.

Der Sinn darin liegt, dass diese Server von einem Storage Daten in Grösse zwischen 1-10 GB zu sich lokal kopieren und dann ca. 5-10h daran rechnen. Erst danach wird das ganze wieder zurück auf das Storage geschrieben.

Dann ist das wahrscheinlich genau das richtige. Machen wir ähnlich mit bis zu 60GB auf 64GB RAM.

Der einzige Grund, warum jemand allen ernstes ramfs bevorzugen könnte, wäre weil es dynamisch wächst. Bis das System dann hängt.

gt

 

[bu1137]

@GrandTheft: Was hast du mit ramfs? Das ist gestorben, und hat hier auch keiner vorgeschlagen.

15GB RAM-Disk (swap-backed tmpfs) bei 4GB RAM ist aber nunmal Blödsinn. Übrigens musst du in der Konfiguration auch noch sicherstellen, dass du überhaupt genügend swap (Auslagerungsdatei) zur Verfügung hast...

 

[GrandTheft]

wo steht 4GB? Wenn das irgendwo stünde, wärs blöd. Stimmt. Steht aber nirgends.
Ich habe "lieber direkt" als "lieber mit ramfs" interpretiert. Was sonst? Auf die Platte ist ja keine Alternative zu tmpfs.

gt

 

[bu1137]

Natürlich direkt auf die Platte. Lass den VFS Cache walten.

Die 4GB leite ich davon ab, dass normalerweise die Hälfte vom RAM als tmpfs benutzt wird. Und seiner Aussage nach ist es ja bisher auf 2GB limitiert. Ergo, 4GB RAM total.

 

[GrandTheft]

Dann wärs echt öhm, komisch, mit 15GB tmpfs arbeiten zu wollen.

Wenn man aber genug Speicher zur Verfügung hat, kann man schon mit tmpfs arbeiten, dann hat man die Daten auch schon beim ersten Zugriff im Speicher und muss später nicht auf den Cache hoffen. Sollte man bei häufiger Nutzung ausprobieren, wenns keinen Performance-Unterschied macht, kann man's auch auf die Platte schreiben. Hab ich noch nie ausprobiert. Kann im Grenzfall höchstens genauso schnell sein -> bleibt so.

gt

 

[PCProfi]

Ob blödsinnig oder nicht. Für mich ist das der Weg ans Ziel.
Die Rechner haben 4 GB Ram, wie bu1137 richtig vermutet hat.

 

[bu1137]

Beschwer dich dann aber nicht, wenn die Kiste im Schneckentempo läuft.

Ich würde dir nach wie vor empfehlen, den tmpfs mount wegzulassen. Im besten Fall eine eigene Partition auf /tmp mounten.

 

[GrandTheft]

full ack mit bu1137. Damit hälst Du quasi künstlich den RAM voll und zwingst den kernel die ganze Zeit zum swappen. An sowas wie file system cache ist dann gar nicht mehr zu denken.

 

[mensch183]

Standardlösung für ein Programm mit temporären Daten, die nicht ins Schema fürs normale /tmp eines Systems passen, ist, dieses Programm seine temp. Daten in einem anderen Pfad ablegen zu lassen. Dieser andere Pfad kann ganz nach Belieben für das fragliche Programm optimiert werden.

Vorteil: Alle anderen /tmp nutzenden Programm bleiben unbeeinflusst. Da gehts nicht nur um Performance sondern auch um Restart-Verhalten, Speichennutzung usw. Auf Kisten, die dediziert nur für einen Job da sind, ist das natürlich wumpe. Auf Kisten, auf denen bischen mehr los ist, sollte man das Verhalten von /tmp allerdings nicht einfach so umkrempeln.