Compreendendo falhas e ausências de buffer
Contents
Introduction
Este documento discute ausências e falhas do buffer no Processador de Roteamento (RP).
Prerequisites
Requirements
Não existem requisitos específicos para este documento.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Falhas e falhas de buffer
O RP divide sua memória de processador em pools. Cada conjunto contém um número de blocos de memória do mesmo tamanho. Esses blocos de memória são chamados de buffers.
Pools de buffer
Há seis pools de buffer:
-
Pequeno—buffers de 104 bytes
-
Meio—buffers de 600 bytes
-
Grande—buffers de 1.524 bytes
-
Muito grande—buffers de 4.520 bytes
-
Grande—buffers de 5024 bytes
-
Enorme—buffers de 18024 bytes
Por exemplo, se um processador de interface precisa passar um pacote de 20 bytes para o RP, ele "pede" um buffer pequeno. Se um processador de interface precisa passar um pacote de 500 bytes para o RP, ele pede um buffer do meio e assim por diante.
Observação: o processador de interface deve solicitar um buffer de um determinado tamanho.
Quando o processador de interface solicita um buffer, isso ocorre:
-
Se existir um buffer livre no conjunto solicitado, ele será concedido. Caso contrário, a solicitação gera um "erro" e o algoritmo de buffer tenta "criar" mais buffers para esse pool .
-
Quando o IOS não consegue obter um buffer pequeno, ele não descarta o pacote. Ele incrementa o contador com falha e passa para o buffer de nível seguinte, que é o buffer do meio e solicita um buffer lá. Se ele não conseguir um buffer intermediário, ele solicitará o buffer de nível seguinte, que é um buffer grande. Esse processo continua até que atinja o pool de buffers Imensos. Se ele não conseguir obter um buffer grande, ele descartará o pacote.
-
Quando você usa o conjunto de recursos IBM, uma falha quase sempre gera uma falha.
-
Embora os recursos IBM possam ser comutados por processo, o código para obter um buffer para passar um pacote de uma interface para o RP é executado no nível de interrupção.
-
Os buffers não podem ser criados no nível de interrupção; consequentemente, uma falha enfileira sua solicitação de mais buffers para o RP.
-
Como um buffer adicional não pode ser criado no local, a solicitação de buffer falha e o pacote é descartado.
As falhas de buffer são um dos motivos mais comuns para cancelamento de pacotes. Quando as quedas de pacote ocorrem devido a uma falha de buffer, isso ocorre:
-
Após uma falha de buffer, o RP tem uma solicitação pendente para criar mais buffers do tamanho apropriado para o pool específico.
-
Enquanto o RP está atendendo à solicitação de criação de buffers, pode haver falhas adicionais no pool.
-
O RP pode até mesmo não criar mais buffers, devido às restrições de memória no sistema quando os buffers extras são necessários.
-
Essencialmente, a operação de criação de buffers pode levar vários microssegundos, em que os pacotes são continuamente descartados devido à falta de buffer.
-
Além disso, se os buffers forem usados tão rápido quanto são criados, o RP poderá ser forçado a gastar mais tempo na criação do buffer do que no processamento de pacotes.
-
Isso pode fazer com que o RP comece a descartar pacotes tão rapidamente que o desempenho degrada e as sessões são perdidas.
Felizmente, conforme discutido nesse documento, os problemas de falhas de buffer não são difíceis de identificar e resolver. Esta saída do comando show buffers mostra o estado atual dos pools de buffer do roteador:
dspu-7k#show buffers
Buffer elements:
500 in free list (500 max allowed)
2370 hits, 0 misses, 0 created
Public buffer pools:
Small buffers, 104 bytes (total 16, permanent 10):
11 in free list (0 min, 10 max allowed)
1770 hits, 33 misses, 22 trims, 28 created
9 failures (0 no memory)
Middle buffers, 600 bytes (total 90, permanent 90):
89 in free list (10 min, 200 max allowed)
590 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Big buffers, 1524 bytes (total 90, permanent 90):
90 in free list (5 min, 300 max allowed)
126 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 10, permanent 10):
10 in free list (0 min, 300 max allowed)
50 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Large buffers, 5024 bytes (total 10, permanent 10):
10 in free list (0 min, 30 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Huge buffers, 18024 bytes (total 2, permanent 0):
0 in free list (0 min, 13 max allowed)
2 hits, 2 misses, 0 trims, 2 created
0 failures (0 no memory)
Na saída de show buffers:
-
Total identifica o número total de buffers no pool, que incluem buffers usados e não utilizados.
-
Permanente identifica o número permanente de buffers alocados no pool. Esses buffers estão sempre no pool e não podem ser aparados.
-
Na lista de livres, identifica o número de buffers que estão atualmente no conjunto e que estão disponíveis para uso.
-
Min identifica o número mínimo de buffers que o RP deve tentar manter na lista livre:
-
O parâmetro min é usado para antecipar a demanda do conjunto por buffers em qualquer momento especificado.
-
Se o número de buffers na lista livre cair abaixo desse valor mínimo, o RP tentará criar mais buffers desse pool.
-
-
Max-allowed identifica o número máximo de buffers permitidos na lista livre:
-
O parâmetro max-allowed impede que um pool monopolize buffers que ele não precisa mais. Ela também libera essa memória de volta ao sistema para uso posterior.
-
Se o número de buffers na lista livre for maior que o valor máximo permitido, o RP deve tentar aparar buffers do pool.
-
-
O contador Hits identifica o número de buffers que foram solicitados do conjunto. O contador de acertos fornece um mecanismo para determinar qual pool deve atender à maior demanda de buffers.
-
Misses identifica o número de vezes que um buffer foi solicitado e o RP detectado em que buffers adicionais do pool foram necessários. Em outras palavras, o número de buffers na lista livre caiu abaixo do nível mínimo. A contagem de ausências representa o número de vezes que o RP foi forçado a criar buffers adicionais.
-
Trims identifica o número de buffers cortados pelo RP do pool, quando o número de buffers na lista livre excedeu o número de buffers permitidos pelo máximo.
-
O valor Created (Criados) identifica o número de buffers que foram criados no conjunto. O RP cria buffers nestas situações:
-
Quando a demanda por buffers aumenta até que o número de buffers na lista livre seja menor que o min buffers.
-
Uma falha ocorre porque não há buffers na lista livre.
-
Ambas as situações anteriores.
-
-
Falhas identificam quando o IOS falha em obter um buffer pequeno, mas não descarta o pacote. Ele incrementa o contador com falha e passa para o buffer de nível seguinte, que é o buffer do meio e solicita um buffer lá. Se ele não conseguir um buffer intermediário, ele solicitará o buffer de nível seguinte, que é um buffer grande. Esse processo continua até que atinja o pool de buffers Imensos. Se ele não conseguir obter um buffer grande, ele descartará o pacote.
-
No memory identifica o número de falhas causadas por memória insuficiente para criar buffers adicionais.
Você pode examinar as características de cada pool para determinar quais pools (se houver) estão encontrando problemas. Os parâmetros de um pool podem ser ajustados para permitir que o roteador esteja mais bem preparado para lidar com a carga, se o pool parecer exibir estas características:
-
O número de erros e cria incrementos a uma taxa alta (como porcentagem de acertos).
-
Há um número consistentemente baixo de buffers na lista livre.
-
O número de falhas ou nenhum incremento de memória.
comando de configuração de buffers
Com o comando de configuração buffers, você pode ajustar estes parâmetros para cada pool de buffer:
-
inicial — buffers temporários alocados na recarga do sistema.
-
max-free — Número máximo de buffers livres.
-
min-free — Número mínimo de buffers livres.
-
permanente — Número de buffers permanentes.
Buffers Iniciais
Ajuste os buffers iniciais para acomodar o burst do tráfego de estabelecimento de sessões depois da recarga do roteador.
buffers small initial 250
Esses buffers são eventualmente "aparados" e retornados ao sistema.
Os buffers iniciais são projetados para manejar o estabelecimento de sessão, o que é sempre comutado por processo.
Durante o estabelecimento da sessão, o cache de comutação rápida (usado por outros protocolos de rota) é preenchido; os buffers comutados por processo não são mais necessários e podem ser retornados ao sistema.
Ajustar buffers iniciais pode não ser a solução correta para o conjunto de recursos IBM, porque quase todos os pacotes (após o estabelecimento da sessão) são comutados por processo e exigem o buffer adicional mesmo assim.
Observação: para os recursos comutados por processos da IBM, você deve ajustar buffers permanentes em vez de ajustar os buffers iniciais temporários.
Máx. Buffers Livres
Ajuste buffers max-free para que o valor seja igual ou maior que os buffers permanentes. Se todos os buffers permanentes estiverem na lista livre, o RP não deve tentar aparar buffers permanentes. Max-free pode ser usado para garantir que buffers não utilizados que são criados durante bursts irregulares retornem para a memória do sistema.
buffers small max-free 175 buffers small permanent 125
Buffers Min-Free
Ajuste buffers min-free para que o valor represente o número mínimo estimado de buffers necessários a qualquer momento. Min-free pode ser usado para antecipar as condições de falta de buffer e para garantir que um número mínimo de buffers esteja sempre disponível.
buffers small min-free 50
Buffers permanentes
Ajuste buffers permanentes de modo que o valor represente o número estimado de buffers necessários para o processamento normal.
buffers small permanent 125
Buffers permanentes são usados para acomodar os requisitos de buffers normais (incluindo intermitências freqüentes) do roteador. A determinação dos requisitos normais de buffer é um processo interativo, em que a saída show buffer deve mostrar os buffers totais usados em um pool em um determinado momento. Os buffers permanentes deverão ser ajustados em relação ao "total" consistente de buffers necessários. Ao ajustar buffers permanentes, você deve se concentrar na redução de criações e na eliminação de falhas e falhas.
Comandos show adicionais
Há dois outros comandos show que você pode usar para identificar problemas com a alocação de buffer:
-
show interfaces interface-identifier
-
show source-bridge
Esta saída do comando de exemplo de identificador de interface de show interfaces inclui um contador para nenhum buffer:
dspu-7k#show interfaces channel 4/2
Channel4/2 is up, line protocol is up
Hardware is cxBus IBM Channel
MTU 4472 bytes, BW 98304 Kbit, DLY 100 usec, rely 255/255, load 1/255
Encapsulation CHANNEL, loopback not set, keepalive not set
Virtual interface
Last input 0:00:04, output 0:00:04, output hang never
Last clearing of "show interface" counters never
Output queue 0/40, 0 drops; input queue 0/75, 8 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
646 packets input, 27760 bytes, 8 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
328 packets output, 16959 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets, 0 restarts
0 output buffer failures, 0 output buffers swapped out
Na saída do comando show interfaces interface-identifier:
-
O contador sem buffer é incrementado quando a interface falha ao obter um buffer para um pacote de entrada.
-
Os contadores sem buffer e descartes (fila de entrada) aumentam quando a interface não obtém um buffer para um pacote de entrada.
-
Um contador sem buffer que incrementa na saída show interfaces correlaciona-se ao contador de falhas que incrementa na saída do show buffers. O pool de buffer apropriado pode ser ajustado.
Esta saída do comando de exemplo show source-bridge inclui um contador de interface para os aceleradores, quando o Source-Route Bridging (SRB) é configurado para a interface:
dspu-7k#show source-bridge
Local Interfaces: receive transmit
srn bn trn r p s n max hops cnt:bytes cnt:bytes drops
Ch4/2 666 1 99 * f 7 7 7 652:26020 6:266 0
Global RSRB Parameters:
TCP Queue Length maximum: 100
Ring Group 99:
This TCP peer: 150.10.20.2
Maximum output TCP queue length, per peer: 100
Peers: state bg lv pkts_rx pkts_tx expl_gn drops TCP
TCP 150.10.20.1 open *3 261 266 0 0 0
TCP 150.10.20.2 - *3 0 0 0 0 0
Rings:
bn: 1 rn: 888 locvrt ma: 4000.7000.fff1 Buff Ring888 fwd: 0
bn: 1 RN: 666 local ma: 4000.0c48.2e80 Channel4/2 fwd: 261
bn: 1 RN: 88 remote ma: 4000.4000.fff1 TCP 150.10.20.1 fwd: 322
bn: 1 RN: 250 remote ma: 4000.300f.7c09 TCP 150.10.20.1 fwd: 0
Explorers: ------- input ------- ------- output -------
spanning all-rings total spanning all-rings total
Ch4/2 0 0 0 0 1 1
Local: fastswitched 0 flushed 0 max Bps 256000
rings inputs bursts throttles output drops
Ch4/2 0 0 8 0
Na saída do comando show source-bridge.
-
O contador de limitação é incrementado quando a interface falha ao obter um buffer para um pacote de entrada.
-
O contador de aceleração incrementado na saída do comando show interfaces correlaciona-se a um contador de falhas que incrementa a saída do comando show buffers. O pool de buffer apropriado pode ser ajustado.
Feedback