Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- nosql:log_file_verhalten_oracle_nosql_db_11gr2 [2013/10/08 14:23] – [Die Datendateien / Transaktionslogs analysieren] gpipperr
+++ nosql:log_file_verhalten_oracle_nosql_db_11gr2 [2014/06/21 19:21] (aktuell) – 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>
+==== 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
+Nachfragen im Forum
+  * https://forums.oracle.com/thread/2583684