Aufsatz zum Thema Performancesteigerung mit /cachepraxisdb
Verfasst: Sonntag 11. Mai 2008, 10:35
Liebe Mitstreiter,
ich habe einmal intensiv das Verhalten des FastObjects Datenbankservers von TM in Verbindung mit dem /cachepraxisdb untersucht, speziell im Hinblick auf Nebenwirkungen oder Unverträglichkeiten, auch besonders bei knappem Arbeitsspeicher bzw. sehr großen Praxisdatenbanken. Bei dieser Gelegenheit habe ich auch die Funktion von TM unter 64-Bit Windows angetestet (unter Windows 2008 Server). Das folgende beschreibe ich ausschließlich im Hinblick auf den Einsatz von TM am Server und gehe dabei auf 32-Bit Betriebssysteme (getestet mit Windows XP) und 64-Bit Betriebssystemen (wie gesagt, Windows 2008 Server) ein. Die Optimierung von TM als Client ist eine andere Sache und nicht Bestandteil dieses Aufsatzes.
Grundsätzliches
TM wie auch der FastObjects-Datenbankserver sind 32-Bit Anwendungen, d.h. sie bekommen von Windows üblicherweise nur maximal 2 GB als Programm-Speicher zugewiesen. (Man kann das mit Windows-Tuning-Parametern auf 3 GB erhöhen, ob das sinnvoll ist, bezweifle ich aus Gründen der Stabilität erst einmal. Für diesen Aufsatz, und auch in der Praxis, lasse ich es also.)
Unter einem 64-Bit Windows lief TurboMed offenbar einwandfrei, allerdings arbeitete ich nur an einem Testsystem (Windows 2008 Server) und habe deshalb nicht intensiv alle Funktionen ausprobiert, wie man es an einem Produktivrechner wohl tun würde. Es hat jedoch ohne sichtbare Probleme "gezuckt". Allerdings konnte der Datenbankserver das bekannte F-Symbol nicht im System-Tray anzeigen, wenn er als Dienst eingerichtet war. Das lag vermutlich an der geänderten Arbeitsweise der Konsolen unter Windows 2008 Server. War jedoch nur kosmetisch - der Dienst lief dennoch.
Caching unter Windows
Das folgende ist vereinfacht dargestellt. Die reale Arbeitsweise ist naturgemäß recht komplex und in vielen, seeehr vielen technischen Dokumenten dargestellt. Ich habe vieles davon gelesen und fasse es natürlich nur knapp zusammen. Bitte also keine Aufschreie, wenn das eine oder andere stark komprimiert wurde - für den Einsatz unter TM (am Server) unterschlage ich jedoch nichts essentielles.
Windows nutzt den Arbeitsspeicher, der nicht den Programmen zugewiesen wurde, als Datei-Cache und nennt diesen System Cache. (Wichtig, diesen Begriff gut merken!) Dabei legt es Dateiteile, die von der Festplatte abgerufen wurden, im Speicher ab. Fragt ein Programm dann diesen Dateiteil erneut ab, so bedient Windows die Anfrage aus dem System Cache, also direkt aus RAM, und muss nicht auf die Festplatte zugreifen. Dadurch entstehen massive Geschwindigkeitsvorteile. (Ab hier verwende ich vereinfacht Cache für den System Cache.)
Windows nutzt dabei natürlich viele clevere Mechanismen, um den Cache effizient zu nutzen. Ein paar einfache Grundregeln sind jedoch:
Aus dem ganzen ergibt sich folgende Kette von logischen Konsequenzen:
Das habe ich nicht en detail evaluiert, gehe aber von folgender Arbeitsweise aus, wie sie bei Datenbankservern allgemein praktiziert wird: Einige Systemrelevante Daten (z.B. Indexdaten, manchmal auch Benutzerdaten, also echter Dateninhalt) werden zunächst im Arbeitsspeicher gehalten, bevor sie auf die Platte geschrieben werden. Das spart Zeit, weil das Schreiben einige Sekunden später gemacht werden kann, wenn der Rechner wieder nichts mehr zu tun hat. Wenn man jedoch die Datenbanken sichern möchte, sollten doch schon alle relevanten Daten in der physikalischen Datei sein, sonst sichert man nur halbe Sachen. Außerdem sollte die Datenbank ruhiggestellt sein, es sollte also nicht darin geschrieben werden. Mit dem Starten des Backup-Modes wird FastObjects mitgeteilt, dass er bitteschön einmal alles wegschreiben soll, was noch nicht geschrieben wurde. Bis zum Ende des Backup-Modes schreibt er dann in sogenannte Logdateien, die sich bei TM im Verzeichnis PraxisDB\recovery befinden. Gelesen wird nach wie vor direkt aus den Dateien objects.dat und objects.idx. Beim Ende des Backup-Modes werden dann alle Schreibvorgänge, die der Datenbankserver sich in den Logdateien "gemerkt" hat, in die Datenbank integriert. Während der Sicherung sind die Datenbanken also schön konsistent und weil alle Programme (Sicherungsprogramm und der Datenbankserver) nur lesend darauf zugreifen, gibt es auch keine Konflikte.
(Im Folgenden spreche ich nur noch von Datenbank und meine dabei natürlich die beiden Dateien objects.dat und objects.idx, die zusammen die TM-Praxisdatenbank ausmachen.)
Was genau macht denn nun TMAdmin /cachepraxisdb?
Verblüffend wenig: TMAdmin bringt den Datenbankserver kurz in den Backup-Modus, liest dann einfach einmal die kompletten Datenbankdateien von vorne bis hinten durch und beendet den Back-Modus wieder. Das ist ein ebenso simpler wie cleverer Ansatz, das System zu beschleunigen. Denn dadurch wird Windows gezwungen, sich einmal mit dem kompletten Inhalt der beiden Dateien zu beschäftigen, was zur Folge hat, dass die Daten komplett in den System-Cache wandern. Das kann man gut beobachten: Starten Sie den Task-Manager und gehen Sie auf den Reiter Systemleistung (XP und Windows 2003 Server) bzw. Leistung (Windows 2008 und Vista). Dort finden Sie im Block "Physikalischer Speicher" den Wert "Systemcache" (XP und Windows 2003) bzw. "Im Cache" (Windows 2008 und Vista). Bei einem frisch gestarteten System ohne nennenswerte laufende Programme (also auf dem Server idealerweise nur Windows und der FastObjects Datenbankserver) ist dieser Wert recht niedrig. Rufen Sie nun TMAdmin /cachepraxisdb auf und beobachten Sie, wie der Wert schnell ansteigt. Am Ende ist er recht genau um die Summe der Größen der beiden Datenbankdateien objects.dat und objects.idx angewachsen - Windows hat nun beide Daten - die komplette Praxisdatenbank - im Arbeitsspeicher.
Probieren Sie dann doch einmal folgendes: Starten Sie TMAdmin /cachepraxisdb einfach gleich noch einmal. Das wird dann sehr viel schneller gehen, als beim ersten Durchlauf, denn Windows hat die Datenbank ja schon im Speicher und bedient TMAdmin's einfaches Durchlesen der Daten direkt aus dem Cache! (Wenn es nicht wirklich schneller ist, dann ist Ihre Datenbank entweder sehr klein, oder Sie haben nicht genügend Arbeitsspeicher für den Cache.)
Dieser Ansatz ist deshalb so clever, weil sich der Datenbankserver selbst nicht um das Cachen im großen Stil kümmern muss. Das könnte er als 32-Bit Applikation auch gar nicht, denn selbst unter einem 64-Bit Windows bekommt er nur bzw. kann er nur mit 2 GB Speicher umgehen! Wenn die Praxisdatenbank größer als 2 GB ist (objects.dat und objects.idx zusammengerechnet) käme FastObjects nicht weiter und könnte nicht alle Daten cachen. Windows hat diese Limitierung nicht und kann den ganzen verfügbaren Arbeitsspeicher effizient nutzen.
Risiken von /cachepraxisdb
Risiken und Nebenwirkungen hat das meiner Ansicht nach gar keine! Gehen wir einmal davon aus, dass Windows den Cache gut im Griff hat (das ist schließlich eine der Hauptaufgaben des Betriebssystems), dann passiert hier nichts Außergewöhnliches. Es kann damit auch keine negativen Auswirkungen auf Hausbesuchsmodule, Datensicherungen, usw. geben, denn es wird kein Programm angewiesen, irgendetwas anders als sonst zu machen! Auch hat prinzipiell der verfügbare Arbeitsspeicher keine Auswirkungen auf TMAdmin /cachepraxisdb. Man kann das selbst dann durchführen, wenn die PraxisDB 10 GB groß ist, der Rechner aber nur 1 GB Arbeitsspeicher hat. Natürlich bringt das auch keine Vorteile, denn Windows schiebt die ersten Gigabyte der Datenbank, die es gerade in den Cache gepackt hat, beim Lesen der nächsten Gigabyte Daten direkt wieder raus. Und es dürfte Glückssache sein wenn der Patient, den ich gerade aufrufen will, just eben in dem knappen Cache ist und nicht von der Festplatte nachgelesen werden muss. Aber es schadet auch nicht!
Nachteile dieses Ansatzes
Nachteile bestehen dahingehend, als dass der Datenbankserver keinen direkten Einfluss auf den Cache hat. (Er könnte technisch zwar Eingriff nehmen und den Cache zu seinen Gunsten manipulieren. Es gibt Funktionen, mit denen Applikationen den Cache von Windows beeinflussen können, aber diese werden - meiner Recherche nach - nur von Windows Komponenten und Programmen wie Exchange und SQL Server genutzt. Ich finde, das ist auch so in Ordnung, denn wenn alle Programme sich selbst den Cache zuordnen wollen, wäre ein System wohl kaum mehr lauffähig. Ein Moderator (Windows), der sich um den Cache alleine kümmert, ist sicherlich sinnvoll und nötig.)
Wenn also der Datenbankserver den Cache lange nicht nutzt (TM tut nichts und langweilt sich), ein anderes Programm aber intensiv von der Festplatte liest (ich schaue mir z.B. ein Video an oder spiele Musik ab), dann wird der Cache langsam alle TM-Daten altern lassen und letztlich zugunsten der neuen Daten (hier im Beispiel die Videos und Musik) aus dem Cache werfen. Beim nächsten Zugriff auf die TM-Daten müssen sie wieder frisch von der Festplatte gelesen werden und sind erst ab diesem Zeitpunkt wieder im Cache.
Meine eigene Frage in dem anderen Thread "wie lange hält /cachepraxisdb" beantwortet sich deshalb so: Es hält so lange, wie die Daten von Windows im System Cache gehalten werden - entweder, weil schlichtweg genug RAM für das Cachen aller Plattenzugriffe da ist, oder weil kein anderes Programm läuft, das die Festplatte und damit den Cache auch intensiv nutzt und die TM-Daten wegen Alterung irgendwann aus dem Cache fliegen.
Was ist mit der Datensicherung?
Eine Datensicherung beeinflusst den Systemcache damit theoretisch eigentlich nicht, denn es wird streng genommen auch nur die Datenbank komplett gelesen - wenn sie vorher im Cache war, wird sie dadurch ja nicht aus dem Cache geworfen. Aber: Bei einer Datensicherung wird auch die Sicherungsdatei geschrieben, und die ist bei großen Praxisdatenbanken auch recht groß (kleiner zwar, wegen Komprimierung, aber immer noch beachtlich). Wenn der Arbeitsspeicher, bzw. genauer der für den Cache nutzbare Teil, nun gerade groß genug war, um die Praxisdatenbank zu cachen, passiert folgendes: Direkt nach dem Aufruf von TMAdmin /cachepraxisdb ist das System schnell, denn die ganze TM Datenbank ist im Cache. Während der Sicherung fliegt die Datenbank aber teilweise wieder aus dem Cache, weil auch die Sicherungsdatei kurzfristig darin gepuffert wird. Danach ist die Leistung von TM also erst einmal wieder mehr oder weniger reduziert.
Wie arbeitet man mit TMAdmin /cachepraxisdb am effizientesten
Ich sehe folgende Szenarien:
Ein 64-Bit Betriebssystem lohnt sich auf jeden Fall, sobald die beiden Praxisdatenbanken zusammen größer werden als - sagen wir einmal - ein bis eineinhalb Gigabyte. Ich basiere diese Schätzung auf der Tatsache, dass unter 32-Bit Windows maximal 3 GB RAM genutzt werden können (von zweifelhaften Tricks abgesehen). Windows und Programme (TM Datenbank, vielleicht ein Faxserver und das übliche, was man sonst noch so auf den Server packt) belegen so etwa ein Gigabyte. Bleiben zwei für den Cache. Die anderen Programme bekommen auch etwas vom Cache ab, bleiben also in 1.5 GB für die Praxisdaten übrig. Werden die Praxisdatenbanken größer, so ist die Gefahr unter 32-Bit Windows größer, dass die Daten schneller aus dem Cache fliegen. Mit 64-Bit Windows kann man - je nach Rechner - problemlos 8 und mehr Gigabyte RAM ins System packen. Das kostet heute nicht mehr die Welt, kann aber eben unter 32-Bit Windows nicht genutzt werden.
Nebenbei: Multiprozessor-CPUs
Ich habe die Versuche mit Windows 2008 mit einem 4-Kern-Prozessor, 8 GB RAM und einer 4 GB Praxisdatenbank gemacht. Bei einer komplexen "erweiterten Suche" wurde nur ein Kern wirklich genutzt, ebenso bei der Kassenabrechnung. Und dabei lief am Testrechner auch noch das TurboMed selbst, also nicht nur der Datenbankserver! Ein Doppelkernprozessor sollte also meiner Ansicht nach als Datenbankserver völlig ausreichen, denn dann kommen sich die verschiedenen parallel laufenden Programme (Datenbank, Fax, Windows, usw.) nicht so oft in die Quere. Ein Ein-Kern-Prozessor dürfte aber auch nicht wirklich benachteiligt sein, viel Arbeitsspeicher ist da meiner Ansicht nach wesentlich wertvoller. Wenn man jedoch den Server als Terminalserver betreibt, dann kann man wohl nie genug Kerne haben, denn dann arbeiten ja etliche TM-Instanzen nebeneinander auf dem gleichen Rechner, meist noch Word etc. dazu!
Viele Grüße und schöne Pfingsten noch,
Thomas
ich habe einmal intensiv das Verhalten des FastObjects Datenbankservers von TM in Verbindung mit dem /cachepraxisdb untersucht, speziell im Hinblick auf Nebenwirkungen oder Unverträglichkeiten, auch besonders bei knappem Arbeitsspeicher bzw. sehr großen Praxisdatenbanken. Bei dieser Gelegenheit habe ich auch die Funktion von TM unter 64-Bit Windows angetestet (unter Windows 2008 Server). Das folgende beschreibe ich ausschließlich im Hinblick auf den Einsatz von TM am Server und gehe dabei auf 32-Bit Betriebssysteme (getestet mit Windows XP) und 64-Bit Betriebssystemen (wie gesagt, Windows 2008 Server) ein. Die Optimierung von TM als Client ist eine andere Sache und nicht Bestandteil dieses Aufsatzes.
Grundsätzliches
TM wie auch der FastObjects-Datenbankserver sind 32-Bit Anwendungen, d.h. sie bekommen von Windows üblicherweise nur maximal 2 GB als Programm-Speicher zugewiesen. (Man kann das mit Windows-Tuning-Parametern auf 3 GB erhöhen, ob das sinnvoll ist, bezweifle ich aus Gründen der Stabilität erst einmal. Für diesen Aufsatz, und auch in der Praxis, lasse ich es also.)
Unter einem 64-Bit Windows lief TurboMed offenbar einwandfrei, allerdings arbeitete ich nur an einem Testsystem (Windows 2008 Server) und habe deshalb nicht intensiv alle Funktionen ausprobiert, wie man es an einem Produktivrechner wohl tun würde. Es hat jedoch ohne sichtbare Probleme "gezuckt". Allerdings konnte der Datenbankserver das bekannte F-Symbol nicht im System-Tray anzeigen, wenn er als Dienst eingerichtet war. Das lag vermutlich an der geänderten Arbeitsweise der Konsolen unter Windows 2008 Server. War jedoch nur kosmetisch - der Dienst lief dennoch.
Caching unter Windows
Das folgende ist vereinfacht dargestellt. Die reale Arbeitsweise ist naturgemäß recht komplex und in vielen, seeehr vielen technischen Dokumenten dargestellt. Ich habe vieles davon gelesen und fasse es natürlich nur knapp zusammen. Bitte also keine Aufschreie, wenn das eine oder andere stark komprimiert wurde - für den Einsatz unter TM (am Server) unterschlage ich jedoch nichts essentielles.
Windows nutzt den Arbeitsspeicher, der nicht den Programmen zugewiesen wurde, als Datei-Cache und nennt diesen System Cache. (Wichtig, diesen Begriff gut merken!) Dabei legt es Dateiteile, die von der Festplatte abgerufen wurden, im Speicher ab. Fragt ein Programm dann diesen Dateiteil erneut ab, so bedient Windows die Anfrage aus dem System Cache, also direkt aus RAM, und muss nicht auf die Festplatte zugreifen. Dadurch entstehen massive Geschwindigkeitsvorteile. (Ab hier verwende ich vereinfacht Cache für den System Cache.)
Windows nutzt dabei natürlich viele clevere Mechanismen, um den Cache effizient zu nutzen. Ein paar einfache Grundregeln sind jedoch:
- Alterung: Wenn nicht mehr genügend Arbeitsspeicher frei ist, um den Cache zu vergrößern, dann wirf die ältesten Daten raus um Platz für die neuesten Daten zu machen.
Daten, die erneut angefragt und aus dem Cache bedient werden konnten, werden wieder als "neu" markiert und rutschen dann wieder an eine bessere Stelle in der Alterungsliste.
Nutze soviel Speicher wie möglich für den Cache! Unter einem 64-Bit Windows kann das praktisch der gesamte physikalische Speicher sein, also etliche Gigabyte. Unter 32-Bit Windows ist das naturgemäß eingeschränkt, meist maximal 2 GB. (Man sollte jedoch – wie unten beschrieben – das System für die Cache-Nutzung in den Systemeigenschaften konfigurieren.)
Nutze den Cache nur zum Lesen - Schreibzugriffe werden immer direkt zur Platte durchgereicht! (Das kann man beeinflussen, ist aber kritisch, denn bei einem Stromausfall kann die Datenbank beschädigt werden und Daten verlieren.) Was aber einmal auf die Platte geschrieben wurde, landet auch gleich im Cache - werden die Daten dann erneut gelesen, braucht man wieder keinen Festplattenzugriff.
Der Cache ist für alle laufenden Programme da und nicht für ein spezielles reserviert. Hier gilt Gleichberechtigung!
Aus dem ganzen ergibt sich folgende Kette von logischen Konsequenzen:
- Damit TurboMed also schnell laufen kann, soll es möglichst wenig auf die sehr langsame Festplatte zugreifen müssen
Also soll möglichst die ganze Datenbank im Cache sein und dort auch möglichst immer bleiben(!)
Da andere Programme auch den Cache nutzen (bzw. Windows den Cache auch für die Dateizugriffe der anderen Programme nutzt) sollte man genug Arbeitsspeicher als Cache für alle Datenzugriffe aller Programme haben - im Idealfall also soviel Arbeitsspeicher wie Festplattenspeicher.
Da man das wohl nie bekommen wird
sollte man
a) so viel Arbeitsspeicher wie möglich als Cache im System haben und
b) so wenig wie möglich andere Programme laufen lassen, die sich mit dem TM-Datenbankserver den Cache teilen müssen
Das habe ich nicht en detail evaluiert, gehe aber von folgender Arbeitsweise aus, wie sie bei Datenbankservern allgemein praktiziert wird: Einige Systemrelevante Daten (z.B. Indexdaten, manchmal auch Benutzerdaten, also echter Dateninhalt) werden zunächst im Arbeitsspeicher gehalten, bevor sie auf die Platte geschrieben werden. Das spart Zeit, weil das Schreiben einige Sekunden später gemacht werden kann, wenn der Rechner wieder nichts mehr zu tun hat. Wenn man jedoch die Datenbanken sichern möchte, sollten doch schon alle relevanten Daten in der physikalischen Datei sein, sonst sichert man nur halbe Sachen. Außerdem sollte die Datenbank ruhiggestellt sein, es sollte also nicht darin geschrieben werden. Mit dem Starten des Backup-Modes wird FastObjects mitgeteilt, dass er bitteschön einmal alles wegschreiben soll, was noch nicht geschrieben wurde. Bis zum Ende des Backup-Modes schreibt er dann in sogenannte Logdateien, die sich bei TM im Verzeichnis PraxisDB\recovery befinden. Gelesen wird nach wie vor direkt aus den Dateien objects.dat und objects.idx. Beim Ende des Backup-Modes werden dann alle Schreibvorgänge, die der Datenbankserver sich in den Logdateien "gemerkt" hat, in die Datenbank integriert. Während der Sicherung sind die Datenbanken also schön konsistent und weil alle Programme (Sicherungsprogramm und der Datenbankserver) nur lesend darauf zugreifen, gibt es auch keine Konflikte.
(Im Folgenden spreche ich nur noch von Datenbank und meine dabei natürlich die beiden Dateien objects.dat und objects.idx, die zusammen die TM-Praxisdatenbank ausmachen.)
Was genau macht denn nun TMAdmin /cachepraxisdb?
Verblüffend wenig: TMAdmin bringt den Datenbankserver kurz in den Backup-Modus, liest dann einfach einmal die kompletten Datenbankdateien von vorne bis hinten durch und beendet den Back-Modus wieder. Das ist ein ebenso simpler wie cleverer Ansatz, das System zu beschleunigen. Denn dadurch wird Windows gezwungen, sich einmal mit dem kompletten Inhalt der beiden Dateien zu beschäftigen, was zur Folge hat, dass die Daten komplett in den System-Cache wandern. Das kann man gut beobachten: Starten Sie den Task-Manager und gehen Sie auf den Reiter Systemleistung (XP und Windows 2003 Server) bzw. Leistung (Windows 2008 und Vista). Dort finden Sie im Block "Physikalischer Speicher" den Wert "Systemcache" (XP und Windows 2003) bzw. "Im Cache" (Windows 2008 und Vista). Bei einem frisch gestarteten System ohne nennenswerte laufende Programme (also auf dem Server idealerweise nur Windows und der FastObjects Datenbankserver) ist dieser Wert recht niedrig. Rufen Sie nun TMAdmin /cachepraxisdb auf und beobachten Sie, wie der Wert schnell ansteigt. Am Ende ist er recht genau um die Summe der Größen der beiden Datenbankdateien objects.dat und objects.idx angewachsen - Windows hat nun beide Daten - die komplette Praxisdatenbank - im Arbeitsspeicher.
Probieren Sie dann doch einmal folgendes: Starten Sie TMAdmin /cachepraxisdb einfach gleich noch einmal. Das wird dann sehr viel schneller gehen, als beim ersten Durchlauf, denn Windows hat die Datenbank ja schon im Speicher und bedient TMAdmin's einfaches Durchlesen der Daten direkt aus dem Cache! (Wenn es nicht wirklich schneller ist, dann ist Ihre Datenbank entweder sehr klein, oder Sie haben nicht genügend Arbeitsspeicher für den Cache.)
Dieser Ansatz ist deshalb so clever, weil sich der Datenbankserver selbst nicht um das Cachen im großen Stil kümmern muss. Das könnte er als 32-Bit Applikation auch gar nicht, denn selbst unter einem 64-Bit Windows bekommt er nur bzw. kann er nur mit 2 GB Speicher umgehen! Wenn die Praxisdatenbank größer als 2 GB ist (objects.dat und objects.idx zusammengerechnet) käme FastObjects nicht weiter und könnte nicht alle Daten cachen. Windows hat diese Limitierung nicht und kann den ganzen verfügbaren Arbeitsspeicher effizient nutzen.
Risiken von /cachepraxisdb
Risiken und Nebenwirkungen hat das meiner Ansicht nach gar keine! Gehen wir einmal davon aus, dass Windows den Cache gut im Griff hat (das ist schließlich eine der Hauptaufgaben des Betriebssystems), dann passiert hier nichts Außergewöhnliches. Es kann damit auch keine negativen Auswirkungen auf Hausbesuchsmodule, Datensicherungen, usw. geben, denn es wird kein Programm angewiesen, irgendetwas anders als sonst zu machen! Auch hat prinzipiell der verfügbare Arbeitsspeicher keine Auswirkungen auf TMAdmin /cachepraxisdb. Man kann das selbst dann durchführen, wenn die PraxisDB 10 GB groß ist, der Rechner aber nur 1 GB Arbeitsspeicher hat. Natürlich bringt das auch keine Vorteile, denn Windows schiebt die ersten Gigabyte der Datenbank, die es gerade in den Cache gepackt hat, beim Lesen der nächsten Gigabyte Daten direkt wieder raus. Und es dürfte Glückssache sein wenn der Patient, den ich gerade aufrufen will, just eben in dem knappen Cache ist und nicht von der Festplatte nachgelesen werden muss. Aber es schadet auch nicht!
Nachteile dieses Ansatzes
Nachteile bestehen dahingehend, als dass der Datenbankserver keinen direkten Einfluss auf den Cache hat. (Er könnte technisch zwar Eingriff nehmen und den Cache zu seinen Gunsten manipulieren. Es gibt Funktionen, mit denen Applikationen den Cache von Windows beeinflussen können, aber diese werden - meiner Recherche nach - nur von Windows Komponenten und Programmen wie Exchange und SQL Server genutzt. Ich finde, das ist auch so in Ordnung, denn wenn alle Programme sich selbst den Cache zuordnen wollen, wäre ein System wohl kaum mehr lauffähig. Ein Moderator (Windows), der sich um den Cache alleine kümmert, ist sicherlich sinnvoll und nötig.)
Wenn also der Datenbankserver den Cache lange nicht nutzt (TM tut nichts und langweilt sich), ein anderes Programm aber intensiv von der Festplatte liest (ich schaue mir z.B. ein Video an oder spiele Musik ab), dann wird der Cache langsam alle TM-Daten altern lassen und letztlich zugunsten der neuen Daten (hier im Beispiel die Videos und Musik) aus dem Cache werfen. Beim nächsten Zugriff auf die TM-Daten müssen sie wieder frisch von der Festplatte gelesen werden und sind erst ab diesem Zeitpunkt wieder im Cache.
Meine eigene Frage in dem anderen Thread "wie lange hält /cachepraxisdb" beantwortet sich deshalb so: Es hält so lange, wie die Daten von Windows im System Cache gehalten werden - entweder, weil schlichtweg genug RAM für das Cachen aller Plattenzugriffe da ist, oder weil kein anderes Programm läuft, das die Festplatte und damit den Cache auch intensiv nutzt und die TM-Daten wegen Alterung irgendwann aus dem Cache fliegen.
Was ist mit der Datensicherung?
Eine Datensicherung beeinflusst den Systemcache damit theoretisch eigentlich nicht, denn es wird streng genommen auch nur die Datenbank komplett gelesen - wenn sie vorher im Cache war, wird sie dadurch ja nicht aus dem Cache geworfen. Aber: Bei einer Datensicherung wird auch die Sicherungsdatei geschrieben, und die ist bei großen Praxisdatenbanken auch recht groß (kleiner zwar, wegen Komprimierung, aber immer noch beachtlich). Wenn der Arbeitsspeicher, bzw. genauer der für den Cache nutzbare Teil, nun gerade groß genug war, um die Praxisdatenbank zu cachen, passiert folgendes: Direkt nach dem Aufruf von TMAdmin /cachepraxisdb ist das System schnell, denn die ganze TM Datenbank ist im Cache. Während der Sicherung fliegt die Datenbank aber teilweise wieder aus dem Cache, weil auch die Sicherungsdatei kurzfristig darin gepuffert wird. Danach ist die Leistung von TM also erst einmal wieder mehr oder weniger reduziert.
Wie arbeitet man mit TMAdmin /cachepraxisdb am effizientesten
Ich sehe folgende Szenarien:
- a) Rechner mit sehr knappen Arbeitsspeicher - kleiner als die Praxisdatenbanken. Hier bringt /cachepraxisdb nichts. Schadet nichts, aber bringt auch nichts.
b) Rechner mit knappen Arbeitsspeicher - so groß, dass die Praxisdatenbanken in den Cache passen, aber eben nicht viel mehr. Hier besteht die Gefahr, dass die Daten irgendwann aus dem Cache herausdiffundieren. Man sollte auf solchen Rechnern möglichst wenige Programme neben dem TurboMed Datenbankserver betreiben. Ich sehe es auch als sinnvoll an, TMAdmin /cachepraxisdb immer wieder mal neu zu starten, z.B. automatisch zeitgesteuert morgens, vor Praxisbeginn und Mittags, in der Pause.
c) Rechner mit viel Arbeitsspeicher - wesentlich mehr als die Größe der Praxisdatenbanken. Schön, nur sollte hier /cachepraxisdb eigentlich gar nicht nötig sein, weil irgendwann alle Daten einmal angefasst wurden und dann automatisch im Cache landen. Da der groß genug für alle Programme ist, fliegen die Daten auch nicht wieder raus. Theoretisch.... Ich würde aber dennoch den gleichen Ansatz wie unter b) machen, d.h. TMAdmin /cachepraxisdb immer wieder mal aufrufen, damit die Daten ja auch wirklich im Cache sind. Waren sie es ohnehin schon, dann läuft der Befehl ruckzuck durch - waren sie es nicht, sind es danach eben auf jeden Fall!
Ein 64-Bit Betriebssystem lohnt sich auf jeden Fall, sobald die beiden Praxisdatenbanken zusammen größer werden als - sagen wir einmal - ein bis eineinhalb Gigabyte. Ich basiere diese Schätzung auf der Tatsache, dass unter 32-Bit Windows maximal 3 GB RAM genutzt werden können (von zweifelhaften Tricks abgesehen). Windows und Programme (TM Datenbank, vielleicht ein Faxserver und das übliche, was man sonst noch so auf den Server packt) belegen so etwa ein Gigabyte. Bleiben zwei für den Cache. Die anderen Programme bekommen auch etwas vom Cache ab, bleiben also in 1.5 GB für die Praxisdaten übrig. Werden die Praxisdatenbanken größer, so ist die Gefahr unter 32-Bit Windows größer, dass die Daten schneller aus dem Cache fliegen. Mit 64-Bit Windows kann man - je nach Rechner - problemlos 8 und mehr Gigabyte RAM ins System packen. Das kostet heute nicht mehr die Welt, kann aber eben unter 32-Bit Windows nicht genutzt werden.
Nebenbei: Multiprozessor-CPUs
Ich habe die Versuche mit Windows 2008 mit einem 4-Kern-Prozessor, 8 GB RAM und einer 4 GB Praxisdatenbank gemacht. Bei einer komplexen "erweiterten Suche" wurde nur ein Kern wirklich genutzt, ebenso bei der Kassenabrechnung. Und dabei lief am Testrechner auch noch das TurboMed selbst, also nicht nur der Datenbankserver! Ein Doppelkernprozessor sollte also meiner Ansicht nach als Datenbankserver völlig ausreichen, denn dann kommen sich die verschiedenen parallel laufenden Programme (Datenbank, Fax, Windows, usw.) nicht so oft in die Quere. Ein Ein-Kern-Prozessor dürfte aber auch nicht wirklich benachteiligt sein, viel Arbeitsspeicher ist da meiner Ansicht nach wesentlich wertvoller. Wenn man jedoch den Server als Terminalserver betreibt, dann kann man wohl nie genug Kerne haben, denn dann arbeiten ja etliche TM-Instanzen nebeneinander auf dem gleichen Rechner, meist noch Word etc. dazu!
Viele Grüße und schöne Pfingsten noch,
Thomas
Also lasst es!
