Configurar Otimizações Adicionais para Clusters Esticados FMW
Embora nem todos sejam obrigatórios para essa topologia, eles melhoram o desempenho e o comportamento de determinados recursos e cenários.
Configurar Timeouts no Oracle WebLogic Server (WLS)
Há limites de timeout especificados para transações no banco de dados, para ramificações de transação, invocações do método Enterprise JavaBean (EJB), web services etc. As implantações de cluster estendidas do Oracle Fusion Middleware são especialmente sensíveis às definições de timeout porque várias operações precisam acessar o banco de dados em outro local. Configure os timeouts de forma que:
- Eles consideram a latência no sistema.
Talvez seja necessário aumentar os timeouts nesses tipos de sistemas devido às latências envolvidas. No modelo de cluster esticado, as configurações de domínio são compartilhadas para ambos os sites; portanto, é necessário usar timeouts que considerem o pior cenário.
- Eles expiram corretamente na cadeia de invocações em diferentes camadas.
Os timeouts devem ser configurados nas diferentes camadas do sistema para que as camadas de inclusão apropriadas se comportem corretamente. Por exemplo, se o timeout do banco de dados for definido com um valor menor que o timeout do WLS global, um ID de transação poderá ser "removido" do banco de dados antes da conclusão do trabalho em outras ramificações.
Estes são os principais parâmetros de tempo limite em diferentes camadas:
- Timeout de transação global
O timeout da transação global do Oracle WebLogic Server determina a duração máxima (em segundos) pela qual uma transação distribuída (uma transação global) pode permanecer ativa antes de ser automaticamente submetida a rollback pelo Oracle WebLogic Server. Configure o timeout da transação global na Console Remota WebLogicselecionando JTA (Java Transaction API) na seção Serviços da Árvore de Edição e especificando Segundos de Timeout.
- Timeout da transação XA
O timeout da transação XA nas origens de dados XA é usado no Oracle WebLogic Server para definir um timeout da ramificação da transação para origens de dados. Por padrão, esse valor é definido como 0 (zero), portanto, ele usa o timeout da transação global WebLogic. Mas talvez você queira defini-lo se tiver transações de longa execução que excedam o valor padrão de timeout no recurso XA. Esse valor é configurado para cada origem de dados XA, na guia Transação.
- Timeout de bloqueio distribuído
O timeout de bloqueio distribuído no banco de dados especifica o tempo (em segundos) para que as transações distribuídas aguardem recursos bloqueados. Você pode modificar o parâmetro (
distributed_lock_timeout) com as instruçõesSQL ALTERapropriadas.
Defina o tempo limite de bloqueio distribuído do banco de dados por tempo suficiente para a transação mais lenta, considerando quaisquer atrasos de rede entre os sites. Depois disso, defina a Origem de Dados XA e os Timeouts de Transação Global para valores inferiores usando a seguinte regra:
distributed_lock_timeout >= XA DS Timeout >= Global Transaction TimeoutOs aplicativos podem usar parâmetros de timeouts adicionais. Por exemplo, o Oracle SOA e o BPEL têm os seguintes parâmetros de timeout adicionais que você deve considerar:
- syncMaxWaitTime
O syncMaxWaitTime é o tempo máximo que um cliente síncrono aguarda uma resposta. Esta definição define quanto tempo uma operação de solicitação e resposta pode levar antes de expirar. Se o processo BPEL não receber uma resposta dentro deste tempo, a atividade falhará. Para alterar esse valor no Oracle Enterprise Manager Fusion Middleware Control:
- Clique com o botão direito do mouse em SOA-infra e selecione Administração SOA.
- Selecione Propriedades de BPEL.
- Selecione Mais Propriedades de Configuração BPEL.
- Atualize o valor syncMaxWaitTime (em segundos).
- Timeouts para EJBs
Quando os métodos BPEL EJBs estão envolvidos, isso especifica o timeout da transação em segundos (o padrão é 300 para todos os EJBs BPEL). Modifique o timeout da seguinte forma:
- Na Árvore de Monitoramento da Console Remota WebLogic, selecione Implantações e, em seguida, selecione Gerenciamento de Aplicativos.
- Expanda o aplicativo soa_infra e, em seguida, expanda Configuração e Subimplantação.
- Expanda o módulo e selecione o EJB BPEL específico.
Global Transaction Timeout > BPEL EJB's transaction timeout > syncMaxWaitTime - Timeouts dos clientes de Web services
O cliente de web services deve ser configurado com um timeout que seja permissivo o suficiente com a pior latência. Por exemplo, se uma chamada leva 3 segundos até o site 1, mas leva 10 segundos até o site 2, o tempo limite deve ser definido para pelo menos 10 segundos para lidar com o site mais lento.
- Timeouts de processos BPEL
Se o processo BPEL estiver usando tempos-limite de resposta de solicitação específicos (síncronos) e de recebimento somente in-only (assíncronos), você deverá defini-los com base no pior cenário: quando a chamada for para o site com a maior latência do banco de dados. Essas configurações de timeout são definidas no processo BPEL e não podem ser definidas de forma diferente para cada site. Para obter mais informações sobre como configurar eventos e timeouts nos processos BPEL, consulte o Oracle Fusion Middleware Developer's Guide para o Oracle SOA Suite. Consulte a seção Explorar Mais.
Configurar Replicação de Sessão
Alguns aplicativos (aplicativos web, consoles como o compositor Oracle SOA, o compositor BPM, o espaço de trabalho BPM etc.) fazem uso intensivo de objetos de sessão HTTP.
Uma das vantagens da implantação de cluster esticada do Oracle Fusion Middleware (FMW) é a capacidade de fornecer failover contínuo entre sites. No entanto, a replicação de sessão entre regiões pode causar degradação do desempenho no sistema. A Oracle recomenda definir dois grupos de replicação diferentes (um para cada região) para minimizar a replicação entre os dois locais.
Para configurar grupos de replicação de sessão,
- Na Árvore de Edição da Console Remota WebLogic, selecione Ambiente e Servidores.
- Selecione Nome do Servidor e selecione a guia Cluster.
- Para cada servidor na região 1, informe o mesmo nome de Grupo de Replicação (por exemplo, Region1RepGroup).
- Repita as etapas para os servidores na região 2, usando um nome comum para todos eles, mas diferente do usado na região 1 (por exemplo, Region2RepGroup).
Observe que o uso de grupos de replicação é um melhor esforço para replicar o estado somente para servidores no mesmo site, mas não é um método determinístico. Se um único servidor estiver disponível em um site e outros estiverem disponíveis no outro, a replicação ocorrerá nas regiões e continuará para essa sessão, mesmo que os servidores voltem on-line no mesmo site.
Configurar Reinicialização no Local para JMS
Os armazenamentos persistentes são críticos para o funcionamento adequado dos servidores Oracle WebLogic Server (WLS). Com a reinicialização no local, se o armazenamento persistente encontrar um erro, o serviço JMS tentará reiniciar no mesmo servidor antes de tentar migrar para outro servidor. Esse método é mais rápido do que migrar todo o serviço JMS para outro servidor e muitas vezes pode resolver problemas rapidamente.
Para configurar a reinicialização no local para armazenamentos persistentes JMS, o servidor JMS relacionado e o armazenamento persistente devem ser direcionados a um destino migrável. Este destino migrável deve usar Reiniciar em caso de Falha, que não é ativado por padrão. Para configurar essa propriedade, siga estas etapas:
- Estabelecer Conexão com a Console Remota WebLogic
- Na Árvore de Edição, selecione Ambiente e, em seguida, Alvos Migráveis.
- Selecione um destino migrável e ative Reiniciar em Caso de Falha.
- Selecione Salvar e confirme as alterações.
Configurar o Adaptador JMS do Oracle FMW SOA Suite
A Oracle recomenda o uso da sintaxe do cluster (por exemplo: cluster:t3s://cluster_name) para simplificar a configuração. Essa abordagem simplifica a configuração, permitindo que o adaptador recupere dinamicamente a lista atual de servidores ativos no cluster, garantindo a recuperação eficiente do contexto JNDI.
Se o sistema usar o adaptador JMS intensamente e com payloads grandes, é recomendável configurar o URL JNDI para incluir somente os servidores locais dentro de cada região. Isso significa especificar servidores na região 1 para configurações na região 1 e servidores na região 2 para configurações na região 2. Essa configuração garante a afinidade com o contexto do site, otimizando o desempenho e reduzindo a latência.
Configurar o Oracle FMW SOA Suite File Adapter
Este mecanismo garante que o mesmo arquivo seja processado apenas por um servidor de cada vez e que duas instâncias do adaptador não gravarão no mesmo arquivo simultaneamente.
Na topologia de cluster esticada do Oracle Fusion Middleware (FMW), cada site opera de forma independente, processando arquivos usando seu próprio armazenamento compartilhado dedicado. No entanto, por padrão, ambos os sites utilizam a mesma fonte de dados, esquema e tabelas para mecanismos de bloqueio de arquivos e mutex.
Em operações de saída, a utilização de uma tabela de banco de dados compartilhado é apropriada porque uma sequência exclusiva é empregada como um mutex para evitar que operações de gravação simultâneas substituam arquivos.
No entanto, cenários "em processamento" podem surgir para operações de entrada. As instâncias do Adaptador de Arquivos em qualquer site podem marcar um arquivo como "bloqueado". Se o mesmo nome de arquivo existir em ambos os sites, este mecanismo pode bloquear seu processamento em ambos os locais, mas o arquivo será consumido em apenas um deles. Para evitar essas situações, existem várias alternativas:
- Implementar convenções de nomenclatura de arquivos específicas do site. Use identificadores exclusivos em nomes de arquivos com base no site, reduzindo a probabilidade de colisões de nomes e o bloqueio subsequente.
- Configure esquemas separados para cada região para as tabelas de bloqueio e mutex do adaptador de Arquivos, para garantir que os mecanismos de bloqueio e mutex de arquivos operem de forma independente, evitando o bloqueio entre sites.
- Use um banco de dados separado para as tabelas de bloqueio e mutex do adaptador de arquivos para garantir que os metadados de processamento de arquivos sejam gerenciados separadamente.
Para configurar o Adaptador de Arquivos para usar diferentes bancos de dados ou esquemas separados em cada região, crie o proprietário e as tabelas de esquema apropriados e estabeleça uma nova origem de dados. Os servidores na região 1 continuarão usando a origem de dados original. Somente o plano de implantação na região 2 será modificado para usar a nova origem de dados.
Os servidores da região 1 usarão a origem de dados original, enquanto os servidores da região 2 usarão a nova.
Configurar o Oracle Fusion Middleware Oracle SOA Suite In-Memory SOA
Isso melhora o desempenho e a escalabilidade desses processos de negócios à medida que as operações de leitura e gravação são executadas fora do cache.
As informações de estado do BPEL são armazenadas e extraídas do cache do Oracle Coherence. O estado do processo só é gravado no banco de dados quando há falha ou em intervalos regulares usando um thread de gravação retroativa.
O SOA na memória não é suportado na topologia de cluster estendida do Oracle Fusion Middleware, em que o uso do cache de coerência deve ser mínimo, pois é muito sensível a atrasos.
Configurar Ajuste do Leasing do Banco de Dados WebLogic
O leasing de banco de dados é um mecanismo básico usado para suportar a Migração Automática de Serviço, particularmente para serviços singleton agrupados, como servidores JMS ou o JTA Transaction Recovery Service. Ele é usado para gerenciar e coordenar a propriedade desses serviços singleton em vários servidores em um cluster. Este mecanismo usa um banco de dados como um ponto central para rastrear e controlar de forma confiável qual servidor em um cluster "possui" ou gerencia um serviço singleton específico a qualquer momento. Para isso, é possível armazenar um registro de versão no banco de dados, que é atualizado periodicamente (renovado) pelo servidor proprietário. Consulte Leasing for Migratable Services em Administrando Clusters para Oracle WebLogic Server.
A configuração para as origens de dados GridLink fornecidas anteriormente neste guia garante reconexões automáticas quando um failover de banco de dados ou um switchover ocorre. No entanto, todos os servidores configurados com leasing de banco de dados ou com armazenamentos persistentes JDBC podem ser desativados durante uma interrupção, switchover ou failover do banco de dados. Quando um subsistema crítico (como o serviço JTA) falha, o servidor é definido para o estado FAILED e é reiniciado automaticamente pelo gerenciador de nós.
O tempo necessário para ir para o estado FAILED é variável; depende de quando as verificações relevantes são acionadas e pode acontecer por vários motivos:
- Se o servidor não puder atualizar a tabela de leasing após o número total de novas tentativas.
- Se o servidor não puder acessar o armazenamento persistente JTA JDBC após várias repetições e reinicializações no local.
Um switchover de banco de dados pode levar alguns minutos. A reinicialização automática dos servidores WLS devido à perda de acesso ao armazenamento persistente JTA JDBC leva mais tempo para acontecer, aproximadamente 8-9 minutos, portanto, não é acionada durante um switchover ou failover típico do banco de dados. Mas um servidor pode fazer a transição para o estado FAILED devido à perda de um leasing em menos de 2 minutos com a configuração de leasing padrão. Portanto, uma reinicialização do Oracle WebLogic Server pode ser acionada automaticamente durante um switchover ou failover do Oracle Data Guard se esse servidor WebLogic estiver usando leasing de banco de dados.
Há dois parâmetros para melhorar a resiliência a interrupções de banco de dados para servidores que usam leasing de banco de dados. Esses parâmetros são database-leasing-basis-connection-retry-count (1 nova tentativa por padrão) e database-leasing-basis-connection-retry-delay (1 segundo por padrão). O aumento desses parâmetros prolonga o tempo antes da ocorrência de um erro de leasing perdido. Isso permite que os servidores WebLogic tolerem interrupções mais longas do banco de dados sem reinicialização automática; eles simplesmente se reconectam ao banco de dados quando ele se torna disponível novamente. Embora as tentativas de conexão falhem enquanto o banco de dados está inativo, os servidores WebLogic não serão reiniciados.
Portanto, em um cluster esticado, é recomendável incrementar os valores da Contagem de Repetições e do Timeout da Conexão de Leasing do Banco de Dados para tornar o servidor WebLogic mais resiliente às interrupções do banco de dados. Para alterar essas propriedades, use comandos WLST. Por exemplo:
$ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('weblogic','password','t3s://ADMINVHN:9002')
edit()
startEdit()
cd('/Clusters/' + 'My_Cluster')
cmo.setDatabaseLeasingBasisConnectionRetryCount(10)
cmo.setDatabaseLeasingBasisConnectionRetryDelay(10000L)
save()
activate()
disconnect()
exit()Dica:
Quando um servidor vai para um estado FAILED, o gerenciador de nós tenta duas reinicializações para o servidor por padrão. Se o servidor não puder ser iniciado corretamente, ele será marcado como FAILED_NOT_RESTARTABLE. Você pode ajustar o número de reinicializações na guia Integridade do servidor. Use o parâmetro Máximo de Reinicializações Dentro do Intervalo para definir o número de vezes que o gerenciador de nós pode reiniciar o servidor dentro do intervalo especificado em Intervalo de Reinicialização.Configurar o Coherence
Por exemplo, o Oracle SOA Suite usa o Oracle Coherence para propagar implantações de compostos e atualizações de metadados (MDS) em um cluster.
O Oracle Coherence suporta comunicação multicast e unicast para descoberta e mensagens de membros do cluster. O Unicast é especialmente adequado em ambientes onde o multicast está indisponível ou não é suportado, como em vários data centers ou regiões de nuvem. Usando o recurso de endereços conhecidos (WKA), os membros do cluster podem descobrir e se juntar ao cluster sem depender de multicast. Quando o WKA é configurado, toda a comunicação multicast é desativada. Por padrão, os produtos do Oracle Fusion Middleware utilizam o unicast com uma lista WKA predefinida para o Coherence.
O Oracle Coherence é sensível a atrasos durante a formação do cluster e na resposta a heartbeats de membros do cluster. No entanto, versões recentes melhoraram a tolerância a atrasos de comunicação por meio de recursos como allowable variance. O allowable variance define as variações de tempo permitidas nas comunicações de rede em um cluster do Coherence. Esse parâmetro configurável (maximum-time-variance), assumindo como padrão 16 ms, define a latência máxima permitida para comunicações UDP de tempo de ida e volta (RTT). O Coherence ajusta dinamicamente esse valor em resposta a latências ou inconsistências de rede observadas, mantendo a estabilidade e o desempenho do cluster acomodando maiores desvios no tempo esperado. A mensagem Increasing allowable variance to XX indica esse ajuste. Consulte Elementos de Configuração Operacional em Desenvolvendo Aplicações com o Oracle Coherence.
Com essa melhoria no Oracle Coherence, nenhum erro será reportado na formação do cluster se a latência permanecer dentro dos limites recomendados para a topologia de cluster esticada por FMW (<10ms RTT). Mas ainda assim, longos atrasos nos batimentos cardíacos do cluster podem causar contenção em implantações e tempos de reação ruins a interrupções.
Se você encontrar erros na formação ou nas operações de cluster do Coherence, poderá ajustar os seguintes parâmetros de timeout de rede do Coherence:
<multicast-listener><join-timeout-milliseconds>. Apesar de ter sido originalmente projetado para configurações multicast, o impacto do join-timeout no unicast também. Ele determina quanto tempo o nó inicial levará para formar um cluster e, depois disso, quanto tempo cada nó gastará procurando o cluster antes de tentar formar o seu próprio (se eles estiverem na lista WKA). O valor padrão é 3000, em uma rede não confiável, talvez você precise aumentar esse valor para tentar encontrar um cluster por um período maior antes de iniciar um novo.<packet-publisher><packet-delivery><resend-milliseconds>. O intervalo de reenvio do pacote especifica o tempo mínimo, em milissegundos, que o editor de pacotes aguarda por um pacote ACK correspondente, antes de reenviar um pacote. Deve haver alguns múltiplos do RTT. 10x deve estar correto. O valor default é 200.<packet-publisher><packet-delivery><timeout-milliseconds>. Para pacotes que requerem confirmação, especifica a quantidade máxima de tempo, em milissegundos, que um pacote é reenviado. Após esse timeout expirar, o Coherence determina se o destinatário deve ser considerado encerrado. O valor padrão de 5 min deve ser suficiente, mas você pode aumentá-lo para evitar timeouts ao ingressar no cluster.<packet-publisher><packet-delivery><heartbeat-milliseconds>Esse parâmetro é o intervalo de pulsação para a detecção de morte do anel tcp. O valor padrão de pulsação é 1 segundo. Você pode aumentar o valor para aliviar o tráfego de rede, mas isso também prolonga a detecção de membros com falha.<tcp-ring-listener><ip-timeout>e<ip-attempts>. Essas são a quantidade de tempo e tentativas antes de determinar que um computador que está hospedando membros do cluster se tornou inacessível. O Ip-timeout deve estar na área de 10x o RTT ou superior, com um mínimo de 5s.<cluster-config><tcp-ring-listener><enabled>. Você pode até desativar a detecção de morte por anel tcp para aliviar o tráfego de rede, mas também faz com que a detecção de membros com falha demore mais. Para desativar a detecção de morte, defina-a como falsa. Se desativado, um membro do cluster usa o intervalo de tempo limite de reenvio do editor de pacotes para determinar se outro membro parou de responder a pacotes UDP (por padrão, definido como 5 minutos.)
Para modificar as definições de configuração padrão, use um arquivo de substituição do Coherence. Crie um arquivo chamado custom-coherence-override-<name>.xml e certifique-se de que ele seja consistente e acessível a todos os servidores no cluster. Especifique este arquivo na propriedade java tangosol.coherence.override. Você pode defini-lo na propriedade java EXTRA_JAVA_PROPERTIES no arquivo setUserOverrides.sh. Por exemplo:
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dtangosol.coherence.override=/u01/oracle/config/coherence_custom/custom-coherence-override.xml"Exemplo de arquivo de substituição do Coherence para ajustar parâmetros:
<?xml version='1.0'?>
<!--
This is a custom operational configuration override
-->
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd"
>
<cluster-config>
<multicast-listener>
<join-timeout-milliseconds>5000</join-timeout-milliseconds>
</multicast-listener>
<tcp-ring-listener>
<ip-timeout>20s</ip-timeout>
<ip-attempts>3</ip-attempts>
</tcp-ring-listener>
<packet-publisher>
<packet-delivery>
<resend-milliseconds>200</resend-milliseconds>
<timeout-milliseconds>650000</timeout-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>
Exemplo de arquivo de substituição do Coherence para ajustar o intervalo do anel tcp:
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<heartbeat-milliseconds>5000</heartbeat-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>Exemplo de arquivo de substituição de coerência para desativar a detecção de morte do anel tcp:
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<tcp-ring-listener>
<enabled>false</enabled>
</tcp-ring-listener>
</cluster-config>
</coherence>
Configurar Desempenho do Serviço de Rede
Algumas configurações padrão do sistema operacional podem não ser otimizadas e torna-se muito importante ajustar alguns parâmetros para tornar a transferência de dados mais eficiente. Esses ajustes se tornam particularmente significativos quando há alta latência entre clientes e servidores JDBC. Os servidores com a maior latência no acesso ao banco de dados devem orientar a configuração dos buffers de rede e das definições do Oracle Net Services para otimizar o desempenho.
Uma das principais métricas para determinar a configuração ideal é o BDP (Bandwidth-Delay Product, Produto de atraso de largura de banda). Representa a quantidade máxima de dados que podem estar em trânsito em uma rede a qualquer momento. É calculado multiplicando a capacidade (largura de banda) de um link de rede pelo seu tempo de atraso de ida e volta (latência):
BDP = Bandwidth × Round-Trip Time (RTT)- RTT: Na OCI, você pode obter o RTT médio entre regiões na página Latência entre regiões na console da OCI. Como alternativa, você pode determinar o tempo de ida e volta (RTT) com comandos como ping de um host para outro por alguns minutos e usar os tempos de resposta retornados.
- Largura de banda: não há uma largura de banda garantida entre as regiões da OCI, e a OCI não oferece uma ferramenta específica de medição de largura de banda da OCI. Para medições precisas da largura de banda, você pode usar ferramentas como iPerf para realizar testes. A largura de banda testada entre Frankfurt e Amsterdã é de cerca de 2 a 2,5 Gbps.
As configurações de buffer de soquete TCP controlam quantos pacotes são enviados ao mesmo tempo pela rede. Para obter o throughput ideal, é recomendável definir o tamanho do buffer de soquete para, pelo menos, o BDP. Em muitos casos, definir o tamanho do buffer para o dobro do BDP pode melhorar ainda mais o desempenho, especialmente em redes de alta latência. No entanto, buffers excessivamente grandes podem levar ao aumento do uso de memória. Portanto, é aconselhável definir o tamanho do buffer dentro do intervalo do BDP para três vezes o BDP:
BDP ≤ Socket Buffer Size ≤ 3 × BDPConfigurar Tamanhos de Buffer de E/S no Banco de Dados
SEND_BUF_SIZE no lado do servidor geralmente é suficiente.
Se o servidor de banco de dados estiver recebendo solicitações grandes, defina também o parâmetro RECV_BUF_SIZE. É recomendável ajustá-los no nível do Oracle Net Services no banco de dados, em vez de no nível do Sistema Operacional, para que as sessões TCP normais, como SSH, etc., não usem memória adicional.
Para configurar esses parâmetros para o servidor de banco de dados, defina o tamanho do espaço de buffer nos arquivos listener.ora ou sqlnet.ora.
-
No arquivo
listener.ora, especifique os parâmetros de espaço de buffer para um endereço de protocolo específico ou para uma descrição. Veja a seguir um exemplo das definições de uma configuração típica de listener do Oracle RAC em um Sistema Base Database no Oracle Cloud Infrastructure (OCI):LISTENER_SCAN2=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN2)))) LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))) LISTENER_SCAN3=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN3)))) (…) LISTENER=(DESCRIPTION=(SDU=65535)(SEND_BUF_SIZE=10485760)(RECV_BUF_SIZE=10485760)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))) -
Se os parâmetros forem definidos no
sqlnet.ora, eles se aplicarão globalmente a todos os listeners. Veja a seguir um exemplo das configurações no arquivosqlnet.ora:RECV_BUF_SIZE=10485760 SEND_BUF_SIZE=10485760
Configurar tamanhos do buffer de E/S nos nós da camada intermediária
O sistema operacional Linux usa o ajuste automático para o buffer de recebimento e remetente.
Para o buffer de recebimento, o ajuste automático é determinado pelo parâmetro /proc/sys/net/ipv4/tcp_moderate_rcvbuf. Se o parâmetro tiver um valor 1, o ajuste automático será ativado. Com o ajuste automático, o tamanho do buffer do receptor (e o tamanho da janela TCP) é atualizado dinamicamente para cada conexão, com um tamanho máximo de buffer de 4 MB.
Para o buffer do remetente, o ajuste automático também é ativado por padrão. Embora o ajuste automático do buffer de recebimento possa ser controlado por meio do parâmetro tcp_moderate_rcvbuf, o ajuste automático do buffer de envio não tem uma alternância direta. A definição de tamanhos de buffer fixos desativa o ajuste automático do buffer de envio.
Esses processos de ajuste automático são regidos por vários parâmetros do kernel que gerenciam a alocação de memória para envio e recebimento de dados:
- Por tamanhos de buffer de conexão
A alocação de memória para cada conexão TCP é definida por dois parâmetros:
/proc/sys/net/ipv4/tcp_rmem, que especifica a memória reservada para buffers de recepção TCP./proc/sys/net/ipv4/tcp_wmem, que especifica a memória reservada para buffers de envio TCP.
Ambos os parâmetros aceitam três valores:
- Tamanho Mínimo do Buffer: o menor tamanho de buffer alocado para um soquete TCP.
- Tamanho do Buffer Padrão: o tamanho do buffer inicial atribuído a um soquete TCP na criação.
- Tamanho Máximo do Buffer: o maior tamanho de buffer que pode ser alocado automaticamente para um soquete TCP.
Essas configurações estabelecem os limites para mecanismos de ajuste automático e ajudam a equilibrar o uso da memória, especialmente durante períodos de estresse da memória.
- Tamanhos de buffer por aplicativo
Os aplicativos podem solicitar tamanhos de buffer específicos, mas essas solicitações estão sujeitas a limites definidos pelos seguintes parâmetros:
/proc/sys/net/core/rmem_max, é a janela de recebimento máximo, que define o limite superior do tamanho do buffer de recebimento que os aplicativos podem solicitar./proc/sys/net/core/wmem_max, é a janela Enviar máxima, que define o limite superior para o tamanho do buffer de envio que os aplicativos podem solicitar.
Para ajustar tamanhos de buffer de E/S:
O ajuste automático TCP permanece ativado com limites dimensionados para o produto de atraso de largura de banda da sua rede, melhorando a taxa de transferência sem o uso de memória do sistema de dimensionamento excessivo.
Configurar o Tamanho da Unidade de Dados da Sessão
Oracle Net Services aguarda o preenchimento dessas unidades antes de enviá-las pela rede. Cada um desses buffers é uma unidade de dados de sessão (SDU). Ajustar o tamanho da SDU à quantidade de dados fornecidos para o Oracle Net Services pode melhorar o desempenho, a utilização da rede e o consumo de memória em um cluster esticado do Oracle Fusion Middleware com latências mais altas que 5 mseg RTT.
O tamanho do SDU pode ser definido de 512 bytes para 2 MB. No Oracle Database 23ai, o tamanho padrão da SDU é de 64 KB (65.536 bytes). As versões anteriores do banco de dados definem seu tamanho SDU padrão como 8 KB.
O tamanho real do SDU usado é negociado entre o cliente e o servidor no momento da conexão e é o menor dos dois valores. Configurar um tamanho de SDU diferente do padrão requer configurar o SDU em ambos os computadores cliente e servidor. A Oracle recomenda definir o SDU para o valor máximo possível (64k).
Clientes e servidores negociam o SDU no momento da conexão; configurar ambos os lados garante que o SDU pretendido seja usado.