Avalados por :
Tenemos un portal en funcionamiento con la última versión de JDK (Linux X86_64, IBM JDK SR9), con los parámetros recomendados configurados y aún enfrentamos muchos problemas de estabilidad. El portal tiene tres procesos de servidor, lo que vemos en realidad es que dos de ellos consumen el 100 % de la CPU cada uno. Actualmente, nadie está conectado al portal. Puedo ver mensajes "extraños" en el rastreo predeterminado como
sistema predecesor -
com.sap.engine.services.applocking.exception.AppLockingTechnicalLockException: La duración no puede ser la sesión de usuario, ya que actualmente no hay ningún usuario conectado. No se permite crear bloqueos para el usuario del sistema
.
en com.sap.engine.services.applocking.AbstractBaseLocking.getObjectForLifetime(AbstractBaseLockin
g.java:483)
en com.sap.engine.services.applocking.LogicalLockingImpl.getCurrentLifetimeDescription(LogicalLoc
kingImpl.java:193)
en com.sap.engine.services.applocking.AbstractBaseLocking.lockInternal(AbstractBaseLocking.java:1
28)
en com.sap.engine.services.applocking.LogicalLockingImpl.lock(LogicalLockingImpl.java:43)
en com.sap.engine.services.applocking.NamespaceLogicalLockingImpl.lock(NamespaceLogicalLockingImp
l.java:47)
en com.sap.engine.services.applocking.LogicalLocking_Stub.lock(LogicalLocking_Stub.java:65)
en com.sapportals.wcm.service.taskqueue.TaskQueue$Lock.lock(TaskQueue.java:316)
en com.sapportals.wcm.service.taskqueue.TaskQueue$Lock.writeLock(TaskQueue.java:293)
en com.sapportals.wcm.service.taskqueue.TaskQueue.writeLock(TaskQueue.java:467)
en com.sapportals.wcm.service.taskqueue.TaskQueue.get(TaskQueue.java:122)
en com.sapportals.wcm.service.taskqueue.TaskQueueReader.get(TaskQueueReader.java:68)
en com.sapportals.wcm.service.taskqueue.TaskQueueReader.get(TaskQueueReader.java:58)
en com.sapportals.wcm.service.jobprocessor.LocalDispatcher.stopJobs(LocalDispatcher.java:161)
en com.sapportals.wcm.service.jobprocessor.LocalDispatcher.run(LocalDispatcher.java:101)
en java.lang.Thread.run(Thread.java:838)
los dos procesos del servidor están "en bucle" en algún lugar, el sistema de archivos se satura con esos archivos de registro, 4 o 5 de default.trc.X cada minuto.
Reiniciar el portal NO es una opción, ya que ese problema surgirá tarde o temprano de nuevo.
¿Qué podemos hacer como CLIENTE además de crear volcados de hilos y adjuntarlos a una llamada OSS y "esperar"? ¿Cómo averiguar qué está haciendo el sistema?
Markus
Hola David,
Gracias por ese enlace, lo intentaré
¿Esto también funciona con el JDK de IBM? Estamos en 64 bits aquí...
--
Markus
Comprendo tu dolor.
Suena similar a una situación que tuve hace un tiempo cuando algo estaba sobrecargando las CPU y consumiendo memoria.
Aquí tienes un visor de recolección de basura:
http://www.tagtraum.com/gcviewer-download.html
Descarga la versión que prefieras y añade las líneas -Xloggc:<archivo> -XX:+PrintGCDetails al inicio. Esto creará un archivo en el servidor0 (o cualquier número de servidor). Abre ese directorio para navegar y ejecuta el visor en tu laptop. Podrás ver el momento exacto en que el servidor comienza a volverse loco y así identificar los errores generados en ese momento.
Gracias por tu respuesta.
Sí, puedo/podría iniciar sesión, tenemos tres procesos de servidor y dos de ellos estaban/en ese estado. El soporte me dijo que esos procesos solo estaban realizando recolección de basura y debido a que la máquina estaba paginando dentro y fuera del archivo de intercambio, la recolección de basura no podía "terminar" antes de que comenzara el siguiente.
Lo dudo porque al verificar la E/S en la máquina (usando iostat 1) no mostró ninguna E/S grande.
Mientras tanto reiniciamos la instancia, está funcionando hasta ahora, pero aún no puedo creer que no haya forma de verificar qué está haciendo la caja. Verifiqué la conexión de red y además de mi telnet no había otra conexión al sistema (netstat -t | grep -v `hostname`) - así que el sistema estaba ocupado consigo mismo.
Pierdo cada vez más confianza en ese J2EE porque no obtengo mucha ayuda del soporte más que "instalar los últimos parches" e "instalar las últimas correcciones de webdynpro", lo cual no siempre es posible y no es de mucha ayuda en absoluto (aunque las personas hacen todo lo posible para ayudar, no hay duda).
Lo que realmente me vuelve loco es el hecho de que NO HAY FORMA de averiguar qué está haciendo un proceso además de crear volcados de hilos y enviarlos al soporte y "esperar" - o intentar copiar los volcados a una caja de Windows y abrirlos en el analizador de volcados de hilos y empezar a "adivinar".
La configuración es estándar pura, J2EE, Portal, ESS (configurado usando sapinst), sin NWDI, sin aplicaciones desarrolladas por nosotros mismos, simplemente estándar estúpido, el dimensionamiento también está bien, una caja de ese tipo podría manejar fácilmente a algunos cientos de usuarios de diálogo ABAP.
Ha sido una experiencia frustrante en general y se está volviendo peor cada día que miro una de esas instancias de J2EE, la documentación disponible está dispersa por todas partes (help.sap.com, notas, /rkt...) y está muy en la superficie, lo que significa que no obtienes ninguna información sobre cómo se relaciona algo, cómo interactúa algo con qué, etc.
El cliente se mantiene en la ignorancia a propósito y así nunca se encuentra en una situación para ayudarse a sí mismo, y todo esto por un software tan promocionado por la palabra de moda por la que pagamos tanto dinero.
Lo siento, me desvié del tema, no quería ser grosero, pero todo ese software de "haz clic aquí y luego allá" no es de mucha utilidad si no conoces el trasfondo, simplemente estás perdido.
--
Markus
¿El portal está funcionando en absoluto?
¿Puedes iniciar sesión como usuario o administrador?
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
