Rosenlaube
Geonewbie
Nachfolgend einige Informationen, die wir hinsichtlich des nachstehenden Themas geben möchten. Wir hoffen, sie sind interessant für euch...
"Überlegungen zur performanceoptimierten PC-Ausstattung und -einrichtung hinsichtlich des Einsatzes von GSAK mit allen deutschen Geocaches"
oder auch
„Wie kann man den Einsatz von GSAK beschleunigen, wenn alle Caches in Deutschland verwendet und große POIs für Paperless-Caching performant erstellt werden sollen?“
Bitte beachten: Dies ist ein langer „Schlaumeier-Artikel“ für Geocaching- und PC-Junkies - einfach nicht lesen, wenn die vorhandenen PC-Kenntnisse eher gering sind oder die Verwendung vieler Worte oder von PC-Fachbegriffen eine Allergie oder Schreikrämpfe hervorrufen. - Für alle Nebenwirkungen sind die Leser selbst verantwortlich.
Wir wünschen viel Spaß beim Lesen und hoffentlich gute Ideen für Eure persönliche Umsetzung.
Kommentare mit Anregungen und Ideen, konstruktiver Kritik / Fehlerbeseitigungen oder Komplimente sind erwünscht.
Zum Beginn zunächst unsere Nutzungssituation
Wir Rosenlaubes gehören zur Fraktion der "Alle-Caches-haben-wollenden Cacher". Aus verschiedenen Gründen fahren wir oft durch die Republik und möchten dabei die Gelegenheit nutzen, Drive-by-Caching zu betreiben, ohne uns immer mit Hilfe von gezielten Pocket Queries vorzubereiten. Die vorhandenen Nüvis und Oregons steuern dabei das ihre sehr erfolgreich bei. Den Rest dieser Aufgabe erledigen GSAK und diverse Makros.
(Bitte hier keine Diskussion über diesen unseren Wunsch - wir kritisieren auch nicht eure für unsere Ambitionen unpassenden Ansätze - vielen Dank für eure Fairness.)
Wir nutzen dabei GSAK intensiv, um die Ansätze geräte-, performance- und ergonomiegerecht umzusetzen.
Die Ausgangssituation
Nun hat sich unter GSAK 7.6 - bedingt durch die Leistungsschwäche unseres PC, die nicht optimale GSAK-Performance und die (Un-)Menge an gespeicherten Caches - die Antwortzeit dergestalt entwickelt, dass bei Auswertungen eine Antwortzeit von durchaus sehr vielen Minuten (je nach Filtern und Kombinationen) entstand. Die Erzeugung von Auswertungen und von jeweils mehreren POI-Dateien mit jeweils durchaus 150 MB Größe dauerte durchaus pro Schritt eine Stunde oder mehr (auf einem „eigentlich“ ausreichend leistungsstarken PC mit 2 GB Hauptspeicher und einem Athlon XP 3200 bei einem Datenbestand von ca. 130.000 Caches).
Die bekannten Informationen von Clyde zu Leistungsverbesserungen wurden bereits angewendet (Erhöhung des Index auf max. 30 Spalten, „Speed Tips for The Power User“ unter http://www.gsak.net/help/hs22150.htm; bereits dies hilft bei einzelnen direkten Abfragen enorm, nicht aber bei einer Abfragen, bei denen etwa Indexe komplett neu geschrieben werden müssen).
Klar sein sollte, dass hier ein professioneller Vergleich á la "vorher/nachher" nicht beabsichtigt ist – Ziel ist es, die erzielten Verbesserungen vorzustellen und die Fraktion der Cacher, die ALLE Caches in GSAK verwalten wollen, an den erzielten Erkenntnissen teilhaben zu lassen.
Zu den Vorüberlegungen
1. Die aus dieser Sicht nächste GSAK-Version 7.7 sollte laut Ankündigung von Clyde eine Verbesserung mit sich bringen, weil die Verwendung der SQL-Db deutliche Verbesserungen verspricht.
2. Die Hardware sollte neben den Anforderungen an geringe Lautstärke und Performance preiswert sein.
3. Besondere Beachtung musste hierbei die Festplatten-Situation finden, weil Datenbanken sehr intensiv Festplatten nutzen.
4. Die gewählten technische Voraussetzungen haben zwangsweise (wenn man bereit ist, eine kleine Investition zu tragen), Auswirkungen auf den Hauptspeicher.
5. Damit ist der Einsatz von Windows 7 (wegen der Überschreitung von 3 GB Hauptspeicher) in der 64-bittigen Version vorgegeben.
Im Ergebnis wurde der letzte c't-Artikel zur Hardwareauswahl und eigene berufliche Kenntnisse genutzt, um das System entsprechend zusammenzustellen.
Hier werden nur relativ grob die „organisatorischen“ Ideen angesprochen, weil der Artikel ansonsten zu techniklastig wird - bei Fragen hierzu bitte Kontakt zu uns aufnehmen und nicht hier in diesem Fred diskutieren, weil ansonsten die Lesbarkeit des eigentlichen Themas leidet.
Technische Realisierung
Zu 1.
Passenderweise veröffentlichte Clyde während des Systemumbaus die neueste Version 7.7 von GSAK. Insoweit wurde die Aufregung wegen der angekündigten Performanceverbesserungen der SQL-Engine natürlich deutlich erhöht.
Zu 2. und 3.
Die in diesem Bereich wunderbar professionelle Zeitschrift c't half bei der Vorauswahl, insbesondere bei der kostenmäßigen Einschätzung, was sinnvoll und nicht übertrieben ist.
Im Ergebnis haben wir ein neues System zusammengestellt, welches die folgenden Kern-Komponenten umfasst:
- einen Prozessor AMD Phenom II X4 945 mit 4 Cores und sparsamen 95 Watt (jeder größere Prozessor der AMD-Linie verbraucht dreißig meist unbenutzte Watt mehr, ohne dass der höhere Takt deutliche Geschwindigkeitsvorteile verspräche. Bessere Ausstattungen verteuern das System ohne preisleistungsbezogengen Gegenwert)
- einen Hauptspeicher von 6 GB
- zwei baugleiche vorhandene Festplatten (SATA 3, je 250 GB, leise und performant, im Raid-0 betrieben - damit fast lineare Addition der Geschwindigkeiten und Super-Performance)
(Bitte hier keine Diskussion über die Unsicherheit von RAID-0, die Performance steht im Vordergrund, und ausreichendes Wissen über Datensicherung ist vorhanden).
Weitere für andere Zwecke nötige Einbauten sind hier nicht aufgeführt.
Zu 4.
Wegen der datenbanktypisch intensiven Festplattennutzung war von vornherein klar, dass die allgemeine Geschwindigkeit sich unter RAID-0 deutlich verbessern würde, zur weiteren deutlichen Optimierung aber ein Konzept nötig ist, bei dem man Festplattenzugriffe möglichst gänzlich vermeidet.
Ausflug: Zur Idee, eine Ramdisk einzusetzen
Im Internet bestehen in vielen Foren Meinungen zur Nutzung von Ramdisks (also einer Verwendung von Hauptspeicher als "Festplatte"). Viele Tipps sind eindeutig und verweisen diese Idee in den Bereich des Unsinns. Deshalb an dieser Stelle die Information, dass solche Behauptungen - selbst, wenn sie von "Experten" kommen – in diesem Anwendungsfall meist falsch sind.
Warum ist das so? Ganz einfach: Der Einsatz solcher Tools richtet sich am beabsichtigten Verwendungszweck aus, und viel Hauptspeicher ohne eine Ramdisk hat im Grundsatz den Einsatz von Programmen im Sinn. Hier geht es aber um den Spezialfall, in einem „Datenbankbetrieb“ die Festplattenzugriffe zur Verbesserung der Geschwindigkeit zu beschleunigen (oder besser: zu vermeiden). Die Verwendung einer Ramdisk ermöglicht dabei eine ca. 200fach höheren Geschwindigkeit als beim Einsatz einer Festplatte (auch bei Einsatz von RAID-0) und ist damit selbstverständlich sinnvoll. Also: Nicht von allgemeinen oder Amateur-Artikeln in PC-Foren irritieren lassen... und weiterlesen.
Hierzu haben wir verschiedene Ramdisks geprüft, die teilweise unter Windows 7 64 Bit recht spröde agierten. Letztlich stellte sich die „DATARAM RAMDisk“ (kostenfrei nutzbar) als geeignet und einfach zu integrieren heraus. Dieser wurden etwas mehr als 2 GB Hauptspeicher zugeordnet, ein Laufwerksbuchstabe zugewiesen und diese mit NTFS formatiert. Nun steht sie zur Verwendung bereit – und kann sogar (hier nicht betrachtet) für TEMP verwendet werden, hat also sogar allgemein das Potential, über den hier beschriebenen Zweck hinaus JEDEN Festplattenzugriff, der temporäre Dateien erzeugt, erheblichst zu beschleunigen.
Info: Wenn man eine Ramdisk betreibt, sollte Vorsorge gegen Datenverlust betrieben werden, denn die Inhalte einer Ramdisk sind grundsätzlich flüchtig... (oder man ergreift andere geeignete Maßnahmen, um Datenverlust zu verhindern).
Ausflug: Vorsorge gegen Datenverlust
Allgemein ist eine regelmäßige häufige Datensicherung Pflicht.
Wenn die Pocket Queries in die Ramdisk eingelesen werden sollen (dieser Fall verspricht erhebliche Geschwindigkeitsvorteile), muss diese entweder so eingestellt werden, dass die Inhalte bei Ausschalten des PC auf die Festplatten geschrieben werden (diese Funktion bietet nicht jede Ramdisk), oder die GSAK-Daten müssen per Hand (oder Batch) nach dem Einfügen auf die Platte kopiert werden (in den Ordner von GSAK, also unter Windows 7 „C:\Program Files (x86)\gsak\data“ und unter XP „C:\Programme\gsak\data“).
Bei dieser Methode muss in GSAK natürlich im Menü „Tools/Options/General/Database Folder“ jeweils der Ort der Datenbank („Laufwerksbuchstabe:\Ordnername\“) in der Ramdisk eingestellt werden.
Die bei der DATARAM-Ramdisk enthaltene Option, die Daten beim Herunterfahren des PC automatisch zu sichern, verzögert jedes Ausschalten des PC um Minuten, weil im vorliegenden Fall dann immer erst die 2 GB von der Ramdisk auf die Festplatten geschrieben werden müssen. Auf diese Optionen haben wir verzichtet und nutzen sie nicht, weil wir nicht jeden PC-Ausschaltvorgang verlangsamt wissen wollen.
Zu 5.
Windows 7 64 Bit ist wegen der Nutzung von mehr als 3,x GB Hauptspeicher erforderlich, wenn dieses Konzept genutzt werden soll.
Resumee - Auswirkungen bei den verschiedenen Anwendungsfällen
Nach Aufbau des Systems ergeben sich nun folgende Änderungen:
=> Das Erzeugen von POIs mit jeweils ca. 60.000 - 70.000 Caches inkl. Hints und allen vorhandenen Logs (Tradis, Webcams, Earthes, Letterboxes in einer POI bis 250 km Umkreis, eine POI für diese Caches mit mehr als 250 km Entfernung, alle Multis in einer Eigenen) dauert nun nur noch
-> je wenige Minuten, wenn die Daten im RAID-0 auf den beiden schnellen Festplatten liegen.
Die Verbesserung der Antwortzeit liegt beim hier beschriebenen System sicherlich mindestens im Bereich des 10-fachen im Vergleich zum Altsystem
-> keine 2 Minuten, wenn die Daten in der Ramdisk angelegt werden.
Die Verbesserung der Antwortzeit liegt beim hier beschriebenen System sicherlich im Bereich des 30-fachen im Vergleich zum Altsystem.
=> Komplexe Auswertungen mit Filtern/Makros haben vergleichbare Geschwindigkeitsgewinne zu verzeichnen. Sie profitieren je nach Anwendungsfall ebenfalls vom Einsatz der Ramdisk. Gleichwohl existieren hier Unterschiede:
Wenn die Operationen lediglich den Einsatz der CPUs erfordern (also etwa bei Rechenoperationen), spielt eine Ramdisk keine Rolle und kein Geschwindigkeitsvorteil tritt ein.
Wenn die Operationen Festplattenzugriffe auslösen (Temporärdateien oder Indexe neu erzeugen), löst der Einsatz der Ramdisk massivste Geschwindigkeitsvorteile aus.
Festzustellen ist: Die Performance hat sich - wohl auch wegen der Verbesserungen der Version 7.7, aber natürlich auch sehr wegen der besseren Hard- und Software - dramatisch verbessert und letztlich alle Anforderungen mehr als zufriedenstellend erfüllt. Auswertungen und POIs können sozusagen mal eben erzeugt werden, die Wartezeiten sind äußerst erfreulich.
Die Festplattenzugriffe finden beim Ramdisk-Modus nur noch statt, wenn das auf den Festplatten lokal installierte GSAK seine Programm- (und nicht die Daten-)-Dateien laden will. Ansonsten herrscht ein nicht nur schneller, sondern auch leiser Betrieb. Auch diesen Umstand könnte man noch verbessern...
Ob Euch der Geschwindigkeitsvorteil bei Verwendung einer Ramdisk ca. 85 Euro für 2 GB Hauptspeicher Wert ist, muss ein Jeder für sich selbst entscheiden.
Der PC hat ca. 4 GB für seine sonstigen Aufgaben zur Verfügung und ist damit generell bestens ausgestattet. Durch die Ramdisk gewinnt er aber zusätzlich massiv an Eignung für den Einsatz von GSAK.
Prämissen und kritische Empfehlungen zur Verwendung dieser Idee
Klar sollte sein, dass ein Konzept, welches den Einsatz einer Ramdisk vermeidet, zumindest für den weniger erfahrenen Anwender wahrscheinlich insgesamt wesentlich einfacher und aus Sicht der Daten sicherer sein dürfte. Gleichwohl lässt sich nicht ignorieren, dass die hier geschilderten positiven Auswirkungen ohne die zwei gleichzeitig arbeitenden Festplatten unter RAID-0 und ohne Ramdisk nicht annähernd zu realisieren sind.
Noch einmal in anderen Worten: Wer mit den hier dargestellten technischen Szenarien nicht klar kommt, ist besser beraten, die Ramdisk nicht einzusetzen und sich die 85 Euro einzusparen. Die brutale „Mehr-Performance“ eines aktuellen Systems gegenüber einem Alt-PC mit gleichzeitiger Optimierung der Indexe reicht für allgemeine Zwecke oder kleinere Datenbestände völlig aus.
Weiterer Nutzen
Das Konzept „RAID-0 + Ramdisk“ ist im Falle von GSAK mit großen Datenbeständen dermaßen leistungsstark, dass wir die vermutlich archivierten Caches (also die, die nach einem vollständigen Intervall kein ausreichend aktuelles GPX-Update-Datum aufweisen) nicht mehr löschen. Diese werden in eine eigene Datenbank ausgelagert und für Recherchezwecke vorgehalten. Somit entwickelt sich als Parallelnutzen eine schöne Datenbank vermutlich archivierter Caches, die man sehr gut mit den verschiedenen Cacherkollegen zum Schwadronieren nutzen kann.
Die Gesamtkosten dieser Umsetzung halten sich in dem Rahmen, der bei einer Beschaffung eines neuen PC eh erforderlich ist.
Ausblick
Zur Automatisierung werden wir, wenn mal wieder freie Zeit zu vermelden ist, noch Verbesserungen herstellen:
„Automatisches“ Kopieren der Datenbanken in die Ramdisk (die aus Datensicherheitsgründen lokal auf den Festplatten liegen) per Batch.
Anlegen eines ständig vorhandenen zweiten GSAK-Profils, welches nach dem Kopieren der Datenbanken in die Ramdisk nicht immer den Aufbau der Indexe vornehmen muss.
„Automatisches“ Kopieren der Datenbanken von der Ramdisk lokal auf die Festplatten, damit die Daten „sicher“ sind per Batch.
„Automatisches“ zusätzliches Kopieren der lokal liegenden Datenbanken auf eine zweite Festplatte im Rahmen des angesprochenen Batches.
GSAK scheint wohl für manche Aufgaben nur zwei der vier Cores zu nutzen – zumindest auf unserem System werden oft nicht alle Prozessorkerne gleichzeitig verwendet. Hier „lockt“ weiteres Geschwindigkeitspotential bei prozessorlastigen Operationen. Vielleicht kann sich das mal einer der SQL-Profis anschauen.
O. T.: Generierung von einer einzigen POI-Dateien mit ALLEN Caches. Es scheint so zu sein, dass entweder GSAK oder das Makro „garmin_nuvi_exportgpx.gsk“ oder der POI-Loader ein Problem mit mehr als 64xxx Caches besitzt (ein 16-Bit-Problem!?). Vielleicht macht das aber keinen Sinn, wenn Nüvi oder Oregon dann zu langsam werden.
So, nach diesem langen Artikel wünschen wir euch eine schöne Cachingzeit.
Rosenlaube
"Überlegungen zur performanceoptimierten PC-Ausstattung und -einrichtung hinsichtlich des Einsatzes von GSAK mit allen deutschen Geocaches"
oder auch
„Wie kann man den Einsatz von GSAK beschleunigen, wenn alle Caches in Deutschland verwendet und große POIs für Paperless-Caching performant erstellt werden sollen?“
Bitte beachten: Dies ist ein langer „Schlaumeier-Artikel“ für Geocaching- und PC-Junkies - einfach nicht lesen, wenn die vorhandenen PC-Kenntnisse eher gering sind oder die Verwendung vieler Worte oder von PC-Fachbegriffen eine Allergie oder Schreikrämpfe hervorrufen. - Für alle Nebenwirkungen sind die Leser selbst verantwortlich.
Wir wünschen viel Spaß beim Lesen und hoffentlich gute Ideen für Eure persönliche Umsetzung.
Kommentare mit Anregungen und Ideen, konstruktiver Kritik / Fehlerbeseitigungen oder Komplimente sind erwünscht.
Zum Beginn zunächst unsere Nutzungssituation
Wir Rosenlaubes gehören zur Fraktion der "Alle-Caches-haben-wollenden Cacher". Aus verschiedenen Gründen fahren wir oft durch die Republik und möchten dabei die Gelegenheit nutzen, Drive-by-Caching zu betreiben, ohne uns immer mit Hilfe von gezielten Pocket Queries vorzubereiten. Die vorhandenen Nüvis und Oregons steuern dabei das ihre sehr erfolgreich bei. Den Rest dieser Aufgabe erledigen GSAK und diverse Makros.
(Bitte hier keine Diskussion über diesen unseren Wunsch - wir kritisieren auch nicht eure für unsere Ambitionen unpassenden Ansätze - vielen Dank für eure Fairness.)
Wir nutzen dabei GSAK intensiv, um die Ansätze geräte-, performance- und ergonomiegerecht umzusetzen.
Die Ausgangssituation
Nun hat sich unter GSAK 7.6 - bedingt durch die Leistungsschwäche unseres PC, die nicht optimale GSAK-Performance und die (Un-)Menge an gespeicherten Caches - die Antwortzeit dergestalt entwickelt, dass bei Auswertungen eine Antwortzeit von durchaus sehr vielen Minuten (je nach Filtern und Kombinationen) entstand. Die Erzeugung von Auswertungen und von jeweils mehreren POI-Dateien mit jeweils durchaus 150 MB Größe dauerte durchaus pro Schritt eine Stunde oder mehr (auf einem „eigentlich“ ausreichend leistungsstarken PC mit 2 GB Hauptspeicher und einem Athlon XP 3200 bei einem Datenbestand von ca. 130.000 Caches).
Die bekannten Informationen von Clyde zu Leistungsverbesserungen wurden bereits angewendet (Erhöhung des Index auf max. 30 Spalten, „Speed Tips for The Power User“ unter http://www.gsak.net/help/hs22150.htm; bereits dies hilft bei einzelnen direkten Abfragen enorm, nicht aber bei einer Abfragen, bei denen etwa Indexe komplett neu geschrieben werden müssen).
Klar sein sollte, dass hier ein professioneller Vergleich á la "vorher/nachher" nicht beabsichtigt ist – Ziel ist es, die erzielten Verbesserungen vorzustellen und die Fraktion der Cacher, die ALLE Caches in GSAK verwalten wollen, an den erzielten Erkenntnissen teilhaben zu lassen.
Zu den Vorüberlegungen
1. Die aus dieser Sicht nächste GSAK-Version 7.7 sollte laut Ankündigung von Clyde eine Verbesserung mit sich bringen, weil die Verwendung der SQL-Db deutliche Verbesserungen verspricht.
2. Die Hardware sollte neben den Anforderungen an geringe Lautstärke und Performance preiswert sein.
3. Besondere Beachtung musste hierbei die Festplatten-Situation finden, weil Datenbanken sehr intensiv Festplatten nutzen.
4. Die gewählten technische Voraussetzungen haben zwangsweise (wenn man bereit ist, eine kleine Investition zu tragen), Auswirkungen auf den Hauptspeicher.
5. Damit ist der Einsatz von Windows 7 (wegen der Überschreitung von 3 GB Hauptspeicher) in der 64-bittigen Version vorgegeben.
Im Ergebnis wurde der letzte c't-Artikel zur Hardwareauswahl und eigene berufliche Kenntnisse genutzt, um das System entsprechend zusammenzustellen.
Hier werden nur relativ grob die „organisatorischen“ Ideen angesprochen, weil der Artikel ansonsten zu techniklastig wird - bei Fragen hierzu bitte Kontakt zu uns aufnehmen und nicht hier in diesem Fred diskutieren, weil ansonsten die Lesbarkeit des eigentlichen Themas leidet.
Technische Realisierung
Zu 1.
Passenderweise veröffentlichte Clyde während des Systemumbaus die neueste Version 7.7 von GSAK. Insoweit wurde die Aufregung wegen der angekündigten Performanceverbesserungen der SQL-Engine natürlich deutlich erhöht.
Zu 2. und 3.
Die in diesem Bereich wunderbar professionelle Zeitschrift c't half bei der Vorauswahl, insbesondere bei der kostenmäßigen Einschätzung, was sinnvoll und nicht übertrieben ist.
Im Ergebnis haben wir ein neues System zusammengestellt, welches die folgenden Kern-Komponenten umfasst:
- einen Prozessor AMD Phenom II X4 945 mit 4 Cores und sparsamen 95 Watt (jeder größere Prozessor der AMD-Linie verbraucht dreißig meist unbenutzte Watt mehr, ohne dass der höhere Takt deutliche Geschwindigkeitsvorteile verspräche. Bessere Ausstattungen verteuern das System ohne preisleistungsbezogengen Gegenwert)
- einen Hauptspeicher von 6 GB
- zwei baugleiche vorhandene Festplatten (SATA 3, je 250 GB, leise und performant, im Raid-0 betrieben - damit fast lineare Addition der Geschwindigkeiten und Super-Performance)
(Bitte hier keine Diskussion über die Unsicherheit von RAID-0, die Performance steht im Vordergrund, und ausreichendes Wissen über Datensicherung ist vorhanden).
Weitere für andere Zwecke nötige Einbauten sind hier nicht aufgeführt.
Zu 4.
Wegen der datenbanktypisch intensiven Festplattennutzung war von vornherein klar, dass die allgemeine Geschwindigkeit sich unter RAID-0 deutlich verbessern würde, zur weiteren deutlichen Optimierung aber ein Konzept nötig ist, bei dem man Festplattenzugriffe möglichst gänzlich vermeidet.
Ausflug: Zur Idee, eine Ramdisk einzusetzen
Im Internet bestehen in vielen Foren Meinungen zur Nutzung von Ramdisks (also einer Verwendung von Hauptspeicher als "Festplatte"). Viele Tipps sind eindeutig und verweisen diese Idee in den Bereich des Unsinns. Deshalb an dieser Stelle die Information, dass solche Behauptungen - selbst, wenn sie von "Experten" kommen – in diesem Anwendungsfall meist falsch sind.
Warum ist das so? Ganz einfach: Der Einsatz solcher Tools richtet sich am beabsichtigten Verwendungszweck aus, und viel Hauptspeicher ohne eine Ramdisk hat im Grundsatz den Einsatz von Programmen im Sinn. Hier geht es aber um den Spezialfall, in einem „Datenbankbetrieb“ die Festplattenzugriffe zur Verbesserung der Geschwindigkeit zu beschleunigen (oder besser: zu vermeiden). Die Verwendung einer Ramdisk ermöglicht dabei eine ca. 200fach höheren Geschwindigkeit als beim Einsatz einer Festplatte (auch bei Einsatz von RAID-0) und ist damit selbstverständlich sinnvoll. Also: Nicht von allgemeinen oder Amateur-Artikeln in PC-Foren irritieren lassen... und weiterlesen.
Hierzu haben wir verschiedene Ramdisks geprüft, die teilweise unter Windows 7 64 Bit recht spröde agierten. Letztlich stellte sich die „DATARAM RAMDisk“ (kostenfrei nutzbar) als geeignet und einfach zu integrieren heraus. Dieser wurden etwas mehr als 2 GB Hauptspeicher zugeordnet, ein Laufwerksbuchstabe zugewiesen und diese mit NTFS formatiert. Nun steht sie zur Verwendung bereit – und kann sogar (hier nicht betrachtet) für TEMP verwendet werden, hat also sogar allgemein das Potential, über den hier beschriebenen Zweck hinaus JEDEN Festplattenzugriff, der temporäre Dateien erzeugt, erheblichst zu beschleunigen.
Info: Wenn man eine Ramdisk betreibt, sollte Vorsorge gegen Datenverlust betrieben werden, denn die Inhalte einer Ramdisk sind grundsätzlich flüchtig... (oder man ergreift andere geeignete Maßnahmen, um Datenverlust zu verhindern).
Ausflug: Vorsorge gegen Datenverlust
Allgemein ist eine regelmäßige häufige Datensicherung Pflicht.
Wenn die Pocket Queries in die Ramdisk eingelesen werden sollen (dieser Fall verspricht erhebliche Geschwindigkeitsvorteile), muss diese entweder so eingestellt werden, dass die Inhalte bei Ausschalten des PC auf die Festplatten geschrieben werden (diese Funktion bietet nicht jede Ramdisk), oder die GSAK-Daten müssen per Hand (oder Batch) nach dem Einfügen auf die Platte kopiert werden (in den Ordner von GSAK, also unter Windows 7 „C:\Program Files (x86)\gsak\data“ und unter XP „C:\Programme\gsak\data“).
Bei dieser Methode muss in GSAK natürlich im Menü „Tools/Options/General/Database Folder“ jeweils der Ort der Datenbank („Laufwerksbuchstabe:\Ordnername\“) in der Ramdisk eingestellt werden.
Die bei der DATARAM-Ramdisk enthaltene Option, die Daten beim Herunterfahren des PC automatisch zu sichern, verzögert jedes Ausschalten des PC um Minuten, weil im vorliegenden Fall dann immer erst die 2 GB von der Ramdisk auf die Festplatten geschrieben werden müssen. Auf diese Optionen haben wir verzichtet und nutzen sie nicht, weil wir nicht jeden PC-Ausschaltvorgang verlangsamt wissen wollen.
Zu 5.
Windows 7 64 Bit ist wegen der Nutzung von mehr als 3,x GB Hauptspeicher erforderlich, wenn dieses Konzept genutzt werden soll.
Resumee - Auswirkungen bei den verschiedenen Anwendungsfällen
Nach Aufbau des Systems ergeben sich nun folgende Änderungen:
=> Das Erzeugen von POIs mit jeweils ca. 60.000 - 70.000 Caches inkl. Hints und allen vorhandenen Logs (Tradis, Webcams, Earthes, Letterboxes in einer POI bis 250 km Umkreis, eine POI für diese Caches mit mehr als 250 km Entfernung, alle Multis in einer Eigenen) dauert nun nur noch
-> je wenige Minuten, wenn die Daten im RAID-0 auf den beiden schnellen Festplatten liegen.
Die Verbesserung der Antwortzeit liegt beim hier beschriebenen System sicherlich mindestens im Bereich des 10-fachen im Vergleich zum Altsystem
-> keine 2 Minuten, wenn die Daten in der Ramdisk angelegt werden.
Die Verbesserung der Antwortzeit liegt beim hier beschriebenen System sicherlich im Bereich des 30-fachen im Vergleich zum Altsystem.
=> Komplexe Auswertungen mit Filtern/Makros haben vergleichbare Geschwindigkeitsgewinne zu verzeichnen. Sie profitieren je nach Anwendungsfall ebenfalls vom Einsatz der Ramdisk. Gleichwohl existieren hier Unterschiede:
Wenn die Operationen lediglich den Einsatz der CPUs erfordern (also etwa bei Rechenoperationen), spielt eine Ramdisk keine Rolle und kein Geschwindigkeitsvorteil tritt ein.
Wenn die Operationen Festplattenzugriffe auslösen (Temporärdateien oder Indexe neu erzeugen), löst der Einsatz der Ramdisk massivste Geschwindigkeitsvorteile aus.
Festzustellen ist: Die Performance hat sich - wohl auch wegen der Verbesserungen der Version 7.7, aber natürlich auch sehr wegen der besseren Hard- und Software - dramatisch verbessert und letztlich alle Anforderungen mehr als zufriedenstellend erfüllt. Auswertungen und POIs können sozusagen mal eben erzeugt werden, die Wartezeiten sind äußerst erfreulich.
Die Festplattenzugriffe finden beim Ramdisk-Modus nur noch statt, wenn das auf den Festplatten lokal installierte GSAK seine Programm- (und nicht die Daten-)-Dateien laden will. Ansonsten herrscht ein nicht nur schneller, sondern auch leiser Betrieb. Auch diesen Umstand könnte man noch verbessern...
Ob Euch der Geschwindigkeitsvorteil bei Verwendung einer Ramdisk ca. 85 Euro für 2 GB Hauptspeicher Wert ist, muss ein Jeder für sich selbst entscheiden.
Der PC hat ca. 4 GB für seine sonstigen Aufgaben zur Verfügung und ist damit generell bestens ausgestattet. Durch die Ramdisk gewinnt er aber zusätzlich massiv an Eignung für den Einsatz von GSAK.
Prämissen und kritische Empfehlungen zur Verwendung dieser Idee
Klar sollte sein, dass ein Konzept, welches den Einsatz einer Ramdisk vermeidet, zumindest für den weniger erfahrenen Anwender wahrscheinlich insgesamt wesentlich einfacher und aus Sicht der Daten sicherer sein dürfte. Gleichwohl lässt sich nicht ignorieren, dass die hier geschilderten positiven Auswirkungen ohne die zwei gleichzeitig arbeitenden Festplatten unter RAID-0 und ohne Ramdisk nicht annähernd zu realisieren sind.
Noch einmal in anderen Worten: Wer mit den hier dargestellten technischen Szenarien nicht klar kommt, ist besser beraten, die Ramdisk nicht einzusetzen und sich die 85 Euro einzusparen. Die brutale „Mehr-Performance“ eines aktuellen Systems gegenüber einem Alt-PC mit gleichzeitiger Optimierung der Indexe reicht für allgemeine Zwecke oder kleinere Datenbestände völlig aus.
Weiterer Nutzen
Das Konzept „RAID-0 + Ramdisk“ ist im Falle von GSAK mit großen Datenbeständen dermaßen leistungsstark, dass wir die vermutlich archivierten Caches (also die, die nach einem vollständigen Intervall kein ausreichend aktuelles GPX-Update-Datum aufweisen) nicht mehr löschen. Diese werden in eine eigene Datenbank ausgelagert und für Recherchezwecke vorgehalten. Somit entwickelt sich als Parallelnutzen eine schöne Datenbank vermutlich archivierter Caches, die man sehr gut mit den verschiedenen Cacherkollegen zum Schwadronieren nutzen kann.
Die Gesamtkosten dieser Umsetzung halten sich in dem Rahmen, der bei einer Beschaffung eines neuen PC eh erforderlich ist.
Ausblick
Zur Automatisierung werden wir, wenn mal wieder freie Zeit zu vermelden ist, noch Verbesserungen herstellen:
„Automatisches“ Kopieren der Datenbanken in die Ramdisk (die aus Datensicherheitsgründen lokal auf den Festplatten liegen) per Batch.
Anlegen eines ständig vorhandenen zweiten GSAK-Profils, welches nach dem Kopieren der Datenbanken in die Ramdisk nicht immer den Aufbau der Indexe vornehmen muss.
„Automatisches“ Kopieren der Datenbanken von der Ramdisk lokal auf die Festplatten, damit die Daten „sicher“ sind per Batch.
„Automatisches“ zusätzliches Kopieren der lokal liegenden Datenbanken auf eine zweite Festplatte im Rahmen des angesprochenen Batches.
GSAK scheint wohl für manche Aufgaben nur zwei der vier Cores zu nutzen – zumindest auf unserem System werden oft nicht alle Prozessorkerne gleichzeitig verwendet. Hier „lockt“ weiteres Geschwindigkeitspotential bei prozessorlastigen Operationen. Vielleicht kann sich das mal einer der SQL-Profis anschauen.
O. T.: Generierung von einer einzigen POI-Dateien mit ALLEN Caches. Es scheint so zu sein, dass entweder GSAK oder das Makro „garmin_nuvi_exportgpx.gsk“ oder der POI-Loader ein Problem mit mehr als 64xxx Caches besitzt (ein 16-Bit-Problem!?). Vielleicht macht das aber keinen Sinn, wenn Nüvi oder Oregon dann zu langsam werden.
So, nach diesem langen Artikel wünschen wir euch eine schöne Cachingzeit.
Rosenlaube