Feb 092011
 

Linux bietet auf x86-Architekturen die Möglichkeit, statt der normalerweise 4K großen Memory Pages auch 2M große Pages zu nutzen. Der Vorteil hierbei ist, dass die MMU der CPU deutlich seltener ein Address Mapping von virtuellem Speicher auf die physikalische Adresse durchführen muss. Dieser Vorgang wird auch Table Walk genannt. Er hat den Nachteil, dass der Zugriff auf diese Mapping-Tabellen am Cache vorbei durchgeführt werden muss und somit sehr langsam ist. Das Ergebnis des Table Walks landet seinerseits in einem speziellem Cache, dem sog. TLB. Es bietet sich unter Linux an, Software mit hohem Speicherverbrauch diese Huge Pages oder Huge Tables nutzen zu lassen. Gerade Server-Prozesse wie JBoss fallen da schnell ins Auge.

Will man unter Java diese sog. Huge Pages verwenden, reicht da die JVM-Option -XX:+UseLargePages. Allerdings ist das nicht die gesamte Arbeit. Dazu muss man den Linux-Kernel anweisen, Huge Tables zur Verfügung zu stellen. Dazu muss man sich erst klar werden, dass Huge Tables dem allgemeinen Memory Pool entzogen wird und nicht mal dem Linux Caching mehr zur Verfügung steht. Es ist also Speicher, der dem Java-Prozess dediziert zur Verfügung steht. Es empfiehlt sich, 512M mehr als Huge Tables bereitzustellen, als man mit -Xmx der virtuellen Maschine zur Verfügung stellt. Hat man 8G RAM, und will man 3,5G dem Java bereit stellen. Müssen wir 4G an Huge Tables bereitstellen. Das geschieht in der Datei /etc/sysctl.d/hugetlb.conf. Dort müssen drei Einträge gemacht werden:

  1. kernel.shmmax=<max-shared-memory-in-bytes>
    Da Huge Tables als Shared Memory allokiert werden, muss die Maximalzahl hier auf die verwendete Speichergröße hochgesetzt werden.
  2. vm.nr_hugepages=<amount>
    Die Zahl der Huge Tables selbst. Will man 4G an Huge Tables haben, muss hier eine 2048 eingetragen werden, weil 2048 * 2M = 4G ist.
  3. vm.hugetlb_shm_group=<gid>
    Hier muss die Usergroup eingetragen werden, die Huge Tables benutzen darf.

Sind die Werte eingetragen, muss man ein sysctl -p -f /etc/sysctl.d/hugetlb.conf ausführen, um die Werte dem Kernel mitzuteilen. Hat der Server schon eine relativ lange Uptime, muss er vielleicht durchgestartet werden. Grund ist, dass die Huge Tables im Stück im Speicher liegen müssen. Da es auch beim Hauptspeicher eine Fragmentierung geben kann, kann evtl. die Zuteilung der Huge Tables nur teilweise gelingen. Kontrollieren kann man das, indem man cat /proc/meminfo ausführt. Das ergibt dann so eine Ausgabe wie:

HugePages_Total:     512
HugePages_Free:      512
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       47040 kB
DirectMap2M:     4147200 kB

Hier sind 512 (= 1G) Huge Tables zugewiesen worden. Als Nächstes muss dem entsprechenden Benutzer, der die Huge Tables benutzen möchte, die Erlaubnis geben, diesen Speicher fest im Speicher zu halten, so dass er nicht im Swap landen kann. Das erfolgt in der Datei /etc/security/limits.conf. Hier wird die Größe des Wertes kernel.shmmax aus der Datei /etc/sysctl.d/hugetlb.conf übernommen. Die Einträge lauten:

<username> soft memlock <locked-memory-in-kbytes>
<username> hard memlock <locked-memory-in-kbytes>

Benutzt man für den Usernamen „*“, gilt diese Einstellung für alle Benutzer, ausgenommen root. Für ihn muss man explizit einen Eintrag machen, wenn gewünscht. Üblicherweise läuft JBoss nicht als root, sondern hat einen dedizierten Benutzer, den man dann auch hier eintragen sollte. Hierbei muss man darauf achten, das PAM so konfiguriert ist, dass die Limits auch als Benutzer entsprechend konfiguriert werden. Hat man als Shell die bash, kann man mit ulimit -a überprüfen, ob der Wert max locked memory korrekt gesetzt wurde. Ein Reboot ist hierfür nicht erforderlich!

jboss@master:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 3145728
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65536
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Sind die Huge Tables verfügbar und die Limits gesetzt, kann man jede JVM mit der Option -XX:+UseLargePages starten und Java benutzt Huge Tables.

Kann Java keine Huge Tables allokieren, kommt es zu folgender Fehlermeldung:

Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 22).

In diesem Falle allokiert Java „normalen“ Speicher. Wenn zu viele Huge Tables belegt wurden, kann es dann zu einem Engpass an normalen Speicher kommen. Die Wahl der Option -Xmx ist daher wichtig!

Unter JBoss sollte diese Option in die Datei $JBOSS_HOME/bin/run.conf übernommen werden.

oAW-Tools jetzt Open Source

 Eclipse, MDSD, Software  Kommentare deaktiviert für oAW-Tools jetzt Open Source
Jul 092010
 

Die oAW-Tools sind ab sofort auf SourceForge als Open Source verfügbar. Die oAW-Tools beinhalten eine Reihe kleiner Komponenten und Beautifier. Die Startseite ist unter http://sourceforge.net/apps/trac/oaw/ erreichbar. Der Quellcode kann aus dem Subversion-Repository heruntergeladen werden. Ferner gibt es noch eine Update-Site, die direkt aus dem Eclipse benutzt werden kann.

Viel Spaß!


Jul 072010
 

Das Projekt der modell(-bau-)basierten Eisenbahnsteuerung ist ab sofort auf SourceForge als Open Source verfügbar. Die Startseite ist unter http://sourceforge.net/p/mrw/wiki/Home/ erreichbar. Der Quellcode und die Schaltungen können aus dem Subversion-Repository heruntergeladen werden.

Viel Spaß!


Anzeige:



Apr 012010
 

Seit der Veröffentlichung von EJB3.0 ist der Umgang mit Persistenz erheblich vereinfacht worden. Hintergrund ist die Verwendung sog. POJOs (Plain Old Java Object), die den Entwicklungsvorgang erheblich vereinfachen. Völlig in den Hintergrund ist dabei die Verwendung sog. POPOs (Plain Old Paper Object) geraten. Gerade diese Variante wurde schon von den alten Ägyptern eingesetzt. Es ist der Nachweis gelungen, dass die Persistenz über mehrere tausend Jahre erhalten bleibt. Den Beweis, die Persistenz über diesen Zeitraum aufrecht erhalten zu können, müssen die POJOs noch erbringen, ist die damit einhergehende Technologie erst ein paar Jahrzehnte alt.

Ein POPO wird angelegt.

Bild 1: Ein POPO beim Anlegen. Dieses wird später offline gestellt, um gezielt einen Nachschub-Auftrag durchführen zu können.


Anzeige:




POPOs stehen in ihrer Funktionalität den POJOs in nichts nach, sind doch alle Patterns gemäß des CRUD-Paradigmas verwendbar. Selbst das redundante Schreiben und getrennte Aufbewahren ist damit möglich und somit auch das Lesen parallelisierbar. Auch Transaktionen mit Commit und Rollback stellen kein Problem dar. Einzig die Zugriffszeit ist mit POPOs ein Problem. Der größtenteils biomechanische Zugriff kann unter Umständen mehrere Minuten bis Stunden dauern. Gerade hier spielt die Parallelisierbarkeit mit enormen Zeitgewinn zu Lasten der Betriebskosten eine wesentliche Rolle. Typischerweise sind auch die räumlichen Erfordernisse größer als bei POJOs, wenngleich die klimatischen Bedürfnisse z.B. an Trockenheit und Lichteinflüsse vergleichbar sind.

Ein Storage für POPOs

Bild 2: Dieses Bild zeigt ein Storage für POPOs. Es ist deutlich erkennbar, dass Zugriffe hierauf parallel ablaufen können. Auch der größere Platzaufwand lässt sich hier unschwer erkennen.

Auch in heutiger Zeit sind POPOs nicht aus dem Alltagsleben wegzudenken. Es gibt sogar Varianten für den Embedded Bereich. Auch das Offline-Stellen für z.B. Nachschub-Aufträge lässt sich realisieren und sind sogar praktikabler, als POJO-Varianten. Insgesamt darf man gespannt sein,wie lange sich diese Technologie halten wird.

Ein POPO wird zum Löschen vorgemerkt.

Bild 3: Dieses POPO ist für das endgültige Löschen vorgemerkt. Dieser Vorgang kann durch ein Rollback wieder rückgängig gemacht werden.