Manual Alertas del sistema

[cbqjob]

Buenos días,

Nuestro sistema va muy lento y estamos buscando las posibles causas, alguien podría decirme dónde encontrar un manual que me ayude a interpretar las transacciones de monitorización y sus parámetros? (transacciones ST02, ST06,...).
Alguien puede orientarme de cuáles pueden ser las causas de la lentitud en el sistema? paginación? swapping?...

Muchas Gracias,
cbqjob

[aromodom]

El nuestro tambien iba muy lento. ¿que entorno tenéis?

Lo nuestro se resolvio bajando el número de WorkProcess en dialogo que estaban disponibles.

Cuando las cosas iban mal se tiraban swapeando el 100% del tiempo...

[cbqjob]

Estamos en unix, con bbdd oracle,en windows2000, versión 4.6c. y creo que hay muchas posibilidades de que nos pase lo mismo que a vosotros... sabes la transacción para modificar el parámetro workprocess en diálogo disponibles? podría mirar cuántos tenemos....
Muchas gracias por tu ayuda aromodom!!!
Saludos,
cbqjob

[johangonz]

Por la trx SM50 ves la cantidad de work process que tienes configurados en el sistema. Para cambiar los work process lo haces desde la trx RZ10, eliges el perfil de la instancia y modificas los wp.

Aquí hay algo de tuning del sistema:

COMO SE HACE UN TUNING TCC

DETERMINACIÓN DEL PROBLEMA
o ¿Cuántos programas son los que están lentos?
o ¿Cuales programas?
o ¿Cuál es el tiempo promedio de respuesta de esos programas?

TUNNING DEL SISTEMA

CONFIGURACIÓN BASICA: SERVERS, WORK PROCESS AND LOAD BALANCE
Transacciones: SM50, SM51, SM66.
Hay que chequear si hay procesos en PRIV mode y si es así hay que hacer un análisis de la administración de memoria y chequear parámetros de perfiles.
Nota 33873 provee una lista de códigos y definiciones por lo general semáforos que están relacionados con el sistema operativo

HARDWARE Y SISTEMA OPERATIVO
Reglas:
Solo debe estar corriendo R/3 en el servidor de otra manera es muy difícil medir el sistema operativo.
Transacciones: OS06, DB03, ST06.
Definiciones de ST06 y como es que puedes sospechar del problemas en el sistema operativo:
o CPU idle debe ser mayor a un 10% y cuando es el sistema solo tiene un servidor constantemente case hasta 30%.
o PAGES OUT/SECOND cuando excede 10,000 por hora en un periodo de 24 horas
o LOAD AVEREAGE en lo últimos 15 minutos excede a 3.
o PHYSICAL MEMORY AVAILABLE valores muy bajos, pero debes de esperar cuando menos 1GB de memoria disponible
o PHYSICAL MEMORY FREE valores extremadamente grandes. hay que checar el parámetro.

SAP R/3 WORKLOAD ANALYSIS.
ST03 CONDICIONES PARA UN PROCESO DE DIALOGO
DESCRIPCION MAX VALOR ACEPTABLE
Average response time 1500 ms
average CPU time 40% del response time
Average database request time 40% del response time
average wait time 50 ms
average load time 50 ms
time per database 5ms
direct reads 2 ms
sequential reads 10ms
change and commits 25ms
roll intime or rollout time 10ms
response time for main menu 100ms
La transacción ST03 se usa para análisis de workload y también la RZ03 va a generar estadísticas similares.
También la transacción ST03 puedes encontrar estadísticas para ciertas transacciones ciertos periodos y estas herramientas pueden ser utilizadas para check jobs específicos
Hay que recordar que los queries a tablas muy grandes pueden causar excesivo roll in y roll out especialmente en un proceso de dialogo

COMPARACIÓN DE TIEMPOS DE RESPUESTA DE PROC. DE DIALOGO Y BACKGROUND
Casi todos los jobs de background son reportados como dialog step y van a causar un alto porcentaje de response times.
Los tiempos de respuesta para query o programas de reporteo por lo general van a tener un porcentaje muy bajo de CPU y mas porcentaje de database request tiem.
Programas que realizan cálculos complejos o rutinas que se calendarizan (p.e. material requirement planning van a tener mayor porcentaje de CPU que de DB).
Programas hechos por el cliente que no estén almacenados en buffer y generan código. (Ejemplo BDC batch data conversion programs) va a tener mayor load time.

SSAP R/3 BUFFERS STATISTICS
Transacción ST02 es usada para hacer un tuning de la memoria by buffers del sistema. Es muy compleja.
Hay varios parámetros (cientos) que afectan al sistema en performance y la mayoría de estos afecta a la memoria.
ST02:
DESCRIPTION DEFININICION
HIRATIO El hitratio es un indicador de la eficiencia de los buffers, cuando un usuario de SAP necesita datos primero checa en los buffers de R/3. Cuando el sistema se reinicia los buffers se limpian. Los buffers deben tener un hitratio de 0 y deben llegar hasta un 100% si se puede. es recomendable tener un hitratio arriba de 90%.
NAMETAB, CUA, SCREEN AND CALENDAR Estos buffers se les ve poco crecimiento en un ambiente de producción por lo que pueden ser configurados con mejor espacio libre. La mayoría de los demás buffers deben tener un 20% más de espacio libre.
DIRECTORY ENTRIES Todos lo buffers necesitan entradas libreas a directorios, el espacio en memoria requerido para almacenar directory entries es minimo.
OBJECT SWAPS Mucho swapeo por lo general indica un tuning mal hecho, sin embargo algunos swaps no pueden dejar de hacerse. el swapeo se acumula a partir del inicio de instancia. los BDC y otras funciones que generan código en tiempo real incrementan el swapeo.
ROLL AND PAGING AREA MEMORY Solo se puede analizar en detalle cuando el porcentaje de uso exceda el 80% constantemente, de igual manera para el extended memory cuando el porcentaje de uso exceda 75 por ciento.
HEAP MEMORY Los programas batch pueden utilizar grandes cantidades de heap memory y por lo general causan mucho swapeo a nivel SO. Cuando veas que se utilizan grandes cantidades de Heap memory hay que checar que se tenga el suficiente swapeo a nivel SO.
CALL STATISTICS Puedes utilizar call statistics para analizar buffering de tablas y que tan eficientemente lo usan los abap programs. Investiga el hitratio y el numero de fallas.

TUNNING SPECIFIC PROGRAMS
Que herramientas hay disponibles para analizar problemas con funciones o programas específicos
o ABAP RUNTIME ANALYSYS (SE30)
o ABAP PROGRAM EXTENDED SYNTAX CHECK (SLIN)
o PROCESS OVERVIEW(SM50)
o PERFORMANCE WORKLOAD ANALYSIS (st02, st03)
o PERFORMANCE WORKLOAD STATISTICS RECORDS (stat)
o MISCELLANEOUS DATABASE STATISTICS (ST04, DB01,DB02)
o TRACE REQUEST (ST05)
o ABAP PROGRAM DEBUGGER(SE38)

Johan González
Administrador Comunidad Basis en Español

[r2ro]

Muy interesante el post Johan. Me ha servido de mucho ya que soy nuevo en esto de tunning del sistema y me podrías aclarar a que se refiere con "SWAP"?

Muchas gracias.

Arturo Pairazamán

[johangonz]

Te felicito por usar el buscador, ni yo recordaba algunas cosas de esas como hay cosas que han cambiado y son distintas. El tuning como mencioné es algo delicado de hacer, algo que es progresivo, ya que es importantante ir validando que cada parametro que se ajuste ayuda a mejorar y no hace lo contrario.

El swap es SAP es como la memoria virtual en Gindows (del verbo guindar), el cual es un área de disco que se usa como memoria para cuando en los buffers de SAP se ocupa todo el espacio de memoria fisica asignado, el procede a escribir en este area de disco que es usado como memoria. El detalle es que cuando existe mucho swap, el performance se degrada por los accesos de lectura y escritura en disco, por ende lo optimo es que este use sólo la memoria fisica para sus buffers, por ende hay muchas veces, cosa que me causa cierta gracia que los clientes le meten mas hierros (memoria, cpu) a los servidores donde ejecutan sistemas SAP pero no los ajustan en base a estas mejoras, y por ende los sistemas no muestran gran avance, ya que no se trata de la RAM disponible, sino de la RAM que se dimensiona en los buffers al aplicativo y la base de datos.

[r2ro]

Gracias Johan por la explicación ... hay alguna forma de que el sistema envíe alertas? he revisado la SM50 y por mas que me quede viendo por una hora esta transacción no encontré ningún proceso que tenga un valor en la columna Semáforo. según la nota SAP dice que se puede ver estas alertas pero no vi ninguna, o se tiene que activar algo para poder ver las alertas? ... lo que pasa es que nuestro sistema va lento, ya le hemos aumentado la cantidad de procesos de dialogo, se cambiaron algunos parámetros de los buffer pero aun así sigue lento. identifique que algunas trx Z tienen un alto tiempo de respuesta, es posible revisar los procesos de los Z o el tiempo de respuesta de los Z antes de que salgan en productivo?