Access-Speicher überwachen mit VMMap

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Trotz eigentlich ausreichenden Arbeitsspeichers und sonstiger Systemressourcen kann es vorkommen, dass Access in die Knie geht. Das macht sich durch verschiedene Fehlermeldungen bemerkbar. Aber wo liegen eigentlich die Grenzen von Access in der 32-Bit- und der 64-Bit-Version und wie findet man heraus, wie viele Formulare oder Recordsets Access vertragen kann? Das schauen wir uns in diesem Beitrag einmal genauer an. Dabei nutzen wir ein Tool namens VMMap von Microsoft, mit dem wir uns den Speicherbedarf von Anwendungen wie Access genau ansehen können.

Werkzeug für diesen Beitrag: VMMap

VMMap ist ein hilfreiches Tool, um den virtuellen Adressraum und den Speicherverbrauch von Prozessen zu visualisieren und zu analysieren. Die verschiedenen Werte, die wir in VMMap sehen, repräsentieren verschiedene Arten von Speicherbereichen und -ressourcen im virtuellen Adressraum eines Prozesses.

VMMap herunterladen

VMMap laden wir direkt beim Microsoft herunter. Eine zum Zeitpunkt der Erstellung dieses Beitrags gültige Downloadadresse lautet:

https://learn.microsoft.com/de-de/sysinternals/downloads/vmmap

Dies lädt das Programm vmmap.exe herunter.

VMMap starten

Starten wir die Datei vmmap.exe, erscheint der Dialog aus Bild 1. Hier wählen wir den Prozess aus, den wir hinsichtlich des Speicherbedarfs untersuchen wollen. In diesem Fall wählen wir den Eintrag MSACCESS.EXE aus.

Bild 1: Übersicht der Prozesse

Direkt im Anschluss wird es in dem nun geöffneten Fenster für diesen Prozess sehr bunt (siehe Bild 2). Hier sehen wir im oberen Bereich drei Balken, die folgende Bedeutung haben:

Bild 2: Daten eines Prozesses

• Committed: Der „Committed“ (zugesagte) Speicher bezieht sich auf den Teil des virtuellen Adressraums eines Prozesses, der tatsächlich für die Verwendung im physischen Speicher oder in der Auslagerungsdatei reserviert ist. Es stellt den Speicher dar, den der Prozess für seine Operationen nutzen kann. Ein zugesagter Speicher muss nicht sofort im physischen RAM vorhanden sein, sondern kann bei Bedarf in die Auslagerungsdatei verschoben werden.
• Private Bytes: „Private Bytes“ sind der Teil des „Committed“ Speichers, der nicht von anderen Prozessen oder Anwendungen geteilt wird. Dies ist der Speicher, der ausschließlich für den aktuellen Prozess reserviert ist. Private Bytes repräsentieren den Verbrauch von tatsächlichem physischem RAM und Auslagerungsdatei-Speicher durch den Prozess.
• Working Set: Das „Working Set“ ist der tatsächliche physische Speicher (RAM), der derzeit von einem Prozess im Arbeitsspeicher gehalten wird. Es umfasst diejenigen Seiten im virtuellen Adressraum des Prozesses, die aktiv verwendet werden. Der Working Set-Wert ändert sich ständig, wenn der Prozess Daten liest und schreibt.

Die Balken stellen die darunter abgebildeten Informationen in einer anderen Ansicht dar.

Hier ist eine Erklärung für die darunter liegenden Zeilen:

• Image: Dieser Bereich enthält den ausführbaren Code und die Daten des Prozesses. Es umfasst das Programm selbst sowie die DLLs und anderen Dateien, die vom Prozess verwendet werden.
• Heap: Ein Heap ist ein Speicherbereich, in dem dynamisch zugewiesene Speicherblöcke für Datenstrukturen wie Arrays und Listen verwaltet werden. Dieser Bereich wächst und schrumpft je nach Bedarf.
• Page Table: Die Seitenverwaltungstabelle ist eine interne Struktur, die das Betriebssystem verwendet, um den physischen Speicher mit den virtuellen Adressen zu verknüpfen. Dieser Bereich zeigt Informationen über die Seitenzuordnung.
• Private Data: Private Daten sind Bereiche im virtuellen Adressraum, die von diesem Prozess für seine eigenen Zwecke reserviert wurden. Sie sind für andere Prozesse nicht zugänglich.
• Shareable: „Shareable“-Bereiche sind solche, die zwischen verschiedenen Prozessen gemeinsam genutzt werden können, zum Beispiel durch Speicherzuweisungen über gemeinsam genutzte Bibliotheken oder Ressourcen.
• Mapped File: Dieser Bereich repräsentiert Dateien, die in den Speicher des Prozesses abgebildet (geladen) wurden. Diese Dateien können von anderen Prozessen oder dem Betriebssystem geändert werden.
• Stack: Der „Stack“ ist ein Bereich des Speichers, der für die Verwaltung von Funktionen und Variablen in einem Programm verwendet wird. Er wächst normalerweise von oben nach unten und enthält Informationen über Aufrufer und Parameter von Funktionen.
• Managed Heap: Dieser Bereich ist spezifisch für verwalteten Code, normalerweise im Kontext von .NET-Programmierung. Er enthält Objekte, die vom .NET-Heap verwaltet werden.
• Unusable: „Unusable“-Bereiche sind Speicherbereiche, die nicht verwendet oder zugewiesen werden können. Dies kann beispielsweise aufgrund von Sicherheitsmaßnahmen oder Betriebssystemeinschränkungen der Fall sein.
• Free: Dies sind Bereiche, die im virtuellen Adressraum als nicht zugewiesener oder freier Speicherplatz markiert sind und derzeit nicht verwendet werden.

Der Bereich darunter schlüsselt die verschiedenen Bereiche sehr detailliert auf – diesen Bereich wollen wir uns nicht genauer ansehen. Interessant sind die Werte Size in der Zeile Total und Free.

Speicherbedarf mit und ohne aktiviertem LAA-Modus

Da das Thema Access in der 32-Bit-Version und der 64-Bit-Version und LAA-Moduls nach wie vor aktuell ist, schauen wir uns als Erstes einmal den Speicherbedarf einer neuen, leeren Datenbank an.

Bei nicht aktiviertem LAA-Modus erhalten wir das Ergebnis aus Bild 3. Bei rund 0,9 Gigabyte Speicherbedarf ohne geöffnete Objekte verbleiben ca. 1,2 Gigabyte virtueller Speicher für Objekte.

[

Bild 3: Speicherbedarf von Access ohne aktivierten LAA-Modus

Bei aktiviertem LAA-Modus verbraucht Access an sich ungefähr genauso viel Speicher wie ohne LAA-Modus. Allerdings ist der verfügbare Speicher mit über 3,3 Gigabyte fast drei Mal so groß (siehe Bild 4).

Bild 4: Speicherbedarf von Access mit aktiviertem LAA-Modus

Den LAA-Modus haben wir mit dem Tool eingeschaltet, das wir im Beitrag Schneller, weiter, höher mit LAA für Access 32-Bit (www.access-im-unternehmen.de/1458) vorstellen.

Speicherbedarf im laufenden Betrieb prüfen

Wir experimentieren zunächst ein wenig mit Access ohne aktivierten LAA-Modus. Dazu erstellen wir ein Formular zum Steuern der Tests namens frmTests. Dieses erhält eine Schaltfläche namens cmdFormularOeffnen und ein Textfeld namens txtAnzahlFormular zur Anzeige der Anzahl der Formulare.

Im Klassenmodul des Formulars hinterlegen wir den folgenden Code. Die Variable col soll die Verweise auf die Formulare speichern:

Dim col As Collection

Diese füllen wir mit den Verweisen auf die nachfolgend erstellten Formulare. Dazu initialisieren wir die Variable col beim Laden des Formulars:

Private Sub Form_Load()
     Set col = New Collection
End Sub

Klicken wir auf die Schaltfläche cmdFormularOeffnen, lösen wir die folgende Prozedur aus. Diese initialisiert ein neues Objekt des Typs Form_frmLeer, also im Prinzip eine Instanz des Formulars, und referenziert diese mit der Variablen frm. Warum öffnen wir das Formular nicht einfach mit DoCmd.OpenForm? Weil wir dann nur eine Instanz erstellen können.

Nach dem Initialisieren blenden wir das Formular mit frm.Visible = True ein. Außerdem fügen wir die Objektvariable der Collection col hinzu, damit das Formular nach dem Beenden der Prozedur nicht zerstört wird.

Wir tragen die Anzahl der aktuell geöffneten Formulare in das Textfeld ein und verschieben das neu geöffnete Formular ein wenig nach unten und nach rechts, damit wir erkennen können, dass ein neues Formular angelegt wurde.

Schließlich verschieben wir noch den Fokus auf unser aufrufendes Formular, damit wir schnell hintereinander einige Formulare öffnen können:

Private Sub cmdFormularOeffnen_Click()
     Dim i As Integer
     Dim frm As Form
     Set frm = New Form_frmLeer
     frm.Visible = True
     col.Add frm
     Me!txtAnzahlFormulare = Forms.Count
     DoCmd.MoveSize Me!txtAnzahlFormulare * 30, _
         Me!txtAnzahlFormulare * 20
     Me.SetFocus
End Sub

Wenn wir einige Formulare geöffnet haben, erscheint schließlich die Fehlermeldung aus Bild 5. In unserem Fall können wir also gerade mal 64 völlig leere Formulare öffnen.

Bild 5: Meldung nach einigen geöffneten Formularen

Formulare mit Datenbindung

Schauen wir uns an, wie viele Recordsets mit einer mittelgroßen Tabelle wir öffnen können. Dazu fügen wir dem Formular eine weitere Collection hinzu, die wir beim Laden ebenfalls initialisieren:

Dim colRecordsets As Collection
Private Sub Form_Load()
     Set col = New Collection
     Set colRecordsets = New Collection
End Sub

Außerdem fügen wir ein weiteres Textfeld und eine weitere Schaltfläche analog zum vorherigen Beispiel hinzu.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo