Lösen Sie schnell das Problem des langsamen Tomcat-Starts, super einfach

Heute habe ich einem Klassenkameraden geholfen, ein Problem zu lösen – Tomcat startete sehr langsam, etwa fünf oder sechs Minuten. Sobald das Problem behoben ist, dauert das Hochfahren nur 3 Sekunden.

Wie kann das Problem gelöst werden?

Suchen Sie catalina.sh im Bin-Verzeichnis von Tomcat, öffnen Sie es und fügen Sie an der folgenden Stelle eine Codezeile hinzu:

-Djava.security.egd=Datei:/dev/urandom

Nachtrag vom 12.02.2019: Viele Freunde möchten das Prinzip wissen, deshalb erkläre ich es kurz.

Tomcat 7 und Tomcat 8 rufen beim Start org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom auf, um eine Zeichenfolge sicherer Zufallszahlen zu generieren.

In der Linux-Umgebung (CentOS) können Zufallszahlen aus zwei speziellen Dateien generiert werden, eine ist /dev/urandom und die andere ist /dev/random.

Das Prinzip der Zufallszahlengenerierung besteht darin, den Entropiepool des aktuellen Systems zu nutzen, um eine feste Anzahl von Zufallsbits zu berechnen und diese Bits dann als Bytestrom zurückzugeben. Der Entropiepool ist das Umgebungsrauschen des aktuellen Systems. Entropie bezieht sich auf den Grad des Chaos in einem System. Systemrauschen kann anhand vieler Parameter bewertet werden, wie z. B. Speichernutzung, Dateinutzung, Anzahl unterschiedlicher Prozesstypen usw.

/dev/random blockiert das Programm, wenn es keine neuen Zufallszahlen generieren kann, und kehrt nicht zurück, bis entsprechend dem Entropiepool neue Zufallsbytes generiert wurden. /dev/urandom tut dies nicht (ublock) und natürlich sind die generierten Zufallszahlen nicht sehr gut.

Daher zwingen wir Tomcat, zum Generieren von Zufallszahlen /dev/urandom anstelle von /dev/random zu verwenden. Dadurch verbessert sich die Geschwindigkeit erheblich – von mehreren Minuten auf nur wenige Sekunden.

Zusätzliches Wissen: Lösung für den Tomcat-Start ist sehr langsam und es gibt keine Fehler im Protokoll

1. Problem

Als ich das Projekt einmal in der Alibaba Cloud bereitgestellt habe, gab es kein Problem mit dem Projekt. Als ich jedoch Tomcat startete, dauerte es einen halben Tag, bis ich reagierte und den Tomcat-Startvorgang abschloss.

Tomcat startet sehr langsam und es gibt keine Fehler im Protokoll. Die folgenden Informationen finden sich im Protokoll:

Log4j:[2015-10-29 15:47:11] INFO ReadProperty:172 - Eigenschaftendatei wird aus der Klassenpfadressource [resources/jdbc.properties] geladen

Log4j:[2015-10-29 15:47:11] INFO ReadProperty:172 - Eigenschaftendatei wird aus der Klassenpfadressource [resources/common.properties] geladen

29.10.2015 15:52:53.587 INFO [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Erstellung einer SecureRandom-Instanz für sessionIdGeneratorBase.createSecureRandom

2. Gründe

Tomcat 7/8 verwenden beide die Klasse org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom, um eine Instanz der sicheren Zufallsklasse SecureRandom als Sitzungs-ID zu generieren, was 342 Sekunden oder fast 6 Minuten dauert. Der SHA1PRNG-Algorithmus ist ein auf dem SHA-1-Algorithmus basierender Pseudozufallszahlengenerator mit starker Vertraulichkeit. In SHA1PRNG gibt es einen Seed-Generator, der je nach Konfiguration verschiedene Operationen ausführt.

1) Wenn die Eigenschaft java.security.egd oder die Eigenschaft securerandom.source „file:/dev/random“ oder „file:/dev/urandom“ angibt, verwendet die JVM den nativen Seed-Generator NativeSeedGenerator, der die Methode super() aufruft, d. h. die Methode SeedGenerator.URLSeedGenerator(/dev/random) zur Initialisierung.

2) Wenn die Eigenschaft java.security.egd oder die Eigenschaft securerandom.source eine andere vorhandene URL angibt, wird zur Initialisierung die Methode SeedGenerator.URLSeedGenerator(url) aufgerufen.

Aus diesem Grund funktioniert es, den Wert auf „file:///dev/urandom“ oder „file:/./dev/random“ festzulegen.

In dieser Implementierung wertet der Generator die Menge an Rauschen im Entropiepool aus. Zufallszahlen werden aus einem Entropiepool erstellt. Beim Lesen gibt das Gerät /dev/random einfach zufällige Bytes aus dem Rauschen im Entropiepool zurück. /dev/random eignet sich gut für Szenarien, die eine sehr hohe Zufälligkeitsqualität erfordern, wie etwa einmalige Zahlungen oder Schlüsselgenerierung.

Wenn der Entropiepool leer ist, werden Lesevorgänge von /dev/random blockiert, bis der Entropiepool genügend Umgebungsgeräuschdaten gesammelt hat. Der Zweck besteht darin, einen kryptografisch sicheren Pseudozufallszahlengenerator zu schaffen und der Entropiepool sollte eine möglichst große Ausgabe haben. Dies ist wichtig für die Generierung hochwertiger Verschlüsselungsschlüssel oder für Szenarien, die einen langfristigen Schutz erfordern.

3. Lösung

Es gibt zwei Lösungen:

1) Gelöst in TOMCAT-Umgebung

Sie können eine nicht blockierende Entropiequelle verwenden, indem Sie die JRE konfigurieren.

Fügen Sie diese Zeile zu catalina.sh hinzu:

-Djava.security.egd=Datei:/dev/./urandom

Das ist es.

Nach dem Hinzufügen verringerte sich die gesamte Startzeit beim Starten von Tomcat auf 2912 ms für den Serverstart.

2) In JVM-Umgebung lösen

Öffnen Sie die Datei $JAVA_PATH/jre/lib/security/java.security.

Sie können im vi-Befehl danach suchen:

?sichererZufallswert.Quelle

Finden Sie die folgenden Inhalte:

securerandom.source=Datei:/dev/random

Ersetzen Sie es dann durch:

securerandom.source=Datei:/dev/./urandom

Der obige Artikel handelt davon, wie man das Problem des langsamen Tomcat-Starts schnell lösen kann. Er ist super einfach und das ist alles, was der Herausgeber mit Ihnen geteilt hat. Ich hoffe, er kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden.