Basis - 5

Academia Basis
Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 1

Marcio Cicarelli -–Companhia Energética de Minas Gerais - CEMIG
Semana 5 – 21/02/2000 a 25/02/2000 – Rinaldo
Marcio Cicarelli - Cemig

Índice
ACADEMIA BASIS 1
Semana 5 – 21/02/2000 a 25/02/2000 – Rinaldo 2
Índice 3
R/3 SPOOL AND PRINT 6

R/3 Spool System 6
Spool and Output Requests 6
Spool Work Processes 6
Local and Remote Printing 7
Spool Administration 7
Frontend Printing 7
Logical Spool Servers 8
Spool Request Management 8
R/3 OUTPUT MANAGEMENT 8

Device Pools 9
External Output Management Systems (OMS) 9
Spool Server and Requests Management 9
Non-Standard Printers 10
Character set 10
Format, Page format e Format actions 10
Print controls 10
Message Control and EDI 11
SAPconnect 11
INTRODUCTION TO WORKLOAD ANALYSIS 11

Performance Problems 11
Basis Tuning 12
Application Tuning 12

Response Times 12
Wait time 12
Roll in time 12
Database time 13
Processing time 13
CPU time 13
Workload Statistics 13
Workload Analysis 13
Analysis Roadmap using workload monitor (ST03) 14
Analysis Roadmap using transaction profile (ST03  Transaction profile) 14
PERFORMANCE ANALYSIS MONITORS 14

Work Process Overview 14
Analysis Roadmap using work process overview (SM50 ou SM66) 14
Operating System Monitor 14
Buffer Monitor 15
R/3 MEMORY MANAGEMENT 15

R/3 Memory Areas 15
Local memory for work processes 15
R/3 buffers 15
Extended memory 16
Heap memory 16
Roll memory 16
Paging memory 16
Allocation Concepts 16
Allocation Sequence for Dialog Work Processes 17
Heap Memory Management 17
R/3 Extended Memory 17

Analysis Roadmap: R/3 Memory Configuration (ST02) 18
HARDWARE CAPACITY VERIFICATION 18

Hardware Bottlenecks 18
Analysis Roadmap: Hardware consuption (ST06) 18
Optimizing the Configuration 19

Memory configuration 19
CPU configuration 19
EXPENSIVE SQL STATEMENTS 19

Consequences of Expensive SQL Statements 19
SQL Statements and Monitors to Analyse 20

Analysis Roadmap using transaction profile (ST03  Transaction profile) 20
Analysis Roadmap using work process overview (SM50 ou SM66) 20
Detail Analysis and Tuning 20
ROAD MAPS SUMMARY 22

Analysis Roadmap using workload monitor (ST03) 22
Analysis Roadmap: R/3 Memory Configuration (ST02) 22
Analysis Roadmap: Hardware consuption (ST06) 22

R/3 Spool and Print
R/3 Spool System

 O R/3 possui diferentes formas de enviar documentos através de seus sistemas de spool.
Um documento formatado, que pode ser uma impressão, um fax ou um EDI, representa
uma message no sistema R/3 e, uma vez criada, estará liberada para impressão ou
transmissão.
 As impressões no R/3 podem ser imediatas ou adiadas para posterior saída. Além do
message control, o R/3 possui uma combinação de programas de impressão e
SAPScripts para produzir os documentos de impressão. Enquanto o programa de
impressão obtém os dados a serem impressos, o SAPscripts especifica o layout do
documento a ser impresso.
 Como o sistema R/3 é um ambiente multiplataforma, foi criado um sistema interno de
spool para interfacear com os diversos hosts nos quais o R/3 pode rodar. Através deste
princípio o R/3 formata os documentos e requisita ao spool do sistema operacional que
apenas repasse o documento para o dispositivo físico
Spool and Output Requests

 Um spool request é criado quando um documento R/3 é requisitado para impressão mas
ainda não foi enviado para o dispositivo de saídaOs dados ficam armazenados em um
formato genérico interno do R/3
 Um spool request formatado para um determinado dispositivo gera um específico
output request. Vários output requests podem ser gerados a partir de um único spool
request, contendo cada um os atributos o comandos específicos de um determinado
hardware de impressão.
 Os spool requests gerados ficam armazenados em um repositório denominado
Temporary Sequential Database, ou TemSe. Este repositório poderá estar no banco de
dados do R/3 ou em arquivos do global directory do sistema operacional (determinado
pelo parâmetro de profile rspo/store_location = db ou G).
 Os output requests são armazenados apenas como registros de controle. Os formatos de
impressão uma vez gerados são repassados diretamente para o sistema operacional sem
serem armazenados na base de dados.
Spool Work Processes

 Quando uma requisição de impressão de um spool request é efetuada, um output request
específico para o device desejado é criado pelo spool work process do R/3, que lê os
dados a serem impressos no TemSe (spool request) e o formata baseado no driver do
sispositivo especificado.
 Uma vez formatado, o dado é repassado diretamente para o spool do sistema
operacional para que o encaminhe para o dispositivo endereçado.
 Para formatar corretamente a saída, além do driver específico do dispositivo o R/3
utiliza informações referentes ao character set utilizado e comandos específicos do
dispositivo para formatação dos dados.
Local and Remote Printing

 Os output requests formatados são repassados para os dispositivos através de strings de
impressão. Quando se utiliza o método Local (L), os dados são repassados diretamente
para o spooler do sistema operacional que cuida de envia-los, seja para uma impressora
conectada diretamente ao host ou através da rede. É o método mais rápido, uma vez que
a tarefa de gerenciamento do string até o dispositivo de saída fica a cargo do sistema
operacional, liberando o work process desta tarefa.
 Remote printing consiste na transferência dos output requests diretamente para os
dispositivos remotos. Neste caso o spool work process fica responsável pela negociação
com o dispositivo através da rede. Este método de acesso remoto (S ou U) é menos
otimizado por onerar o work process gerando possíveis contenções na impressão.
 A transmissão remota é feita através de lpd (line printer daemon) e a SAP provê o
programa SAPLPD para as plataformas que não possuem este protocolo standard.
Spool Administration
 A transação SPAD é utilizada no R/3 para a administração de spool.
 As impressoras (output devices) são definidas especificando o método de acesso (local
ou remoto – L, S ou U) e suas características (driver, nome, host name, etc.)
Frontend Printing
 A impressão frontend no R/3 permite que usuários enviem output requests para
impressoras que não foram definidas como output devices no R/3. É o denominado
método de acesso F
 Caso a estação do usuário seja um PC windows, o request é enviado para um SAPLPD
rodando na estação do usuários. Se o SAPLPD não estiver rodando, ele é iniciado e
manipula os requests e os envia para a impressora default do usuário
 Neste método de acesso o processamento do spool é efetuado pelos próprios dialog
work processes, não havendo necessidade de encaminhar o request para os spool work
processes
 Para definir uma impressora frontend para as estações windows, além de especificar o
método de acesso F, é necessário definir o device type SWIN (qualquer impressora com
device instalado no windows) e o host printer deverá ser __DEFAULT.

 Este método deverá ser evitado em sistemas produtivos por utilizar os work processes
para tarefas que deveriam estar reservadas para os spool work processes
Logical Spool Servers

 Logical spool server é uma camada que permite mapear spools lógicos para físicos,
permitindo efetuar o switch dinâmico de servidores.
 Um real spool server no ambiente R/3 é uma instancia com pelo menos um spool work
processes definido.
 Este mecanismo de definição lógica permite efetuar o switch facilmente entre servers
reais que estão indisponíveis sem interrupção do serviço de impressão para os usuários.
 Através do mcanismo de transportes de change requests do R/3 é possível definir toda
uma arquitetura de impressão em um ambiente e posteriormente transporta-la para os
demais sistemas do landscape.
Spool Request Management

 O spool requests gerados no sistema devem ser gerenciados pelo administrador para
garantir a disponibilidade do ambiente.
 O programa RSPO0041 deve ser schedulado em todos os sistemas para efetuar o
trabalho de housekeeping e eliminar spools antigos do sistema.
 A transação SP01 é o spool request viewer, que permite aos usuários ver seus requests e
requisitar outputs ou eliminar spools. Administradores com autorizações apropriadas
podem ver todo o spool request do ambiente.
 A transação SPAD ou o programa RSPO0043 pode ser utilizado para chacar a
consistencia entre os spool requests, output requests e output datas são consistentes.
 A verificação de problemas associados com os spool requests pode ser efetuada tanto
pela SP01 quanto pela SM21 ou ST22.
 Existem objetos de autorização específicos para diversas operações de spool no R/3,
seja protegendo determinados dispositivos de saída (S_SPO_DEV) ou limitando o
poder de gerenciamento . O objeto S_SPO_PAGE limita o número máximo de páginas
que um usuário pode imprimir em um determinado dispositivo. Para que esta
autorização tenha efeito é necessário ativar o parâmetro de profile
rspo/auth/pagelimit=1.
R/3 Output Management

 Através da opção de administração extendida na SPAD, uma série de funções
avançadas podem ser escolhidas

Device Pools
 O conceito de device pools é permitir que se defina um pool de dispositivos de saída
que podem ser referenciados através de um único nome. Device pools são definidos
especificando método de acesso P e a lista dos dispositivos que o compõem.
 Output requests podem ser enviados para todos os dispositivos que compõem o pool
simultaneamente ou pode-se requisitar que o sistema efetue o balanceamento de carga
entre os dispositivos de saída da lista.
 Os dispositivos que compõem a lista de um device pool podem ainda ser acessados
individualmente como devices independentes
External Output Management Systems (OMS)

 O R/3 permite integrar ao seu ambiente sistemas externos de gerencia de impressão que
podem se fazer necessários em ambientes complexos. Esta comunicação é efetuada
através do XOM-API
 Através da definição de um objeto real de OMS (ROMS) e de pelo menos um objeto
lógico OMS (LOMS), os spool requests de um sistema R/3 podem ser passados para o
sistema externo.
 Os devices no ambiente R/3 que serão gerenciados pelo sistema externo OMS são
definidos com o método de acesso E.
Spool Server and Requests Management

 Qualquer instancia R/3 que possui spool work processes é denominada um spool server
 O R/3 permite a definição de um alternate spool server que pode assumir as tarefas de
um spool server principal.
 Quando se assinala o campo non-exclusive spool server no atributo de um spool server
o sistema R/3 efetua o balanceamento de carga dos requests de impressão.
 O sistema R/3 permite que se classifique os servidores e os dispositivos em categorias
(High volume, Production, Desktop e Test) o que faz com que o sistema envie uma
mensagem de warning quando se efetua o assign de um determinado dispositivo com
um server incompatível.
 Os requests enviados para um determinado spool server caem em uma fila de spool e
são processados sequencialmente. Quando o server possui mais de um spool work
process, os requests são manipilados paralelamente de forma que determinado request
da fila poderá ser enviado para um disposistivo antes de outro documento pesado que
ainda esteja sendo formatado. Caso se defina um dispositivo com a opção de sequential
request procesing, os output request para o dispositivos serão serializados. Esta
definição pode causar impacto em todo o sistema de impressão, já que durante a
presença de requests para o device, um determinado work process fica reservado para
processar a fila

 Para permitir que os usuários acompanhem o andamento de seus requests, os spool
work process questionam os devices sobre o sucesso das operações. Uma vez que
durante este tracking o spool permanece aguardando uma resposta, isto pode ser
particularmente problemático para impressoras remotas ou com baixa performance
na rede. Esta opção pode ser desabilitada para um dispositivo de saída especificando no
longer ask for print requests in host spool.
 Ao se especificar o atributo monitoring usingmonitoring infrastructure, o device pode
ser monitorado atrvés da árvore de MTEs do CCMS
Non-Standard Printers
 Quando um determinado dispositivo de saída não possui device padrão no R/3, é
possível criar um driver personalizado para o dispositivo através da especificação de
alguns objetos.
 A transação SPAD fornece todos os mecanismos para formatar e testar o drive a ser
utilizado pelo novo dispositivo.
 Antes de definir um novo dispositivo, verifique no OSS se já não existe disponível o
novo drive para ser baixado do sapservX.
Character set
 O character set é especifica os códigos internos armazenados no spool request e seus
respectivos ASCII que serão impressos. É um de para.
 Cada caracter tem um código interno no R/3 (nenhuma relação com o ASCII), cuja lista
pode ser visualizada através da SPAD (Full Administration  SAP characters). É
possível acrescentar caracteres nesta lista, utilizando os códigos 9000 a 9999.
 Cada tabela de character set disponível transcreve este código interno R/3 para um
determinado ASCII. Para adapter uma determinada tabela, é necessário inicialmente
copia-la e então efetuar as alterações na cópia e salvando posteriormente as alterações
em um character set identificado por 9nnn (começa por 9)
Format, Page format e Format actions
 Format identifica o papel utilizado pelo R/3 (letter, A4, etc.). Quando utilizamos
formula’rios que não são padrões é necessário definir novos formatos pela SPAD
 Page formats provê a interface entre o format e o SAPscripts, permitindo que os
programas R/3 possam determinar o número de linhas por página, entre outros dados.
 Para definir format actions, ou seja, como determinado dispositivo manipula um
determinado formato de impressão, é necessário editar o dispositivo de saída e
acrescentar na sua opção de format as sequencias de caracteres para efetuar as
operações de impressão (new line, skip page, 12 char/inch, etc.)
Print controls
 Os print controls determinam como um determinado dispositivo eftua determinadas
operações, como por exemplo imprimir em bold. Print controls são específicos de cada
device e durante a formatação são convertidos para determinadas sequencias de
caracteres.
Message Control and EDI

 O message control é utilizado no R/3 para troca de informações entre parceiros
envolvidos em uma determinada regra de negócio.
 Os documentos gerados (EDI, fax, impressões, etc.) são normalmente gerados através
de exits específicas dentro programas R/3 que são chamadas para formatar a saída
desejada. Dependendo da customização efetuada, o documento gerado é enviado como
parte da transação ou fica pendente para posterior envio
 O EDI, Electronic Data Interchange, é a troca de mensagens de negócio entre dois
sistemas através de interfaces standard. A SAP não fornece um subsistema EDI no R/3,
mas provê uma interface aberta para estes sistemas se conectarem. Esta interface é
baseada em Intermediate Documents, ou IDOCs
 No R/3 todos os dados transferidos por EDI são transferidos através de RFCs entre os
sistemas envolvidos.
SAPconnect
 O SAPconnect é uma camada que permite a comunicação do R/3 com outros sistemas
externos, tipo fax ou mail servers.
 A conexão do R/3 com sistemas externos normalmente requer a especificação de
interfaces externas, porém a conexão entre dois sistemas R/3 via SAPconnect pode ser
feita diretamente. Estes adapters externos devem ser fornecidos por cada fornecedor
interessado em se conectar com o sistema R/3.
 A SAP fornece um adapter para o Microsoft Exchange Server que pode ser configurado
para integrar as duas ferramentas.
Introduction to Workload Analysis
Performance Problems
 A workload analysis consiste em aplicar métodos específicos de análise dos tempos de
resposta em um sistema R/3 para que se encontre gargalos e programas problemas no
ambiente conseguindo com isto efetuar ajustes finos de performance que consigam
diminuir o tempo de resposta das transações e aumentar o throughput do sistema
 Tempos de resposta ruins deverão ser analisados localizadamente (por transação) ou no
sistema como um todo (média geral dos tempos de resposta), dependendo da forma
como o problema se manifesta.

Basis Tuning
 Uma análise geral do ambiente tem por finalidade distribuir corretamente a carga do
ambiente entre os servidores de um sistema R/3
 Isto significa dimensionar corretamente o hardware, distribuir os discos e otimizar a
definição dos work processes e buffer das instancias
Application Tuning
 Um tuning localizado de uma aplicação tem por finalidade evitar que programas mal
especificados produzam uma carga desnecessária no ambiente
 Esta análise vai desde a localização e aplicação de notas do OSS até a otimização dos
códigos dos programas desenvolvidos na instalação (programas Z). Eventualmente esta
análise cheja a conclusão de que é necessário criar novos índices nas tabelas do sistema.
Response Times
 O tempo de resposta (response time) de uma transação no R/3 é o tempo entre a
requisição do usuário ao sistema e vai até o retorno da próxima tela, podendo ser
dividido em vários componentes individuais que permitem uma análise mais profunda
no componente causador da má performance. O tempo de transmissão (rede) não é
computado pelos monitores do R/3:
 Wait time: é o tempo de permanencia do request na fila do dispatcher
 Roll in time: o tempo necessário para efetuar o roll in dos dados de contexto do
usuário para dentro do work process
 Load time: o tempo necessário para carregar os objetos (e eventualmente gera-los)
do dicionário ABAP para os buffers da instancia
 Processing time: é o tempo gasto para processamento dentro do work process,
equivalendo a diferença entre o response time e a soma de todos os demais tempos
 Database request time: tempo de processamento dos SQL, que começa quando a
requisição é encaminhado ao database interface e termina quando este retorna com o
resultado
 CPU time: tempo de CPU consumido pelo work process para executar o request
Wait time
 Os requests encaminhados pelo SAPGUI são colocados em uma fila de espera FIFO
pelo dispatcher. Um elevado tempo de permanência nesta fila indica indisponibilidade
de work process. Esta indisponibilidade pode entretanto vir de uma pequena definição
de número de work processes como também pode significar que os work processes não
estão sendo liberados com a rapidez esperada. Elevados wait times merecem uma
análise menos simplista.
Roll in time
 Roll in é a transferência dos dados do contexto do usuário do roll buffer para a roll
memory do work process. Ao efetuar esta transferência tem-se início ao processamento

do dialog step. Tempos elevados de roll time podem indicar problemas no
gerenciamento de memória do R/3 ou ainda gargalos de CPU para efetuar a operação
Database time
 Quando um dado é requisitado via um open SQL, a requisição é enviada para o
database interface do work process que efetua o request ou localmente nos database
buffers da instancia ou envia a requisição para ser processada pelo servidor de bancos
de dados. Tempos elevados no componente database podem indicar gargalos na
instancia DB, problemas de rede (se outra instancia), comandos SQL caros, falta de
índices, enfim uma série de problemas relacionados ao tuning do banco.
Processing time
 O processing time é definido como o tempo de resposta total menos o wait, database,
load, roll e enqueue time. Tempos elevados podem significar loops no programa.
CPU time
 O tempo de CPU consumido pelo work process durante um dialog step é computado no
CPU time. Tempos elevados de CPU indicam problemas na lógica do programa ABAP,
tais como processamento de tabelas muito extensas.
Workload Statistics
 O Performance Monitor (transação ST03) dá informações detalhadas e estratificadas
dos tempos de resposta em em sistema R/3
 A proporção apresentada entre o número de database calls e os database requests dá
uma noção exata da eficiência da buferização de tabelas, indicando o número de
requests que tiveram que ser encaminhadas ao DB server pelo database interface.
 As chamadas externas de funções RFC podem provocar roll out do user context para
liberação do work processes. A espera pelo retorno (roll wait) e posterior roll in, todos
estes tempos ficam embutidos no roll time do dialog step. Transações com elevado
número de chamadas RFC tendem a ter um roll time mais elevado que as demais.
Workload Analysis
 Uma análise geral pode indicar se existem problemas de performance gerais na
instalação:
 Wait time deverá ser < 10% response time
 Main menu deverá estar < 100 ms
 Através da ST03, alguns valores indicam boa performance:

 Average roll in time < 20 ms
 Average roll out time < 20 ms
 Average load time < 10% response time e sempre inferior a 50 ms
 Average database time < 40% do (response time – wait time)
 Average CPU time < 40% do (response time – wait time)
 Average CPU time não pode ser muito inferior ao processing time

Analysis Roadmap using workload monitor (ST03)
 Workload Monitor (ST03)
 Wait time > 10% response time  general performance problem
 DB time > 40% (response time – wait time)  detail SQL analysis
 Processing time > CPU time x 2  detail hardware bottleneck analysis
 Load time > 50 ms  mem. config. analysis (small buffer)
 Roll time > 20 ms  mem. Config. analysis (extended mem. & roll buffer)
 Processing times muito superiores ao CPU time indicam gargalos de CPU ou problemas
de comunicação
 A opção de trasnsaction profile da ST03 exibe a distribuição dos tempos por transação,
permitindo análises individualizadas, permitindo efetuar esforços de tuning nas
transações mais utilizadas
Analysis Roadmap using transaction profile (ST03  Transaction profile)
 Transaction profile, sorted by “response time total”
 CPU time > 40% (response time – wait time)  detail ABAP analysis
 A transação STAT exibe estatísticas individualizadas por servidor
Performance Analysis Monitors
Work Process Overview

 A transação SM50 permite a monitoração dos work processes de uma instancia R/3.
 A monitoração deverá se ater aos processos com status running e aqueles com status
stopped, que indicam work process em modo PRIV
Analysis Roadmap using work process overview (SM50 ou SM66)
 Work Process Overview (SM50/SM66)
 WP in status running  Long processing: analyse status field
 Dir. Read, Seq. Read, Insert, Update, Delete, Commit  DB analysis
 Load Report  mem. config. analysis (small buffer)
 Roll in/out  mem. Config. analysis (extended mem. & roll buffer)
 WP in status stopped  Heap area allocation: analyse reason
 PRIV  mem. Config. analysis (extended mem. & roll buffer)
 CPIC  CPIC connection problem
Operating System Monitor

 A transação que permite a monitoração do sistema operacional no R/3 é a ST06, que
exibe informações sobre utilização de CPU, swaps, utilização de discos e configuração
do sistema operacional.

 Gargalos de CPU aparecem quando temos menos de 10% idle ou quando o Load
Average indica um valor superior a 2 vezes o número total de CPUs disponíveis
 Problemas de alto consumo de CPU podem ser identificados através da análise dos
topCPU processes, no detail analysis. disp+work são os processos R/3 e ORACLE80 é
um processo de banco de dados
Buffer Monitor
 A transação ST02 é o monitor dos buffers do R/3, indicando tamanhos, qualidades e
percentuais de ocupação.
 Quando detectamos que a extended memory atingiu 100% de utilização ( Max use = In
memory), começarão a aparecer contenções de memória para os work processes. Roll
area com valores de Max use superiores ao In memory indicam que a utilização de roll
area teve que ser expandida para disco, o que é ruim
R/3 Memory Management
R/3 Memory Areas

 A memória física é a memória em RAM instalada na máquina. A área de swap é uma
area em disco pelo sistema operacional para paginar a memória utilizada pelos
processos.
 Quando alocamos uma memória em unix, estamos efetuando uma alocação de memória
virtual. O sistema operacional é quem decide se a memória alocada estará em disco ou
em memória física.
 Dependendo do sistema operacional utilizado, a memória virtual terá um valor entre o
swap especificado e a soma do swap com a memória real.
 Uma instancia possui duas áreas básicas de memória: local memory e shared memory
Local memory for work processes
 É a memória associada com cada work process. Esta memória é utilizada para:
 Executáveis
 Dados, stack
 Buffer para transferência de dados
 Local roll area
 Local paging area
R/3 buffers
 Memória alocada na shared memory e que contém objetos globais de todos os usuários
e work processes, tais como programas e tabelas de customização.

Extended memory
 A extended memory contém dados de contexto associados com a transação de um
determinado usuário, tais como variáveis, listas, tabelas internas, etc.
Heap memory
 A heap memory é alocada pelo work process diretamente na área de swap. Work
processes que começam a utilizar heap area entram em PRIV mode, desta forma não
efetuando mais roll out/roll in, ficando desta forma dedicado ao usuário.
Roll memory
 A roll memory é alocada no roll buffer (shared memory) e contém a parte inicial do
contexto do usuário
Paging memory
 É uma área utilizada pelos work processes na paging area (shared memory) para
determinadas operações.
Allocation Concepts
 Os work processes são compartilhados pelos vários usuários que se conectam a uma
instancia. Este compartilhamento efetuado a cada dialog step (ou chamada RFC) força o
R/3 a manter um mecanismo que salve os dados do usuário e permita o reinicio do
processamento quando solicitado pelo usuário no próximo dialog step
 Estes dados referentes a um determinado usuário é denominado user context area. Este
conceito permite por exemplo que um determinado código de naterial que o usuário
trabalhou em uma transação seja “lembrado” como default na próxima transação.
 O conceito de roll out salva a user context area garantindo assim que os dados de um
usuário não sejam sobrescritos pelos usuários que utilizam o mesmo work process
posteriormente. Os dados são movidos (rolled out) para disco
 O próximo dialog step provoca o retorno da user context area para o work process que
irá processa-lo. Este processo é denominado roll in.
 Existem duas áreas no R/3 que sofrem este processo de roll out/roll in. A roll area
propriamente dita contém os dados de contexto do usuário associados a autorizações,
internal tables e report lists. A paging area contém a memória associada a alguns
comandos específicos de ABAP.
 A extended memory é alocada na shared memória e disponibilizada para os work
processes que podem requisitar pedaços de memória que ficam mapeados nos work
process através de pointers armazenados na respectiva roll area. Isto permite diminuir o
contexto de roll out/in apenas para referências (pointers) à extended memory alocada.

Allocation Sequence for Dialog Work Processes
 A fim de minimizar o volume de dados necessários para as operações de roll in/out, o
sistema R/3 procura otimizar a alocação de memória através de uma metodologia nesta
operação
 Inicialmente apenas uma poção mínima da roll area é alocada, definida pelo parâmetro
ztta/roll_first. Quando este parâmetro é setado para 1, um mínimo de 100K será alocado
para o processo
 Quando o processo necessitar de área para trabalho, o sistema alocará memória na
extended memory da shared memory e grava na roll area do work processes apenas um
pointer para a área alocada. Esta aquisição de memória na extended memory vai sendo
permitida até que não haja mais memória disponível ou então quando o work process
atinge a sua cota de alocação, definida pelo parâmetro ztta/roll_extension. Esta área não
será copiada durante o processo de rolagem, mas sim mapeada, ou seja apenas as
referências (pointers) serão copiados
 Quando se esgota a alocação de extended memory o work process começa a alocar o
restante da roll area disponível, o que acaba aumentando a quantidade de area sujeita a
roll out/in
 O último passo quando se esgota a roll area é alocar memória na heap memory, Quando
este passo acontece, o work process entra em PRIV mode e para de efetuar rolagem da
área de contexto, o que significa que ele permanecerá alocado para o usuário até o
término da transação. A quantidade máxima de área que pode ser alocada na heap area
para cada work process é definida pelo parâmetro ztta/heap_area_dia
 A partir do release 4.0 do SAP os demais work processes também utilizam este mesmo
critério para alocação de memória.
Heap Memory Management

 Quando heap area é alocada por um work process o mesmo entra em PRIV mode, o que
significa que ele irá parar de efetuar a rolagem para efetuar multitasking, permanecendo
alocado (private) para o usuário.
 Esta área heap é liberada no término da transação porém não será liberada na swap area
do sistema operacional. Esta área somente será liberada se matarmos (kill) o processo
(disp+work) a nível de sistema operacional.
 Existe um parâmetro (abap/heaplimit) que quando atingido pelo total de heap area
alocado por um determinado work process, ele será flagado para automatic restart, ou
seja, o sistema efetua um refresh (kill/start) do work process ao término da transação.
R/3 Extended Memory

 Quando se utiliza um novo parâmetro do R/3, o PHYS_MEMSIZE, ele permitirá que o
próprio R/3 gerencie a sua alocação de extended memory até um limite definido por

em/max_size_MB. Este procedimento simplifica a administração de memória e é
denominado Zero Administration Memory Management
 O tamanho máximo da memória alocada para extended memory (parâmetro
em/initial_size_MB) em UNIX depende da arquitetura utilizada. Em plataformas 32
bits o limite é de 2G, já para sistemas 64 bits, este limite sobe para 108TB.
 Deverá sempre haver uma quantidade suficiente de memória real compatível com a
parametrização do R/3 para evitar paginação excessiva de sistema operacional.
Analysis Roadmap: R/3 Memory Configuration (ST02)
 Buffer Monitor (ST02)
 Many swaps  increase buffer size
 Extended memory: Max used > 80% In memory  Extended mem. Full
 Detail analysis using Mode List
 Sigle users with high extended mem  particular report analysis
 Ztta/roll_first > 1024  ztta/roll_first = 1
 Roll buffer full: Max used > 80% In memory  Increase roll buffer
Hardware Capacity Verification
Hardware Bottlenecks
 Um gargalo causado por hardware no R/3 reflete em um elevado tempo de resposta das
transações
 No sistema operacional este problema se manifestará através de um elevado consumo
de CPU (próximo a 100%), altas taxas de paginação, baixo desempenho da rede ou
ainda por elevados tempos de acesso aos discos.
 A quantidade ideal de CPU idle deverá se situar acima dos 35%. Taxas abaixo de 20%
indicam gargalos de CPU
 Índices de paginação (ST06  double click Paged in [Kb/h]) por hora acima de 20% da
memória RAM indicam problemas de memória.
Analysis Roadmap: Hardware consuption (ST06)
 Operating System Monitor (ST06)
 CPU Idle < 20%  CPU contention
 Other servers available  Work process and users redistribution
 Top CPU process (ST06  Detail analysis)
 R/3 process with high CPU  detail analysis using SM50
 DB process wit high CPU  detail analysis using ST04
 External process with high CPU  stop or redistribute
 High paging rate > 20% of RAM per hour memory contention
 File system cache > 10% RAM  reduce file system cache
 Buffers monitor (ST06  Mode list)

 Programs with high memory  detail analysis of transaction
 Contenções de CPU podem ser resolvidas através da distribuição da carga entre os
demais applications, quando possível.
 Processing time > CPU time x 2 geralmente indica problemas gerais de performance
associados a hardware, sendo necessário pesquisar mais fundo a causa do gargalo. A
causa do elevado consumo de CPU pode muito bem estar associado a processos
rodando na máquina que consomem muito ciclo
Optimizing the Configuration

Memory configuration
 Separe para o banco de dados 20% da memória de todos os servers
 Defina os buffers do R/3 entre 200MB e 500MB por instancia
 Em unix cada work process consumirá aproximadamente 11.5 MB (7.5MB no NT)
 Cada usuário logado consumirá de 5 a 10MB de extended memory
 A RAM física deverá ser aproximadamente 2/3 da memória usada. A memória virtual
alocada pode ser visualizada através da ST02  Detail analysis  Storage
 O swap deverá ser de 3 x RAM (no mínimo 2GB)
 Considere nos cálculos o número de usuários ativos e o peso dos aplicativos que serão
utilizados
CPU configuration
 Utilize para o banco de dados de 10 a 30% da CPU de todos os servers. Garanta que
nunca haja gargalos no servidor de banco de dados
 Utilize de 10 a 20% do total de CPU para o processamento dos updates
 A demanda dos application servers dependerá do perfil dos usuários/aplicativos
utilizados
Expensive SQL Statements
Consequences of Expensive SQL Statements

 Comandos caros de SQL podem aumentar o database time das transações afetando o
tempo de resposta de todo o sistema
 Estes comandos provocam elevadas taxas de leitura de data blocks que provocam I/Os
elevados e elevados consumos de CPU

SQL Statements and Monitors to Analyse
 Devemos procurar por programas com elevados database times e posteriormente por
SQLs com altos valores de buffer gets
 As transações utilizadas nestas análises serão: ST03, SM50/SM66, ST04, ST05 e SE12
 Como visto anteriormente, através da ST03  Transaction profile, transações com
database time superiores a 40% do response time – wait time deverão ser analisados
com enfoque para os acessos ao banco de dados:
Analysis Roadmap using transaction profile (ST03  Transaction profile)
 SQL trace (ST05)
 Detail analysis of SQL statement
 Através da SM50 também é possível efetuar análise de programas com elevados tempos
de resposta
Analysis Roadmap using work process overview (SM50 ou SM66)
 Database Lock Monitor (DB01)
 Wait due database locks  Analyse lock holder
 Database Process Monitor (ST04  Oracle session)
 Look for SQL statements and identify the transaction
 SQL Trace (ST05)
 Identify and analyse specific SQL statement
 Comandos caros também podem ser identificados através da monitoração dos buffer
gets (ST04  Detail analysis  SQL statement) e procure por comandos com elevadas
taxas de buffer gets
Detail Analysis and Tuning

 Comandos expensives de SQL sempre efetuam elevados volumes de buffer gets duarnte
a sua execução. Dependendo do resultado obtido, podem ser classificados em dois
tipos: aqueles que trazem um alto volume de linhas selecionadas (tipo 1) e aqueles que
trazem poucas linhas como resultado (tipo 2)
 Os comandos tipo 1 normalmente indicam programas ABAP mal escritos, devendo ser
reanalisados
 Os comandos tipo 2 são resultado de estratégias ineficientes de acesso ao banco de
dados, seja pela ausência de índices ou pela ausência de estatísticas atualizadas.
Comandos SQL complexos podem ser eventualmente reescritos

 Através de um explain no comando SQL podemos decidir pela criação de um novo
índice secundário. Ao criar índices posicione os campos mais seletivos no início do
índice e não especifique mais do que 5 campos. Evite definir mais do que 5 índices por
tabela, principalmente naquelas que sofrem muita atualização, como é o caso das
tabelas que armazenam dados transacionais


Workload Analysis
 Uma análise geral pode indicar se existem problemas de performance gerais na instalação:
 Wait time deverá ser < 10% response time
 Main menu deverá estar < 100 ms
 Através da ST03, alguns valores indicam boa performance:

 Average roll in time < 20 ms
 Average roll out time < 20 ms
 Average load time < 10% response time e sempre inferior a 50 ms
 Average database time < 40% do (response time – wait time)
 Average CPU time < 40% do (response time – wait time)
 Average CPU time não pode ser muito inferior ao processing time
Road Maps Summary

 Database Lock Monitor (DB01)
 Wait due database locks  Analyse lock holder
 Database Process Monitor (ST04  Oracle session)
 Look for SQL statements and identify the transaction
 SQL Trace (ST05)
 Identify and analyse specific SQL statement
 Load Report  mem. config. analysis (small buffer)
 Roll in/out  mem. Config. analysis (extended mem. & roll buffer)
 WP in status stopped  Heap area allocation: analyse reason
 PRIV  mem. Config. analysis (extended mem. & roll buffer)
 CPIC  CPIC connection problem
Analysis Roadmap using workload monitor (ST03)

 Wait time > 10% response time  general performance problem
 SQL trace (ST05)
 Detail analysis of SQL statement
 Processing time > CPU time x 2  detail hardware bottleneck analysis
 Load time > 50 ms  mem. config. analysis (small buffer)
 Roll time > 20 ms  mem. Config. analysis (extended mem. & roll buffer)
 CPU time > 40% (response time – wait time)  detail ABAP analysis
Analysis Roadmap: R/3 Memory Configuration (ST02)

 Buffer Monitor (ST02)
 Many swaps  increase buffer size
 Extended memory: Max used > 80% In memory  Extended mem. Full
 Detail analysis using Mode List
 Sigle users with high extended mem  particular report analysis
 Ztta/roll_first > 1024  ztta/roll_first = 1

 Roll buffer full: Max used > 80% In memory  Increase roll buffer
Analysis Roadmap: Hardware consuption (ST06)

 Operating System Monitor (ST06)
 CPU Idle < 20%  CPU contention
 Top CPU process (ST06  Detail analysis)
 R/3 process with high CPU  detail analysis using SM50
 DB process wit high CPU  detail analysis using ST04
 External process with high CPU  stop or redistribute
 High paging rate > 20% of RAM per hour memory contention
 File system cache > 10% RAM  reduce file system cache
 Buffers monitor (ST06  Mode list)
 Programs with high memory  detail analysis of transaction


Basis - 5

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Basis - 5

Uploaded by

Copyright:

Available Formats

Academia Basis

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 1

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 2

R/3 SPOOL AND PRINT 6

Spool and Output Requests 6

Spool Work Processes 6

Local and Remote Printing 7

Logical Spool Servers 8

Spool Request Management 8

R/3 OUTPUT MANAGEMENT 8

External Output Management Systems (OMS) 9

Spool Server and Requests Management 9

Message Control and EDI 11

INTRODUCTION TO WORKLOAD ANALYSIS 11

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 3

PERFORMANCE ANALYSIS MONITORS 14

Operating System Monitor 14

R/3 MEMORY MANAGEMENT 15

Allocation Sequence for Dialog Work Processes 17

Heap Memory Management 17

R/3 Extended Memory 17

HARDWARE CAPACITY VERIFICATION 18

Optimizing the Configuration 19

EXPENSIVE SQL STATEMENTS 19

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 4

SQL Statements and Monitors to Analyse 20

Detail Analysis and Tuning 20

ROAD MAPS SUMMARY 22

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 5

R/3 Spool System

Spool and Output Requests

Spool Work Processes

Local and Remote Printing

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 7

Logical Spool Servers

Spool Request Management

R/3 Output Management

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 8

External Output Management Systems (OMS)

Spool Server and Requests Management

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 9

Message Control and EDI

Introduction to Workload Analysis

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 11

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 12

 Através da ST03, alguns valores indicam boa performance:

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 13

Performance Analysis Monitors

Work Process Overview

Operating System Monitor

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 14

R/3 Memory Management

R/3 Memory Areas

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 15

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 16

Heap Memory Management

R/3 Extended Memory

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 17

Hardware Capacity Verification

Academia Basis – Semana 5 - 21/02 a 25/02/2000 Pag. 18

Optimizing the Configuration

Expensive SQL Statements

Consequences of Expensive SQL Statements