[OSM-Devserver] Ihr steht euch gegenseitig auf den Füßen :(

[Jochen Topf]

On Tue, Apr 27, 2010 at 11:50:10AM +0200, Christoph Wagner wrote:
> Sven Geggus schrieb:
> > Tobias Wendorff <tobias.wendorff at uni-dortmund.de> wrote:
> 
> >> Ich könnte es im RAMdrive machen, dann sollte es niemand stören.
> > 
> > Um Gottes Willen wir haben doch sowieso schon zu wenig RAM. Nicht ein Byte
> > würde ich unter diesen Umständen für ein tmpfs spendieren wollen.
> > 
> > Wenn es wirklich so wenige Daten sind dann sollte man das caching einfach
> > dem OS überlassen. Hint: Unbenutzten Speicher benutzt Linux automatisch zum
> > cachen.
> 
> Hallo Sven,
> 
> so ganz blöde finde ich die Idee fast gar nicht. Ein eigenes tmpfs ist vielleicht blöde, aber so im Prinzip ist ja bei mir folgendes Problem.
> 
> Ich habe nach dem splitten ein Verzeichnis mit ca. 330 osm-files, die mit gzip gepackt sind und insgesamt 4.1G Speicher brauchen.
> Jedes mal, wenn ich einen mkgmap prozess starte läd der sich die Dinger von der platte, packt sie aus und rödelt sie durch.
> 
> Da ich keine einfache Möglichkeit gefunden habe, wie man bei Java mehrere Programme in einer VM laufen lassen kann (die vielleicht sowas cachen könnte), gibts vielleicht noch eine andere Möglichkeit.
> 
> Weiß jemand, ob man Linux beibringen kann, die Files einmal komplett in den Speicher zu ziehen und dort zu lassen, damit der nächste Prozess sie sofort wieder nutzen kann ohne primary I/O? Wenn der letzte Prozess fertig ist, müsste man den Speicher wieder freigeben können.
> 
> Kennt einer sowas?

Es ist sehr unwahrscheinlich, dass eine RAM-Disk viel bringt. Wenn Du eine
Datei schreibst unter Linux, dann wird der Inhalt im RAM gecached, weil sich
der Kernel schon denkt, dass Du das bald wieder brauchst. Wenn Du jetzt die
Daten wieder liest, liest der Kernel sie aus dem RAM. Das ganze bleibt solange
im RAM, wie der Kernel das RAM nicht für was besseres braucht. Wenn als nichts
anderes das RAM braucht sind die Daten noch da auch ohne RAM-Disk, wenn was
anderes die Daten aus dem RAM verdängt, dann wurde das RAM gebraucht und die
RAM-Disk blockiert diese Nutzung oder es wird halt geswapped.

Natürlich werden die Daten zusätzlich auf die Platte geschrieben. Das kostet
IO. Wenn Du nichts anderes machst zu dem Zeitpunkt, dann ist das egal. Nur
wenn zum gleichen Zeitpunkt Dein Prozess oder ein anderer auf die Platte
zugreift, dann kommen die sich ggf. ins Gehege. Aber: Um so mehr Du auf der
Platte rummachst, um so wichtiger ist viel RAM, weil das eben Sachen von der
Platte cachen kann. Wenn Du das RAM für die RAM-Disk blockiert hast, nimmst
Du es dem Kernel weg, dass er nicht mehr so viel für den Plattencache hat.

Normalerweise ist der Kernel cleverer als der Mensch, diese Ressourcen richtig
zu verteilen. Natürlich gibt es Fälle, wo das nicht der Fall ist. Aber meist
lohnt der Aufwand nicht, so eine Optimierung zu machen.

Was anderes spielt hier vielleicht noch eine Rolle: Linear von der Platte lesen
ist viel schneller als in kleinen Stücken. Wenn ich das richtig verstehe, dann
hast Du einen Splitter, der ein File liest und 330 Files schreibt. Und zwar
alle gleichzeitig. Dann muss der Disk-Kopf ständig hin- und her zwischen den
Orten, wo die 330 Files liegen. Danach liest Du dann die 330 Files nacheinander
in den mkgmap ein und nudelst sie durch. Dabei kannst Du linear von der Platte
lesen. Es kann natürlich auch andersrum sein: Du schreibst in relativ großen
Blöcken und dadurch linear immer ein Block für die eine Datei, nächster Block
für die nächste. Dann musst Du aber beim lesen alles wieder zusammensuchen.
Eventuell kann man hier durch geeignetes Buffering beim Schreiben der Dateien
ein bischen was erreichen. Aber auch hier gilt wieder, dass der Kernel ja
selbst buffered und man es daher kaum vorraussehen kann, was was hilft.

Und das alles was bringt hängt davon ab, ob IO wirklich der Bottleneck ist.
Die ganze Ein- und Auspackerei und XML-Parserei scheint mir auch problematisch
zu sein.

Warum ist der Splitter eigentlich ein getrenntes Programm? Wenn Du das im RAM
halten willst, dann wäre es vielleicht sinnvoll zu versuchen Splitter und Mkgmap
in ein Java-Binary zu tun.

Jochen
-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298