Weblogic es lento para empezar (11mins) bajo VM (VirtualBox y VMware)

Question

(SOLUCIONADO! Falsificando sistema aleatorio GENERADOR, ver más abajo)

una imagen de máquina virtual Soy la creación de mi dev/construcción equipo . Dentro de esa VM, se debe ejecutar un dominio Weblogic. Uso la distribución de servidor Ububtu, WLS 9.2MP3 + ALSB.

Todo funciona bien, bastante rápido, pero en el momento de inicio, el WLS se detiene dos veces durante un tiempo medible. Dos paradas en total ascienden a unos 10 minutos de retraso. Para las tareas en las que la implementación requiere el reinicio del servidor, es muy molesto. :-(

tiempo de sueño no es constante, a veces el servidor se inicia muy rápido, a veces más o menos, a veces 10 minutos o más.

interesante que si presiono Enter mientras se mira en el servidor detenido, se despierta mucho más rápido, a veces después de algunos segundos. WLST (Weblogic Jython shell) también se cuelga durante bastante tiempo cuando se ejecuta en VM. No reacciona a Enter.

Aquí deben haber algunos desarrolladores que ejecutan WLS con una VM. Me pregunto si otros tienen el mismo problema. ¿Alguien pudo resolverlo?

Aquí está la salida del servidor (sólo para un caso):

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) 
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode) 
Starting WLS with line: 
/shared2/beahome/jdk150_12/bin/java -client -Xmx256m -XX:MaxPermSize=128m -Xverify:none -da -Dplatform.home=/shared2/beahome/weblogic92 
-Dwls.home=/shared2/beahome/weblogic92/server -Dwli.home=/shared2/beahome/weblogic92/integration -Dweblogic.management.discover=true -Dwl 
w.iterativeDev= -Dwlw.testConsole= -Dwlw.logErrorsToConsole= -Dweblogic.ext.dirs=/shared2/beahome/patch_weblogic923/profiles/default/sysext_ 
manifest_classpath -Dweblogic.management.username=admin -Dweblogic.management.password=wlsadmin -Dweblogic.Name=LOGMGR-admin -Djava.security 
.policy=/shared2/beahome/weblogic92/server/lib/weblogic.policy weblogic.Server 
<1-Apr-2010 12:47:22 o'clock PM GMT-05:00> <Notice> <WebLogicServer> <BEA-000395> <Following extensions directory contents added to the end 
of the classpath: 
/shared2/beahome/weblogic92/platform/lib/p13n/p13n-schemas.jar:/shared2/beahome/weblogic92/platform/lib/p13n/p13n_common.jar:/shared2/beahom 
e/weblogic92/platform/lib/p13n/p13n_system.jar:/shared2/beahome/weblogic92/platform/lib/wlp/netuix_common.jar:/shared2/beahome/weblogic92/pl 
atform/lib/wlp/netuix_schemas.jar:/shared2/beahome/weblogic92/platform/lib/wlp/netuix_system.jar:/shared2/beahome/weblogic92/platform/lib/wl 
p/wsrp-common.jar> 
<1-Apr-2010 12:47:22 o'clock PM GMT-05:00> <Info> <WebLogicServer> <BEA-000377> <Starting WebLogic Server with Java HotSpot(TM) Client VM Ve 
rsion 1.5.0_12-b04 from Sun Microsystems Inc.> 
<1-Apr-2010 12:47:23 o'clock PM GMT-05:00> <Info> <Management> <BEA-141107> <Version: WebLogic Server 9.2 MP3 Mon Mar 10 08:28:41 EDT 2008 
1096261 > 
<1-Apr-2010 12:47:25 o'clock PM GMT-05:00> <Info> <WebLogicServer> <BEA-000215> <Loaded License : /shared2/beahome/license.bea> 
<1-Apr-2010 12:47:25 o'clock PM GMT-05:00> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STARTING> 
<1-Apr-2010 12:47:25 o'clock PM GMT-05:00> <Info> <WorkManager> <BEA-002900> <Initializing self-tuning thread pool> 
<1-Apr-2010 12:47:25 o'clock PM GMT-05:00> <Notice> <Log Management> <BEA-170019> <The server log file /shared2/wldomains/beaadmd/LOGMGR/ser 
vers/LOGMGR-admin/logs/LOGMGR-admin.log is opened. All server side log events will be written to this file.> 

Aquí tenemos el primer retraso, hasta 5 horas ...

<1-Apr-2010 12:53:21 o'clock PM GMT-05:00> <Notice> <Security> <BEA-090082> <Security initializing using security realm myrealm.> 
<1-Apr-2010 12:53:24 o'clock PM GMT-05:00> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STANDBY> 
<1-Apr-2010 12:53:24 o'clock PM GMT-05:00> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STARTING> 
<1-Apr-2010 12:53:25 o'clock PM GMT-05:00> <Notice> <Log Management> <BEA-170027> <The server initialized the domain log broadcaster success 
fully. Log messages will now be broadcasted to the domain log.> 
<1-Apr-2010 12:53:25 o'clock PM GMT-05:00> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to ADMIN> 
<1-Apr-2010 12:53:25 o'clock PM GMT-05:00> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RESUMING> 
<1-Apr-2010 12:53:28 o'clock PM GMT-05:00> <Notice> <Security> <BEA-090171> <Loading the identity certificate and private key stored under t 
he alias adminuialias from the jks keystore file /shared2/wldomains/beaadmd/LOGMGR/CustomIdentity.jks.> 

Y aquí está la segunda, de nuevo hasta 5 minutos.

<1-Apr-2010 12:58:56 o'clock PM GMT-05:00> <Notice> <Security> <BEA-090169> <Loading trusted certificates from the jks keystore file /shared 
2/wldomains/beaadmd/LOGMGR/CustomTrust.jks.> 
<1-Apr-2010 12:58:57 o'clock PM GMT-05:00> <Notice> <Server> <BEA-002613> <Channel "DefaultSecure" is now listening on 192.168.56.102:7002 f 
or protocols iiops, t3s, ldaps, https.> 
<1-Apr-2010 12:58:57 o'clock PM GMT-05:00> <Notice> <Server> <BEA-002613> <Channel "Default" is now listening on 192.168.56.102:8012 for pro 
tocols iiop, t3, ldap, http.> 
<1-Apr-2010 12:58:57 o'clock PM GMT-05:00> <Notice> <WebLogicServer> <BEA-000331> <Started WebLogic Admin Server "LOGMGR-admin" for domain " 
LOGMGR" running in Development Mode> 
<1-Apr-2010 12:58:57 o'clock PM GMT-05:00> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RUNNING> 
<1-Apr-2010 12:58:57 o'clock PM GMT-05:00> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode> 

ACTUALIZACIÓN

creo que tengo la pista: tiene que ser la inicialización de semillas randon. Eso puede explicar por qué la generación de eventos de teclado libera el servidor. He hecho el vertedero de hilo, un hilo y está en estado ejecutable, pero esperando:

"[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=1 tid=0x0a7b06e8 nid=0xeda runnable [0x728a500 
0..0x728a6d80] 
     at java.io.FileInputStream.readBytes(Native Method) 
     at java.io.FileInputStream.read(FileInputStream.java:194) 
     at sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:185) 
     at sun.security.provider.NativePRNG$RandomIO.implGenerateSeed(NativePRNG.java:202) 
     - locked <0x7d928c78> (a java.lang.Object) 
     at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:108) 
     at sun.security.provider.NativePRNG.engineGenerateSeed(NativePRNG.java:102) 
     at java.security.SecureRandom.generateSeed(SecureRandom.java:475) 
     at weblogic.security.AbstractRandomData.ensureInittedAndSeeded(AbstractRandomData.java:83) 

Answer 1

resuelto

Weblogic utiliza SecureRandom a init subsistema de seguridad. SecureRandom utiliza de forma predeterminada el dispositivo/dev/urandom. Por alguna razón, leer este dispositivo en VM se detiene con bastante frecuencia. Generar eventos de consola ayuda a crear más aleatoriedad y liberar el WLS.

Para los propósitos de prueba que han cambiado jre archivo/seguridad/java.security/lib:

securerandom.source=file:/tmp/big.random.file 

Weblogic ahora se inicia en 15 segundos.

Como no probamos ningún elemento de seguridad en nuestras VM, la simiente repetitiva está totalmente bien para nosotros.

Answer 2

Oracle ha creado una nota de Metalink relacionada con este El asistente de configuración de FMW es muy lento en entornos virtuales de Linux. El inicio de los servidores WLS también es muy lento. [ID 1344974.1]

...

Solución 1 1) Descargue e instale las siguientes rpm: rng-utils-2.0-1.14.1.fc6.x86_64.rpm. Póngase en contacto con su proveedor para obtener detalles de la descarga. 2) Puesta en marcha el generador aleatorio de la siguiente manera: rngd -r/dev/urandom -o/dev/-t aleatorio 1

Por defecto parece que hay una dependencia en/dev/random en Linux que bloquea hasta que suficientes aleatoriedad se genera. Los servidores virtuales sin mouse ni teclado conectados pueden bloquear significativamente. En el comando anterior, la entrada se toma del desbloqueo/dev/urandom, por lo que la espera de aleatoriedad no se convierte en un cuello de botella de la aplicación.

Answer 3

En caso de que tenga servidores de aplicaciones estándar de la empresa sin privilegios para cambiar sus binarios, puede agregar un indicador de JVM para sobrescribir el generador aleatorio que se debe utilizar. Por ejemplo:

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

De esta manera no tiene que cambiar ninguna configuración del sistema.

Answer 4

Pruebe la instalación rngd. En sistemas modernos con hardware RNG, esto creará suficiente entropía.