Mrz 192014
 

Seit geraumer Zeit entwickele ich mit meinem Kollegen Dominik Pieper an einem JEE-Generator, mit dem es auf einfache Art und Weise möglich ist, eine CRUD-Webanwendung zu generieren. In einem kleinen Einführungsvideo stelle ich einen kleinen Einstieg in den Generator dar.

Der generierte Code ist eine JEE6-Applikation basierend auf JSF 2.0 und EJB 3.1. Alle Masken können vollständig generiert werden. Zusätzlich kann eigener Code zusätzlich hinzugefügt werden. Somit wird eine maximale Flexibilität gewährleistet. Weitere Features sind:

  • Rollenbaseierte Sicherheit mit JAAS
  • Lokalisierung
  • Vollständige Eclipse-Integration
  • Deployment in JBoss 7 und Glassfish 3
  • u.v.a

Anzeige:


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.