PDA

Ver la Versión Completa : Ayuda con Performance y manejo de memoria


Rodolfo SAP
29/07/09, 22:01:22
Compañeros Abap.

Tengo el siguiente problema, existe un programa estandar que esta generando un dump por falta de recursos (anexo dump) ok entonces lo que se esta pensando es mejorar el performance de las subrutinas de proceso para este programa, estas subrutinas estan en un include Z.

En algunas subrutinas tengo varios select que son a tablas muy muy pesadas ejemplo hrp1001 aprox 400,000 , ZHR_KARDEX_BW aprox 8,000,000 de registros y esta llama a subrutinas lo hace por una iteración GET a una base de datos logica.

Solución.

Mi idea es realizar una extracción global de las tablas y posteriormente realizar puros READ TABLE en las subrutinas, como no puedo modificar el programa Main Estandar no puedo meter alguna subrutina inicial antes del GET object para hacer la extracción global, entonces pienso que se podria crear un programita Z que me deje en memoria las extracciones de datos y posteriormente en las subrutinas hacer el import de esa extraccion para realizar los READ TABLE pero no se como hacer esto no conozco muy bien las funciones EXPORT MEMORY e IMPORT MEMORY y tampoco se si esto se pueda hacer o sea logico factible y pues que sea una buena opcion y si de verdad me puede ayudar a lograr la disminución de tiempo en las subrutinas.

Código programa Main Estandar

GET objec.
PERFORM HR_CUALIF.
PERFORM HR_GET_KAR.
PERFORM HR_CAT_FUN.


Código Subrutinas en un Z Include

form hr_cualif using p_in
changing p_parm like /ehr/s71_user_exit_parm
p_out.

types: begin of hr_profileqk,
class_id type hrpe_profq-class_id, " Grupo
class_text type hrpe_profq-class_text, " Textp grupo
tbjid type hrpe_profq-tbjid, " Caulificación
ttext type hrpe_profq-ttext, " Texto cualificación
profc_text type hrpe_profq-profc_text, " Calificación
profcy type hrpe_profq-profcy, "ID
end of hr_profileqk.

select * from hrp1001 into table gt_escolqk
where otype eq gv_otypeqk and
objid eq so_class-low and
plvar eq p_parm-plvar and
begda le sy-datum and
endda ge sy-datum and
subty eq gv_subty.

if sy-subrc eq 0.

loop at gt_escolqk into gs_escolqk.

so_class-sign = 'I'.
so_class-option = 'EQ'.
so_class-low = gs_escolqk-sobid.
append so_class.

endloop.

endif.


form HR_GET_KAR using p_in
changing p_parm like /ehr/s71_user_exit_parm
p_out.

**INI_INS_ADU030609---------------------------------------
data: ls_zhr_kardex_bw like line of itab_zhr_kardex_bw.
**END_INS_ADU030609---------------------------------------
select pernr fejecucion total from ZHR_KARDEX_BW
into table itab_ZHR_KARDEX_BW
where pernr = p_in.


form HR_CAT_FUN using p_in
changing p_parm like /ehr/s71_user_exit_parm
p_out.

select single hilfm from hrp1010
into hilfm
where plvar = '01' and
otype = 'C' and
objid = p_in and
subty = subty and
begda < sy-datum and
endda > sy-datum.

if sy-subrc = 0.

select single sutxt from t777u
into sutxt
where langu = 'S' and
infty = '1010' and
subty = subty.

select single htext from t777w
into htext
where langu = 'S' and
subty = subty and
hilfm = hilfm.

concatenate subty sutxt '/' hilfm htext into p_out separated by space.

exit.

endif.

ballan
30/07/09, 07:56:05
Esta pregunta es muy compleja y se necesitaria ver bien el codigo y mucho tiempo de analisis yo te digo lo que pienso desde mi desconocimiento d ela naturaleza del proceso que ejecutais

La primera optimizacion siempre debe ser reducir el flujo de datos de los select,
por ejemplo :

no hagas SELECT * si no necesitas todos los campos
acceder siempre a las tablas por campos claves y si no es posible plantear la posibilidad de crear un indice
intentar acotar al maximo para no traer lineas que no vamos a necesitar o que posteriormente vamos a rechazar

Teniendo en cuenta todo esto si el proceso es tan masivo deberia ejecutarse en fondo con lo que te evitarias los problemas de time out y podrias tener mas controlado el tema de quedarte sin memoria (existe un parametro que es la memoria asignada a los procesos en fondo podrias consultar con el BASIS si ese parametro se podria aumentar o incluso si hay la posibilidad de aumentarlo solo para un proceso especifico)

Un proceso ejecutado en fondo la unica limitacion que tiene es que no va a permitir al usuario interactuar con el por lo que si ese es tu caso deberias hacerlo asi y dejar que trabaje la maquina sin tener que hacer grandes modificaciones en el programa

Ya te digo que esto es una aproximacion, seguro que mas gente puede aportar otros puntos de vista

spider_galu
19/08/09, 20:28:39
Estoy de acuerdo en lo del select, debes de optimizar solo los campos que vas a utilizar, colocarlos en el orden en el que estan en la tablas y accesar por los campos llaves, una vez que otienes los datos siempre es bueno verificar si la tabla trajo datos para proseguir ejecutando el programa.

Cuando se utiliza un read table es necesario ordenar la tabla por los campos con los campos vas accesar, además podrias agregarle la sentencia binary search para que el acceso a la tabla interna se mas rápida y eficaz...

Saludos

Rodolfo SAP
27/01/10, 17:49:10
La vdd este tema me ha dado mucha lata pero despues de mucho tiempo consegui una solución para estos temas lo cual aconsejo buscar un buen manualito de performance como por ejemplo....

Hacer uso de Field-symbols y estructutas.

Example.

TYPES: BEGIN OF ty_data,
value TYPE string,
END OF ty_data.



DATA: t_data TYPE STANDARD TABLE OF ty_data.

FIELD-SYMBOLS: <fs_data> LIKE LINE OF t_data.

y usar LOOP AT t_data ASSIGNING <fs_data>.
ENDLOOP.


o por ejemplo


usar la instruccion BINARY SEARCH y un SORT antes en la tabla y ocupando la structura.

SORT t_data BY k ASCENDING.
READ TABLE t_data INTO wa_data WITH KEY K = 'X' BINARY SEARCH.


o por ejemplo

Uso de índices para

COrrecto
DELETE t_dataFROM 450 TO 550. es preferible a:

Incorrecto
DO 101 TIMES.
DELETE t_data INDEX 450.
ENDDO.

O utlizar las herramientas que ya SAP nos proporciona por ejemplo o hasta funciones de mucha utilidad siempre hay algo que nos ayudara.

COLLECT
REPLACE
GET
FIND

El USO DE INDICES O VISTAS TAMBE¡IEN ES RECOMENDABLE.

etc etc




Saludos.