Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- nosql:log_file_verhalten_oracle_nosql_db_11gr2 [2013/08/19 17:51] – gpipperr
+++ nosql:log_file_verhalten_oracle_nosql_db_11gr2 [2013/10/08 14:23] – [Die Datendateien / Transaktionslogs analysieren] gpipperr
@@ Zeile 1: / Zeile 1: @@
-===== Oracle NoSQL 2.1.18 - Datenwachstum und Datendatei/Transaktionslog Verhalten =====
-Bei ersten Lasttests fällt auf, das jede Operation (Einfügen, Updaten, Löschen) die scheinbare Größe des Stores auf der Platte stetig stark wachsen lässt.
-Die unter der NoSQL liegende Berkeley Java DB (Version 5.0.83 in der 2.2.18) trennt die klassischen Datendateien und Transaktionslogs einer Datenbank nicht voneinander, sondern persistiert alle Operationen eine nach der nacheinander in den gleichen Dateien.
-Ein Background Job, der Cleaner, der Berkeley Java DB bereinigt die Datenbank Dateien bei Bedarf im Hintergrund, aber erst immer  dann wenn diverse Randparameter erfüllt sind.
-Um die I/O Last des Systems möglichst niedrig zu halten, findet das Umkopieren/Reorganisieren dieser Datendateien sehr stark verzögert statt.  (siehe [[http://docs.oracle.com/cd/E17277_02/html/GettingStartedGuide/logfilesrevealed.html|Six Things Everyone Should Know about JE Log Files]] )
-In der Berkeley Java DB wird dieses Verhalten besonders über die folgenden Parameter gesteuert:
-{{ :nosql:nosql_cleaner_parameter.png?500 | NoSQL important cleaner parameters}}
-  * je.cleaner.threads
-    * Anzahl der Cleaner Threads
-  * je.cleaner.bytesInterval
-    * Starte den Cleaner nach x geschriebenen Bytes
-    * Falls 0 bei der Byte zahl die der Hälfte eines Logs entspricht
-  * je.cleaner.minAge
-    * Wieviele Dateien müssen älter sind als die neueste damit der Cleaner arbeitet
-  * je.cleaner.minUtilization
-    * Cleaner hält die "total disk space utilization percentage" oberhalb diese Wertes
-  * je.cleaner.minFileUtilization
-    * Cleaner bereinigt das Log soblad der Füllgrad unter diesen Wert fällt
-    * Einfügen von Daten per Batchlauf kann beobachtet werden, das die Logs nur ungefähr bis zu diesem Prozentsatz gefüllt werden
-  * je.log.fileMax
-    * Maximale Größe einer Log Datei
-  * je.log.bufferSize
-    * Minimale Größe einer Log Datei bei der Neuanlage
-Weitere wichtige Parameter sind:
-  * je.checkpointer.bytesInterval
-    * Starte den Checkpointer alle x Byte
-  * je.cleaner.expunge
-    * Falls "true" lösche "geleerte" Logfile, falls "false" benenne die Logs nur um
-  * je.log.fileCacheSize
-    * Größe des Filehandle Caches
-Solange nicht sicherstellt ist, das die Informationen nicht doch noch für ein Recovery benötigt werden, kann kein Cleaning Prozess auf dem Log statt finden! Diese Checkpoints werden vom Checkpoint Prozess gesetzt. daher ist es wichtig auch den "je.checkpointer.bytesInterval" Parameter zu berücksichtigen.
-Die Parameter im Detail finden Sie hier [[http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat
-/je/EnvironmentConfig.html|JE EnvironmentConfig]]
-Die aktuellen Einstellungen lassen sich ab der NoSQL Version 2.1.18 über die Datei „je.config.csv" überprüfen (liegt im env Verzeichniss parallen zu den Datendateien).
-Am einfachsten für die Auswertung die Datei nach Windows kopieren und in Excel als CSV Datei importieren, die Spalte "je.cleaner.minUtilization" suchen und den Wert auslesen (In meiner Umgebung 40).
-===Wie und vor allen wann wird das Ganze dann aber jetzt wieder kleiner?===
-Die Statistik für das Cleaner Verhalten kann über die "je.stat.csv" überprüft werden, diese Datei kopieren und zum Beispiel über Excel öffnen.
-Im ersten Test mit dem default Einstellung wird beim Erreichen von 1GB „jdb“ Datei Größe eine neue Datei angelegt. Im Test wurden Daten eingefügt und wieder gelöscht, die Datendateien wachen, der Cleaner Prozess scheint aber sehr spät erst zu reagieren.
-Werden allerdings die Parameter über eine je.properties recht "klein" konfiguriert, läßt sich der Cleaner Prozess gut beobachten.
-Es ist noch zu pürfen, ob nicht für kleine/mittlere NoSQL Umgebungen die Standard Parameter im Default viel zu hoch sind.
-===Wo aber lassen sich diese Wert in der NoSQL Umgebung anpassen?===
-In einer Standard Berkeley DB können die entsprechenden Parameter für den Cleaner Task über  die JE Parameter  gesetzt werden ( siehe [[http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/EnvironmentConfig.html| EnvironmentConfig.html]]).
-In der Dokumentation wird von **<environment home>/je.properties** gesprochen, ein Test hat ergeben, dass die Datei immer dann gefunden wird, wenn **je.properties** parallel zu den Datendateien des RN liegt ( zum Beispiel in kvroot/kvstore/sn1/rg1-rn1/env/ ). Soll ein ganzer Store anders konfiguriert werden muss natürlich in jeden RN die je.properties hinterlegt werden.
-Beispiel für eine je.properties mit sehr kleinen Werte um das Verhalten zu testen:
-<code java>
-je.cleaner.threads=2
-je.cleaner.bytesInterval=1048576
-je.cleaner.minAge=2
-je.cleaner.minUtilization=60
-je.cleaner.minFileUtilization=20
-je.log.fileMax=1024000
-je.log.bufferSize=10000
-je.checkpointer.bytesInterval=1048576
-je.cleaner.expunge=true
-je.log.fileCacheSize=1024
-</code>
-Im der Trace/Log Datei beim Starten des RN wird der angepasste Parameter dann auch dokumentiert, allerdings taucht der Wert nicht sofort in der Datei "je.config.csv" auf, hier stehen immer noch die global eingestellten Wert. Es dauert einige Zeit, bis die geänderten Werte dann auch hier aktualisert werden.
-Allerdings muss auf die I/O Last auf dem System stark geachtet werden, mit den obigen Einstellungen hat sich die DB auch nach längerer Zeit nicht mehr "beruhigt", der Cleaner wird mit diesen Einstellunge nicht so recht fertig.
-=== Konfiguration der Default Wert im Code ===
-Für die Default Werte siehe die Java Datei "kv-2.1.8\src\oracle\kv\impl\param\ParameterUtils.java"
-<code java>
-..
- EnvironmentConfig.CLEANER_THREADS             + "=2;"
- EnvironmentConfig.CLEANER_READ_SIZE           + "=1048576;" +
- EnvironmentConfig.LOG_FILE_MAX                + "=1073741824;" +
- EnvironmentConfig.CHECKPOINTER_BYTES_INTERVAL + "=200000000;" +
- EnvironmentConfig.CLEANER_LAZY_MIGRATION      + "=false;" +
- EnvironmentConfig.CLEANER_MIN_UTILIZATION     + "=40;" +
-..
-</code>
-===== Die Datendateien / Transaktionslogs analysieren =====
-Mit den Tools der Berkely Java DB in .\lib\je.jar können die Store Node Datenbanken ausgewertet werden.
-Damit diese Klassen verwendet werden können, müssen aber die KV Jar’s mit in den Klassenpfad aufgenommen werden.
-**Nicht für produktive Umgebungen! \\
-Seiteneffekte im laufenden Betrieb können nicht ausgeschlossen werden!**
-=== Die Log Einträge auswerten/ ausgeben ===
-Mit Hilfe der Original Berkeley DB Management Methoden kann auf das Transaktionslog zugegriffen werden:
-Statistik der Log's ausgeben:
-<code cmd>
-REM in das Sofware Verzeichnis wechseln:
-cd D:\entwicklung\kv-2.1.8
-java -jar .\lib\je.jar DbPrintLog -h D:\entwicklung\kv-2.1.8\kvroot\kvstore\sn1\rg1-rn1\env  -S
-REM Note that DbPrintLog -S gives the average record size under Log statistics, in the LN (leaf node) row, at the avg bytes column.
-</code>
-Alle Inhalte der Logs ohne den Schalter s
-<code cmd>
-java -classpath ".\lib\kvclient.jar;.\lib\kvstore.jar;.\lib\je.jar" com.sleepycat.je.util.DbVerifyLog -h  D:\entwicklung\kv-2.1.8\kvroot\kvstore\sn1\rg1-rn1\env
-</code>
-Tipp:In der MS Powershell nicht vergessen mit "" den Klassenpfad zu escapen!
-=== Datenbank Größe / Partitionen und Anzahl Datensätze pro Partition ausgeben===
-Füllgrad und Größe der Daten/Transaktionslog Dateien anzeigen mit **"com.sleepycat.je.util.DbSpace"**:
-<code java>
-java -classpath ".\lib\kvclient.jar;.\lib\kvstore.jar;.\lib\je.jar" com.sleepycat.je.util.DbSpace -h  D:\entwicklung\kv-2.1.8\kvroot\kvstore\sn1\rg1-rn1\env
-  File    Size (KB)  % Used
---------  ---------  ------
-00000001    1048575       1
-00000002     511706      13
- TOTALS     1560282       5
-(LN size correction factor: 0.9585644)
-</code>
-**LN** steht für Leaf Node.
-Datenbanken anzeigen lassen (Damit werden auch die Partitionen sichtbar!) mit **"com.sleepycat.je.util.DbDump"** :
-<code cmd>
-java -classpath ".\lib\kvclient.jar;.\lib\kvstore.jar;.\lib\je.jar" com.sleepycat.je.util.DbDump -h D:\entwicklung\kv-2.1.8\kvroot\kvstore\sn1\rg1-rn1\env -l
-</code>
-Anzahl der Einträge in den Partitionen anzeigen lassen mit **"com.sleepycat.je.rep.utilint.DbDumpGroup"**:
-<code cmd>
-java -classpath .\lib\kvclient.jar;.\lib\kvstore.jar;.\lib\je.jar com.sleepycat.je.rep.utilint.DbDumpGroup -h  D:\entwicklung\kv-2.1.8\kvroot\kvstore\sn1\rg1-rn1\env -dumpCount
-</code>
-Die Details der Partitionen anzeigen lassen **"com.sleepycat.je.util.DbVerify"**:
-<code cmd>
-java -classpath ".\lib\kvclient.jar;.\lib\kvstore.jar;.\lib\je.jar" com.sleepycat.je.util.DbVerify -h  D:\entwicklung\kv-2.1.8\kvroot\kvstore\sn1\rg1-rn1\env
-</code>
-=== DB Statistik mit DbFilterStats auslesen ===
-Mit Unterstützung der Klasse **“ DbFilterStats“** kann auch einfacher die Performance CSV Datei ausgewertet werden.
-Dazu wird angegeben welche Spalte(n) (Namen der Spalten durch Komma getrennt) ausgelesen werden soll.
-<code cmd>
-java -classpath .\lib\kvclient.jar;.\lib\kvstore.jar;.\lib\je.jar com.sleepycat.je.util.DbFilterStats -p Cleaning:cleanerBackLog,Cleaning:nCleanerDeletions  D:\entwicklung\kv-2.1.8\kvroot\kvstore\sn1\rg1-rn1\env\je.stat.csv
-</code>
-siehe [[http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/util/DbFilterStats.html|DbFilterStats]]
-=== Group Metadata ausgeben ===
-<code powershell>
-# Get the group metadata from each member of the group, directly off their persistent copy
-java -classpath ".\lib\kvclient.jar;.\lib\kvstore.jar;.\lib\je.jar" com.sleepycat.je.rep.utilint.DbDumpGroup -h  D:\entwicklung\kv-2.1.8\kvroot\kvstore\sn1\rg1-rn1\env
-</code>
-Von obiger Ausgabe den Host und Port eintrag in der Zeile Node: verwenden um direkt dem Node Cache abzufragen:
-<code powershell>
-# Get the group metadata from the current master in a running group
-java -classpath ".\lib\kvclient.jar;.\lib\kvstore.jar;.\lib\je.jar" com.sleepycat.je.rep.util.DbGroupAdmin -roupName rg1 -helperHosts jupiter:5006 -dumpGroup
-</code>
-==== Quellen ====
-  * http://www.oracle.com/technetwork/products/berkeleydb/learnmore/bdb-je-architecture-whitepaper-366830.pdf
-  * http://docs.oracle.com/cd/E17277_02/html/GettingStartedGuide/BerkeleyDB-JE-GSG.pdf
-  * http://docs.oracle.com/cd/E17277_02/html/GettingStartedGuide/logfilesrevealed.html
-  * http://docs.oracle.com/cd/E17277_02/html/GettingStartedGuide/backgroundthreads.html#cleaner
-  * http://docs.oracle.com/cd/E17277_02/html/GettingStartedGuide/administration.html#propertyfile
-  * http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/util/DbDump.html
-  * http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/EnvironmentConfig.html
-  * http://freenet.googlecode.com/svn/trunk/contrib/bdb/test/com/sleepycat/je/cleaner/CleanerTest.java
-  * https://blogs.oracle.com/charlesLamb/entry/berkeley_db_java_edition_clean