Este tutorial aborda alguns aspectos menos bem compreendidos desempenho de Adabas no mainframe. O processo buffer flush do Adabas é, de vez em quando, necessita de gravar os blocos modificados (RABN) de volta para a banco de dados para um certo número de razões. Leia este tutorial para entender como o processo buffer flush trabalha com o Adabas.
Este é o primeiro artigo de uma série de artigos sobre alguns aspectos de desempenho menos bem compreendidos da Adabas no mainframe. Vamos começar por olhar para o desempenho de gravação do núcleo Adabas para ASSO e DATA.
Por motivos de desempenho, os bancos de dados modernos tentam desacoplar o processamento as transações de atualização da necessidade de gravar as alterações do banco de dados no disco.
No momento em que Adabas chama como updates, inserts ou deletes são executadas, as atuais alterações reais para o banco de dados não são gravados no disco, nem são quando a transação de usuário dá uma transação de commits. Se eles foram gravados no disco, essas chamadas Adabas levariam muito mais tempo para processar. Em vez da proteger os dados na gravação para o PLOG e da Work, o que permite Adabas, durante a reinicialização de uma falha (de energia ou outra), para reconstruir as transações de committed.
No entanto, ao longo do tempo, o Adabas necessita gravar os blocos modificados (RABN) de volta para a banco de dados para um certo número de razões. Este é um processo chamado de buffer flush (BF).
Quando um BF é desencadedo, todos RABN modificados são copiados em um flush I/O pool (FIOP). Isto em memória o processo de cópia é rápida e ininterrupto. O RABN modificado no buffer pool não pode ser substituído até que uma cópia seja criada pelo processo de BF na FIOP. Caso contrário, a atualização seria perdido. Para garantir isso para cada RABN no buffer pool, há uma flag de gravação no cabeçalho RABN, que é ativado quando a primeira mudança a um RABN ocorre. A flag é reajustado somente quando o processo BF copia o RABN na FIOP. Esta flag é inspecionada sempre que um RABN candidato É pesquisado em uma base menos utilizado recentemente para ser substituído para dar lugar a RABN diferente exigido pela chamada do Adabas. Quanto mais RABN existem em uma area do buffer pool, o que não pode ser substituído, o menos eficiente usa o algoritmo menos recentemente usada chega a encontrar um RABN adequado para ser substituído por um novo RABN.
A partir do FIOP o RABN são gravados no disco. Esta segunda etapa demora muito mais tempo, uma vez que envolve I/O. Uma vez que esta gravação envolve I/O, o buffer flush está concluída.
Através do processo acima, um BF irá gravar todos RABN, que foram modificados entre o início deste BF e a anterior. Durante o reinício do núcleo irá identificar quando o último BF foi concluída antes da falha ter ocorrido e, consequentemente, todas as atualizações, que completou antes do início do que BF, já deve ter sido armazenado no disco em sua totalidade. (Um update, delete, insert normalmente modifica mais de um bloco). Isso limita a quantidade de trabalho que Adabas tem a ver se ele precisa para se recuperar de falha. Não é, evidente, mais para o processo de recuperação, mas este não é o assunto deste artigo.
Existem três principais causas que desencadeiam um BF:
1 - A maioria de comandos checkpoint são gatilhos BF antes do status alterado de um banco de dados for confirmada. Por exemplo, quando um comando do operador define um banco de dados em modo de somente leitura, as atualizações são parado, um BF é desencadeado e, em seguida, um checkpoint é gravada no arquivo checkpoint.
2 - O núcleo devera sempre assegurar que há, pelo menos, dois buffer flush completos na área de proteção (área LP) da Work. Como já observado, o buffer flush completos sobre o Work são essenciais para o processo de recuperação. Se a área de LP é pequena em relação ao processamento de update esta pode ser um gatinho para o buffer flush.
3 - O núcleo mantém um contador do número de RABN na buffer pool que tem a sua flag de gravação atualmente ligado. Sempre que uma flag de um RABN está ligado, o núcleo compara o tamanho da FIOP com este número multiplicado pela maior tamanho de bloco para utilização em ASSO e DATA. Se o FIOP enche, a BF é desencadeado.
Quando os blocos são gravados em disco durante um BF, este é essencialmente um processo assíncrono. Em um ambiente Adabas bem afinado, as chamadas Adabas não aguardar a conclusão da gravação I/O do RABN no ASSO e nem no DATA. Isso é diferente do I/O em RABN em leituras. Uma vez que os dados no RABN é exigido por uma chamada Adabas e esta chamada não pode prosseguir até que a RABN é trazido para o buffer pool.
\ No entanto, há boas razões para se preocupar com esses I/O de gravação. Estes I/O gravação competem pelos mesmos E/S de recursos como I/O de leitura. Eles poderiam impactar a duração do I/O de leitura, o que afeta o desempenho das chamadas Adabas.
\ I/O de gravação para ASSO e DATA hoje muitas vezes são muito menores em números do que I/O de leitura. No entanto, a memória real em mainframes e "virtual 64" significa que os dados, em breve residem em cache spades com tamanhos medidos em gigabytes em vez de megabytes. I/O de leitura acabará por vir para baixo, enquanto RABN modificado ainda precisa ser gravado no disco.
\ Alterações ao banco de dados podem limitar a taxa de throughput e o BF não ser capaz de lidar com o update ratio. Isso ocorre se flags de gravação são ativadas mais rápido do que RABN podem ser gravados em disco redefinam a gravação das flags. Neste caso, o buffer pool iria se encher com blocos modificados.
\ O objetivo de desempenho de o buffer flush, em ordem de importância é:
(*) Atualização maximizar o throughput.
(*) Minimizar os atrasos no processamento de comando, enquanto a BF está em andamento.
(*) Minimizar a duração de um BF.
Em certa medida, estes objectivos estão em conflito um com o outro. Por exemplo, quanto mais rápido um buffer flush procede, o mais I/O write devem ser executados por segundo. Mais throughput geral de atualização podem melhorar, mas à espera de comandos I/O read podem demorar mais quando estes read E/S estão atrasadas. Este será mais provável ocorrer com versões mais antigas do Adabas.
\ Se os valores do parâmetro ADARUN default (LFIOP, FMXIO) estão em uso, a configuração atual irá minimizar o impacto de um BF no processamento de comando simultâneo. O pressuposto é que a taxa de transferência de atualização atual é satisfatória. Este tende a ser um bom compromisso para a maioria dos sites de maior parte do tempo e funciona bem, desde que o buffer flush termina antes do próximo devem ser iniciado.
\ Como se pode detectar que os comandos são atrasados devido às buffer flush processamento e como pode o processo buffer flush ser afinado?
\ Na versão 7.4 do Adabas, novas estatísticas de encerramento relacionados com a BF foram dadas.
\ A estatística encerramento agora não só registros,
(*) O número de buffer flush por sessão;
Mas também:
(*) O número de flush phases;
(*) O número de blocks flushed;
(*) O número de Flush I/Os;
Como notado acima, um BF irá gravar todos os RABN, que tenham sido modificados entre o começo do buffer flush anterior e esta. Se tudo RABN não se encaixam no FIOP, o buffer flush será feito em fases. O RABN são copiados para a FIOP, gravado para o disco e, em seguida, se RABN permanecer, a próxima fase começa com RABN sendo copiado e gravado para fora até que todos RABN modificado ter sido gravado fora. Surge a pergunta, como é possível que um BF tem mais de uma fase, se um buffer flush é desencadeado sempre que houver RABN suficiente para encher o FIOP?
A resposta é que a BF é desencadeado, mas só pode começar se o buffer flush anterior foi concluída. Caso contrário, o começo do buffer flush fica adiada até que a BF anterior estiver concluído. Neste caso, mais RABN podem existir do que se encaixam na FIOP e o próximo BF terá mais de uma flush phase. Isso é chamado de BF overrun.
Comparando o número de BF com o número de flush phase que pode ser visto se o número de flush phase excedam o número de BF por uma quantidade significativa.
Se a resposta for sim, ocorre BF overruns e o BF precisa ser ajustada.
BF pode ser sintonizado, tornando-os mais rápidos e/ou menos freqüentes.
Uma regra boa de ouro é que BF deve, em média, não ocorre mais de uma vez por minuto. Desde a estatística de desligamento registra o tempo da sessão e o número de BF isso é fácil de calcular. Se BF ocorrer com mais freqüência, pode ter de ser aumentada:
(*) FIOP (LFIOP): Se o FIOP é aumentada, pode ser exigido um aumento correspondente do buffer pool (LBP). Por padrão, o tamanho do núcleo da FIOP é um quarto do tamanho do buffer pool. O tamanho médio para o buffer pool este é muitas vezes um bom valor, mas pode ser realmente muito grande para grandes buffer pool e para sites com atualizações pesados, pode ser muito pequeno. Por exemplo, quando updates de um banco de dados são novamente aplicada por meio do utilitário ADARES Regenerate, recomenda-se usar FIOP em excesso de 50% a mais do tamanho do buffer pool.
(*) A área de proteção de Work (LP): A redução da frequência BF tem um efeito geral benéfico, porque RABN modificado será em média de permanência mais longa na área de buffer. Isso aumenta as chances de que mais atualizações para o mesmo RABN modificado ocorrão antes do RABN é write para fora, reduzindo o número total de gravação I/Os. A eficiência de gravação em relação ao número de atualizações melhora. Note-se que a eficiência do buffer nas estatísticas de shutdown se relaciona com a eficiência de read I/Os não para write I/Os.
Para fazer a BF mais rápido é mais difícil e uma vez que a duração de um buffer flush é determinado pelo tempo que ele necessita para fazer a write I/Os, este tende a exigir I/O tuning.
\ Um hardware moderno o write I/O são geralmente gravado em um cache I/O de um subsistema de I/O chamado de armazenamento não volátil (Non Volatile Storage - NVS). Isto significa que I/Os Write tendem a ser rápido (estes I/Os são chamados DASD FAST WRITE) uma vez que os atrasos mecânicas associadas com gravações em discos não estão diretamente envolvidos. Por padrão, o processo BF começará a gravação simultânea I/Os, um para cada volume ADABAS, para as modificações que existem no RABN que existam na FIOP. Uma vez que uma I/O write para um volume foi concluída, a próxima I/O write para o mesmo volume é iniciado independente de qualquer outro I/Os write em andamento enquanto existir RABN modificado para um volume. Para acelerar este processo ainda mais, os RABN consecutivos são combinados em um único I/O. (RABN são sempre ordenados em sequência no FIOP). O número de gravação paralela I/Os é, portanto, dependente de que os arquivos de um banco de dados, a que a maioria das atualizações ocorrem, estão distribuídos por um número suficiente de volumes.
\ Quando a BF não pode lidar, pode haver uma série de razões. As atualizações não são distribuídos por um número suficiente de volumes ou a NVS de I/O do cache pode não ser capaz de lidar com o número de I/Os. Se o NVS fica cheia, I/Os write irá ignorar o cache e write do I/Os de ir diretamente para o disco, um processo muito mais lento.
\ Para evitar isso, I / sistema O blocos de gravação de NVS de forma assíncrona para o disco, mas este processo é não necessariamente mais rápido do que escrever I / Os que chegam com novo RABN em NVS. Neste caso, o banco de dados pode ter de ser distribuídos por mais de um subsistema de I/O para lidar com a carga.
\ Parallel Access Volumes (PAV) permitir que mais de um I/O por volume e o parâmetro ADARUN FMXIO permite instruir o processo BF para iniciar mais de um gravação I/O por volume. Isto pode ser utilizado para acelerar o processo de BF. No entanto, este deve ser julgado apenas como um último recurso, uma vez que read de I/Os pode agora sofrer. Com efeito FMXIO muda a prioridade entre o I/Os do read e do write para a maioria dos sites é melhor dar preferência a o I/Os read. Para a maioria dos sites FMXIO deve ser deixado em seu valor padrão de um. Se FMXIO é aumentada deve ser feito por etapas de um, não mais, e depois avaliado quanto ao seu efeito. O número de simultâneos I/Os, o que pode ser feito a partir de um único espaço de endereço é limitado (um pouco menos de 500) ou um abend devera ocorrer. O processo BF garante que esse limite não será ultrapassado, o que também pode colocar um limite para FMXIO.
\ O shutdown das estatística do Adabas dá o número de comandos que solicitaram a BF e categoriza-os de acordo com:
(*) Return immediately;
(*) Return after logical flush;
(*) Return after entire flush;
A categoria "Return immediately" são o número de comandos que desencadearam um buffer flush, mas continuou sem esperar. Este número não é muito importante do ponto de vista do desempenho.
A categoria "Return after entire flush" são comandos que desencadearam uma BF e teve que aguardar a conclusão do BF que foi desencadeado. Normalmente, estes são BF desencadeada por eventos para comandos de checkpoint.
A categoria "Return after logical flush" são o número de comandos que aguardavam a conclusão de um flush phase e este número deve ser sempre zero.
Este evento ocorre se um comando requer um RABN que não esta na área de buffer, mas o gerente de buffer pool não pode encontrar um RABN para substituir, porque todos RABN na área de buffer tem o seu flag de gravação ligada. Neste caso, um buffer flush já estarão em andamento, porque há RABN mais modificado do que se encaixam na FIOP. Todos os comandos, que exigem uma RABN que não estão na buffer pool não podem prosseguir e são suspensos até que a atual flush phase tenha terminado e, posteriormente, RABN são copiados para a FIOP e sua redefinição da gravação da flag. Se isso acontecer, que não modificados RABN estão na buffer pool, a degradação grave ocorrerá e o núcleo atingiu seu limite de atualização.
Original - Clique Aqui
Este é o primeiro artigo de uma série de artigos sobre alguns aspectos de desempenho menos bem compreendidos da Adabas no mainframe. Vamos começar por olhar para o desempenho de gravação do núcleo Adabas para ASSO e DATA.
Por motivos de desempenho, os bancos de dados modernos tentam desacoplar o processamento as transações de atualização da necessidade de gravar as alterações do banco de dados no disco.
No momento em que Adabas chama como updates, inserts ou deletes são executadas, as atuais alterações reais para o banco de dados não são gravados no disco, nem são quando a transação de usuário dá uma transação de commits. Se eles foram gravados no disco, essas chamadas Adabas levariam muito mais tempo para processar. Em vez da proteger os dados na gravação para o PLOG e da Work, o que permite Adabas, durante a reinicialização de uma falha (de energia ou outra), para reconstruir as transações de committed.
No entanto, ao longo do tempo, o Adabas necessita gravar os blocos modificados (RABN) de volta para a banco de dados para um certo número de razões. Este é um processo chamado de buffer flush (BF).
Quando um BF é desencadedo, todos RABN modificados são copiados em um flush I/O pool (FIOP). Isto em memória o processo de cópia é rápida e ininterrupto. O RABN modificado no buffer pool não pode ser substituído até que uma cópia seja criada pelo processo de BF na FIOP. Caso contrário, a atualização seria perdido. Para garantir isso para cada RABN no buffer pool, há uma flag de gravação no cabeçalho RABN, que é ativado quando a primeira mudança a um RABN ocorre. A flag é reajustado somente quando o processo BF copia o RABN na FIOP. Esta flag é inspecionada sempre que um RABN candidato É pesquisado em uma base menos utilizado recentemente para ser substituído para dar lugar a RABN diferente exigido pela chamada do Adabas. Quanto mais RABN existem em uma area do buffer pool, o que não pode ser substituído, o menos eficiente usa o algoritmo menos recentemente usada chega a encontrar um RABN adequado para ser substituído por um novo RABN.
A partir do FIOP o RABN são gravados no disco. Esta segunda etapa demora muito mais tempo, uma vez que envolve I/O. Uma vez que esta gravação envolve I/O, o buffer flush está concluída.
Através do processo acima, um BF irá gravar todos RABN, que foram modificados entre o início deste BF e a anterior. Durante o reinício do núcleo irá identificar quando o último BF foi concluída antes da falha ter ocorrido e, consequentemente, todas as atualizações, que completou antes do início do que BF, já deve ter sido armazenado no disco em sua totalidade. (Um update, delete, insert normalmente modifica mais de um bloco). Isso limita a quantidade de trabalho que Adabas tem a ver se ele precisa para se recuperar de falha. Não é, evidente, mais para o processo de recuperação, mas este não é o assunto deste artigo.
Existem três principais causas que desencadeiam um BF:
1 - A maioria de comandos checkpoint são gatilhos BF antes do status alterado de um banco de dados for confirmada. Por exemplo, quando um comando do operador define um banco de dados em modo de somente leitura, as atualizações são parado, um BF é desencadeado e, em seguida, um checkpoint é gravada no arquivo checkpoint.
2 - O núcleo devera sempre assegurar que há, pelo menos, dois buffer flush completos na área de proteção (área LP) da Work. Como já observado, o buffer flush completos sobre o Work são essenciais para o processo de recuperação. Se a área de LP é pequena em relação ao processamento de update esta pode ser um gatinho para o buffer flush.
3 - O núcleo mantém um contador do número de RABN na buffer pool que tem a sua flag de gravação atualmente ligado. Sempre que uma flag de um RABN está ligado, o núcleo compara o tamanho da FIOP com este número multiplicado pela maior tamanho de bloco para utilização em ASSO e DATA. Se o FIOP enche, a BF é desencadeado.
Quando os blocos são gravados em disco durante um BF, este é essencialmente um processo assíncrono. Em um ambiente Adabas bem afinado, as chamadas Adabas não aguardar a conclusão da gravação I/O do RABN no ASSO e nem no DATA. Isso é diferente do I/O em RABN em leituras. Uma vez que os dados no RABN é exigido por uma chamada Adabas e esta chamada não pode prosseguir até que a RABN é trazido para o buffer pool.
\ No entanto, há boas razões para se preocupar com esses I/O de gravação. Estes I/O gravação competem pelos mesmos E/S de recursos como I/O de leitura. Eles poderiam impactar a duração do I/O de leitura, o que afeta o desempenho das chamadas Adabas.
\ I/O de gravação para ASSO e DATA hoje muitas vezes são muito menores em números do que I/O de leitura. No entanto, a memória real em mainframes e "virtual 64" significa que os dados, em breve residem em cache spades com tamanhos medidos em gigabytes em vez de megabytes. I/O de leitura acabará por vir para baixo, enquanto RABN modificado ainda precisa ser gravado no disco.
\ Alterações ao banco de dados podem limitar a taxa de throughput e o BF não ser capaz de lidar com o update ratio. Isso ocorre se flags de gravação são ativadas mais rápido do que RABN podem ser gravados em disco redefinam a gravação das flags. Neste caso, o buffer pool iria se encher com blocos modificados.
\ O objetivo de desempenho de o buffer flush, em ordem de importância é:
(*) Atualização maximizar o throughput.
(*) Minimizar os atrasos no processamento de comando, enquanto a BF está em andamento.
(*) Minimizar a duração de um BF.
Em certa medida, estes objectivos estão em conflito um com o outro. Por exemplo, quanto mais rápido um buffer flush procede, o mais I/O write devem ser executados por segundo. Mais throughput geral de atualização podem melhorar, mas à espera de comandos I/O read podem demorar mais quando estes read E/S estão atrasadas. Este será mais provável ocorrer com versões mais antigas do Adabas.
\ Se os valores do parâmetro ADARUN default (LFIOP, FMXIO) estão em uso, a configuração atual irá minimizar o impacto de um BF no processamento de comando simultâneo. O pressuposto é que a taxa de transferência de atualização atual é satisfatória. Este tende a ser um bom compromisso para a maioria dos sites de maior parte do tempo e funciona bem, desde que o buffer flush termina antes do próximo devem ser iniciado.
\ Como se pode detectar que os comandos são atrasados devido às buffer flush processamento e como pode o processo buffer flush ser afinado?
\ Na versão 7.4 do Adabas, novas estatísticas de encerramento relacionados com a BF foram dadas.
\ A estatística encerramento agora não só registros,
(*) O número de buffer flush por sessão;
Mas também:
(*) O número de flush phases;
(*) O número de blocks flushed;
(*) O número de Flush I/Os;
Como notado acima, um BF irá gravar todos os RABN, que tenham sido modificados entre o começo do buffer flush anterior e esta. Se tudo RABN não se encaixam no FIOP, o buffer flush será feito em fases. O RABN são copiados para a FIOP, gravado para o disco e, em seguida, se RABN permanecer, a próxima fase começa com RABN sendo copiado e gravado para fora até que todos RABN modificado ter sido gravado fora. Surge a pergunta, como é possível que um BF tem mais de uma fase, se um buffer flush é desencadeado sempre que houver RABN suficiente para encher o FIOP?
A resposta é que a BF é desencadeado, mas só pode começar se o buffer flush anterior foi concluída. Caso contrário, o começo do buffer flush fica adiada até que a BF anterior estiver concluído. Neste caso, mais RABN podem existir do que se encaixam na FIOP e o próximo BF terá mais de uma flush phase. Isso é chamado de BF overrun.
Comparando o número de BF com o número de flush phase que pode ser visto se o número de flush phase excedam o número de BF por uma quantidade significativa.
Se a resposta for sim, ocorre BF overruns e o BF precisa ser ajustada.
BF pode ser sintonizado, tornando-os mais rápidos e/ou menos freqüentes.
Uma regra boa de ouro é que BF deve, em média, não ocorre mais de uma vez por minuto. Desde a estatística de desligamento registra o tempo da sessão e o número de BF isso é fácil de calcular. Se BF ocorrer com mais freqüência, pode ter de ser aumentada:
(*) FIOP (LFIOP): Se o FIOP é aumentada, pode ser exigido um aumento correspondente do buffer pool (LBP). Por padrão, o tamanho do núcleo da FIOP é um quarto do tamanho do buffer pool. O tamanho médio para o buffer pool este é muitas vezes um bom valor, mas pode ser realmente muito grande para grandes buffer pool e para sites com atualizações pesados, pode ser muito pequeno. Por exemplo, quando updates de um banco de dados são novamente aplicada por meio do utilitário ADARES Regenerate, recomenda-se usar FIOP em excesso de 50% a mais do tamanho do buffer pool.
(*) A área de proteção de Work (LP): A redução da frequência BF tem um efeito geral benéfico, porque RABN modificado será em média de permanência mais longa na área de buffer. Isso aumenta as chances de que mais atualizações para o mesmo RABN modificado ocorrão antes do RABN é write para fora, reduzindo o número total de gravação I/Os. A eficiência de gravação em relação ao número de atualizações melhora. Note-se que a eficiência do buffer nas estatísticas de shutdown se relaciona com a eficiência de read I/Os não para write I/Os.
Para fazer a BF mais rápido é mais difícil e uma vez que a duração de um buffer flush é determinado pelo tempo que ele necessita para fazer a write I/Os, este tende a exigir I/O tuning.
\ Um hardware moderno o write I/O são geralmente gravado em um cache I/O de um subsistema de I/O chamado de armazenamento não volátil (Non Volatile Storage - NVS). Isto significa que I/Os Write tendem a ser rápido (estes I/Os são chamados DASD FAST WRITE) uma vez que os atrasos mecânicas associadas com gravações em discos não estão diretamente envolvidos. Por padrão, o processo BF começará a gravação simultânea I/Os, um para cada volume ADABAS, para as modificações que existem no RABN que existam na FIOP. Uma vez que uma I/O write para um volume foi concluída, a próxima I/O write para o mesmo volume é iniciado independente de qualquer outro I/Os write em andamento enquanto existir RABN modificado para um volume. Para acelerar este processo ainda mais, os RABN consecutivos são combinados em um único I/O. (RABN são sempre ordenados em sequência no FIOP). O número de gravação paralela I/Os é, portanto, dependente de que os arquivos de um banco de dados, a que a maioria das atualizações ocorrem, estão distribuídos por um número suficiente de volumes.
\ Quando a BF não pode lidar, pode haver uma série de razões. As atualizações não são distribuídos por um número suficiente de volumes ou a NVS de I/O do cache pode não ser capaz de lidar com o número de I/Os. Se o NVS fica cheia, I/Os write irá ignorar o cache e write do I/Os de ir diretamente para o disco, um processo muito mais lento.
\ Para evitar isso, I / sistema O blocos de gravação de NVS de forma assíncrona para o disco, mas este processo é não necessariamente mais rápido do que escrever I / Os que chegam com novo RABN em NVS. Neste caso, o banco de dados pode ter de ser distribuídos por mais de um subsistema de I/O para lidar com a carga.
\ Parallel Access Volumes (PAV) permitir que mais de um I/O por volume e o parâmetro ADARUN FMXIO permite instruir o processo BF para iniciar mais de um gravação I/O por volume. Isto pode ser utilizado para acelerar o processo de BF. No entanto, este deve ser julgado apenas como um último recurso, uma vez que read de I/Os pode agora sofrer. Com efeito FMXIO muda a prioridade entre o I/Os do read e do write para a maioria dos sites é melhor dar preferência a o I/Os read. Para a maioria dos sites FMXIO deve ser deixado em seu valor padrão de um. Se FMXIO é aumentada deve ser feito por etapas de um, não mais, e depois avaliado quanto ao seu efeito. O número de simultâneos I/Os, o que pode ser feito a partir de um único espaço de endereço é limitado (um pouco menos de 500) ou um abend devera ocorrer. O processo BF garante que esse limite não será ultrapassado, o que também pode colocar um limite para FMXIO.
\ O shutdown das estatística do Adabas dá o número de comandos que solicitaram a BF e categoriza-os de acordo com:
(*) Return immediately;
(*) Return after logical flush;
(*) Return after entire flush;
A categoria "Return immediately" são o número de comandos que desencadearam um buffer flush, mas continuou sem esperar. Este número não é muito importante do ponto de vista do desempenho.
A categoria "Return after entire flush" são comandos que desencadearam uma BF e teve que aguardar a conclusão do BF que foi desencadeado. Normalmente, estes são BF desencadeada por eventos para comandos de checkpoint.
A categoria "Return after logical flush" são o número de comandos que aguardavam a conclusão de um flush phase e este número deve ser sempre zero.
Este evento ocorre se um comando requer um RABN que não esta na área de buffer, mas o gerente de buffer pool não pode encontrar um RABN para substituir, porque todos RABN na área de buffer tem o seu flag de gravação ligada. Neste caso, um buffer flush já estarão em andamento, porque há RABN mais modificado do que se encaixam na FIOP. Todos os comandos, que exigem uma RABN que não estão na buffer pool não podem prosseguir e são suspensos até que a atual flush phase tenha terminado e, posteriormente, RABN são copiados para a FIOP e sua redefinição da gravação da flag. Se isso acontecer, que não modificados RABN estão na buffer pool, a degradação grave ocorrerá e o núcleo atingiu seu limite de atualização.
Original - Clique Aqui
0 comentários:
Enviar um comentário