Configurar optimizaciones adicionales para clusters extendidos de FMW
Aunque no todos son obligatorios para esta topología, mejoran el rendimiento y mejoran el comportamiento de determinadas funciones y escenarios.
Configurar timeouts en Oracle WebLogic Server (WLS)
Se han especificado límites de timeout para las transacciones de la base de datos, para las bifurcaciones de transacción, las llamadas al método Enterprise JavaBean (EJB), los servicios web, etc. Los despliegues de cluster ampliados de Oracle Fusion Middleware son especialmente sensibles a la configuración de timeout porque varias operaciones necesitan acceder a la base de datos en una ubicación diferente. Configure los timeouts de manera que:
- Ellos representan la latencia en el sistema.
Es posible que deba aumentar los timeouts en estos tipos de sistemas debido a las latencias involucradas. En el modelo de cluster ampliado, la configuración de dominio se comparte para ambos sitios; por lo tanto, es necesario utilizar timeouts que representen el peor de los casos.
- Caducan correctamente en la cadena de llamadas a través de diferentes capas.
Los tiempos de espera se deben configurar en las diferentes capas del sistema para que los niveles de adopción adecuados se comporten correctamente. Por ejemplo, si el timeout de la base de datos se define en un valor inferior al timeout de WLS global, se puede "eliminar" un ID de transacción de la base de datos antes de que finalice el trabajo en otras bifurcaciones.
Estos son los principales parámetros de timeout en diferentes capas:
- Timeout de la transacción global
El timeout de transacción global de Oracle WebLogic Server determina la duración máxima (en segundos) durante la que se permite que una transacción distribuida (una transacción global) permanezca activa antes de que Oracle WebLogic Server realice automáticamente un rollback. Configure el timeout de transacción global en WebLogic Remote Console mediante la selección de JTA (Java Transaction API) en la sección Servicios del árbol de edición y la especificación de segundos de timeout.
- Timeout de transacción XA
El timeout de transacción XA en los orígenes de datos XA se utiliza en Oracle WebLogic Server para definir un timeout de rama de transacción para los orígenes de datos. Por defecto, este valor se define en 0 (cero), por lo que utiliza el timeout de transacción global WebLogic. Sin embargo, puede que desee definirlo si tiene transacciones de larga ejecución que superan el valor del timeout por defecto en el recurso de XA. Este valor se configura para cada origen de datos XA, en el separador Transacción.
- Timeout de bloqueo distribuido
El timeout de bloqueo distribuido en la base de datos especifica la cantidad de tiempo (en segundos) que las transacciones distribuidas esperan los recursos bloqueados. Puede modificar el parámetro (
distributed_lock_timeout) con las sentenciasSQL ALTERadecuadas.
Defina el tiempo de espera de bloqueo distribuido de la base de datos el tiempo suficiente para la transacción más lenta, teniendo en cuenta los retrasos de red entre sitios. Después de eso, defina el origen de datos XA y los timeouts de transacción global en valores inferiores mediante la siguiente regla:
distributed_lock_timeout >= XA DS Timeout >= Global Transaction TimeoutLas aplicaciones pueden utilizar parámetros de timeout adicionales. Por ejemplo, Oracle SOA y BPEL tienen los siguientes parámetros de timeout adicionales que debe tener en cuenta:
- syncMaxWaitTime
syncMaxWaitTime es el tiempo máximo que un cliente síncrono espera una respuesta. Esta configuración define cuánto tiempo puede tardar una operación de solicitud y respuesta antes de que se agote el tiempo de espera. Si el proceso BPEL no obtiene una respuesta en este momento, la actividad falla. Para cambiar este valor en Oracle Enterprise Manager Fusion Middleware Control:
- Haga clic con el botón derecho en SOA-infra y, a continuación, seleccione Administración de SOA.
- Seleccione BPEL Properties (Propiedades de BPEL).
- Seleccione Más Propiedades de Configuración de BPEL.
- Actualice el valor syncMaxWaitTime (en segundos).
- Timeouts para EJB
Cuando intervienen los métodos EJB de BPEL, se especifica el timeout de transacción en segundos (el valor por defecto es 300 para todos los EJB de BPEL). Modifique el timeout de la siguiente manera:
- En el árbol de supervisión de WebLogic Remote Console, seleccione Despliegues y, a continuación, seleccione Gestión de aplicaciones.
- Amplíe la aplicación soa_infra y, a continuación, amplíe Configuración y Despliegue secundario.
- Amplíe el módulo y seleccione el EJB BPEL específico.
Global Transaction Timeout > BPEL EJB's transaction timeout > syncMaxWaitTime - Timeout de clientes de servicios web
El cliente de servicios web debe estar configurado con un timeout que sea lo suficientemente permisivo con la peor latencia. Por ejemplo, si una llamada tarda 3 segundos en el sitio 1, pero tarda 10 segundos en el sitio 2, el tiempo de espera se debe establecer en al menos 10 segundos para manejar el sitio más lento.
- Timeouts de Procesos BPEL
Si el proceso BPEL utiliza timeouts específicos de solicitud-respuesta (síncronos) y de solo recepción (asíncronos), debe definirlos según el peor de los casos: cuando la llamada se dirige al sitio con la latencia de base de datos más alta. Estos valores de timeout se definen en el proceso BPEL y no se pueden definir de forma diferente para cada ubicación. Para obtener más información sobre la configuración de eventos y timeouts en los procesos BPEL, consulte la guía del desarrollador de Oracle Fusion Middleware para Oracle SOA Suite. Consulte la sección Explorar más.
Configurar replicación de sesión
Algunas aplicaciones (aplicaciones web, consolas, como el compositor de Oracle SOA, el compositor de BPM, el espacio de trabajo de BPM, etc.) hacen un uso intensivo de los objetos de sesión HTTP.
Una de las ventajas del despliegue de cluster ampliado de Oracle Fusion Middleware (FMW) es la capacidad de proporcionar un failover perfecto entre sitios. Sin embargo, la replicación de sesión entre regiones puede provocar una degradación del rendimiento en el sistema. Oracle recomienda definir dos grupos de replicación diferentes (uno para cada región) para minimizar la replicación en los dos sitios.
Para configurar grupos de replicación de sesión,
- En el árbol de edición de WebLogic Remote Console, seleccione Entorno y, a continuación, Servidores.
- Seleccione Nombre de servidor y, a continuación, seleccione el separador Cluster.
- Para cada servidor de la región 1, introduzca el mismo nombre de grupo de replicación (por ejemplo, Region1RepGroup).
- Repita los pasos para los servidores de la región 2, utilizando un nombre común para todos ellos pero diferente del utilizado en la región 1 (por ejemplo, Region2RepGroup).
Tenga en cuenta que el uso de grupos de replicación es un mejor esfuerzo para replicar el estado solo a servidores en el mismo sitio, pero no es un método determinista. Si un único servidor está disponible en un sitio y otros están disponibles en el otro, la replicación se producirá en todas las regiones y continuará para esa sesión, incluso si los servidores vuelven a estar en línea en el mismo sitio.
Configurar Reinicio In Situ para JMS
Los almacenes persistentes son críticos para el correcto funcionamiento de los servidores de Oracle WebLogic Server (WLS). Al reiniciar in situ, si el almacén persistente detecta un error, el servicio JMS intentará reiniciarse en el mismo servidor antes de intentar migrar a otro servidor. Este método es más rápido que migrar todo el servicio JMS a otro servidor y, a menudo, puede resolver problemas rápidamente.
Para configurar el reinicio in situ para los almacenes persistentes de JMS, el servidor JMS relacionado y el almacén persistente deben estar dirigidos a un destino migrable. Este destino migrable debe utilizar Restart on Failure, que no está activado por defecto. Para configurar esta propiedad, siga estos pasos:
- Conexión a la WebLogic Remote Console
- En el árbol de edición, seleccione Entorno y, a continuación, Destinos migrables.
- Seleccione un destino migrable y active Reiniciar si se produce un fallo.
- Seleccione Guardar y confirme los cambios.
Configurar el adaptador de JMS de Oracle FMW SOA Suite
Oracle recomienda utilizar la sintaxis del cluster (por ejemplo: cluster:t3s://cluster_name) para simplificar la configuración. Este enfoque simplifica la configuración al permitir que el adaptador recupere dinámicamente la lista actual de servidores activos en el cluster, lo que garantiza una recuperación eficaz del contexto JNDI.
Si el sistema utiliza el adaptador JMS de forma intensiva y con cargas útiles grandes, se recomienda configurar la URL de JNDI para que incluya solo los servidores locales de cada región. Esto significa especificar servidores en la región 1 para configuraciones en la región 1, y servidores en la región 2 para configuraciones en la región 2. Esta configuración garantiza la afinidad con el contexto del sitio, optimizando el rendimiento y reduciendo la latencia.
Configuración del Adaptador de Archivos de Oracle FMW SOA Suite
Este mecanismo garantiza que el mismo archivo sea procesado sólo por un servidor a la vez y que dos instancias de adaptador no escribirán en el mismo archivo simultáneamente.
En la topología de cluster ampliado de Oracle Fusion Middleware (FMW), cada sitio funciona de forma independiente, procesando archivos mediante su propio almacenamiento compartido dedicado. Sin embargo, por defecto, ambos sitios utilizan el mismo origen de datos, esquema y tablas para el bloqueo de archivos y los mecanismos de mutex.
En las operaciones de salida, la utilización de una tabla de base de datos compartida es adecuada porque se utiliza una secuencia única como mutex para evitar que las operaciones de escritura simultáneas sobrescriban los archivos.
Sin embargo, pueden surgir escenarios de "en procesamiento" para operaciones de entrada. Las instancias del adaptador de archivos de cualquier sitio pueden marcar un archivo como "bloqueado". Si el mismo nombre de archivo existe en ambos sitios, este mecanismo puede bloquear su procesamiento en ambas ubicaciones, pero el archivo se consumirá solo en una de ellas. Para evitar estas situaciones, existen varias alternativas:
- Implantar convenciones de nomenclatura de archivos específicas del sitio. Utilice identificadores únicos en los nombres de archivo basados en el sitio, lo que reduce la probabilidad de colisiones de nombres y bloqueos posteriores.
- Configure esquemas independientes para cada región para las tablas de bloqueo y mutex del adaptador de archivos, a fin de garantizar que los mecanismos de bloqueo y mutex de archivos funcionen de forma independiente, evitando el bloqueo entre sitios.
- Utilice una base de datos independiente para las tablas de bloqueo y mutex del adaptador de archivos para asegurarse de que los metadatos de procesamiento de archivos se gestionan por separado.
Para configurar el adaptador de archivos para que utilice diferentes bases de datos o esquemas independientes en cada región, debe crear el propietario y las tablas del esquema adecuados y establecer un nuevo origen de datos. Los servidores de la región 1 seguirán utilizando el origen de datos original; solo el plan de despliegue de la región 2 se modificará para utilizar el nuevo origen de datos.
Los servidores de la región 1 utilizarán el origen de datos original, mientras que los servidores de la región 2 utilizarán el nuevo.
Configuración de SOA en memoria de Oracle Fusion Middleware Oracle SOA Suite
Esto mejora el rendimiento y la escalabilidad de estos procesos de negocio a medida que las operaciones de lectura y escritura se realizan fuera de la caché.
La información de estado BPEL se almacena en la caché de Oracle Coherence y se extrae de ella. El estado del proceso se escribe en la base de datos solo cuando tiene fallos o a intervalos regulares mediante un thread de escritura posterior.
La SOA en memoria no está soportada en la topología de cluster ampliado de Oracle Fusion Middleware, donde el uso de la caché de Coherence debe ser mínimo, ya que es muy sensible a los retrasos.
Configuración del ajuste de leasing de base de datos WebLogic
El arrendamiento de la base de datos es un mecanismo básico utilizado para soportar la migración automática de servicios, especialmente para servicios singleton agrupados como servidores JMS o el servicio de recuperación de transacciones de JTA. Se utiliza para gestionar y coordinar la propiedad de estos servicios singleton en varios servidores de un cluster. Este mecanismo utiliza una base de datos como un punto central para rastrear y controlar de forma fiable qué servidor de un cluster "posee" o gestiona un servicio singleton específico en un momento dado. Para ello, se almacena un registro de versión en la base de datos, que el servidor propietario actualiza (renueva) periódicamente. Consulte Leasing para Servicios Migrables en Administración de Clusters para Oracle WebLogic Server.
La configuración de los orígenes de datos GridLink proporcionada anteriormente en esta guía garantiza las reconexiones automáticas cuando se produce un failover de base de datos o un switchover. Sin embargo, todos los servidores configurados con leasing de base de datos o con almacenes persistentes JDBC se pueden cerrar durante una interrupción, switchover o failover de la base de datos. Cuando un subsistema crítico (como el servicio JTA) falla, el servidor se establece en el estado FAILED (Error) y el gestor de nodos lo reinicia automáticamente.
El tiempo que se tarda en pasar al estado FAILED es variable; depende de cuándo se disparen las comprobaciones relevantes y puede ocurrir por varias razones:
- Si el servidor no puede actualizar la tabla de leasing después del número total de reintentos.
- Si el servidor no puede acceder al almacén persistente de JDBC de JTA después de varios reintentos y reinicios in situ.
Un switchover de la base de datos puede tardar unos minutos. El reinicio automático de los servidores WLS debido a la pérdida de acceso al almacén persistente JDBC de JTA tarda más tiempo en producirse, aproximadamente de 8 a 9 minutos, por lo que no se dispara durante un switchover o failover típico de la base de datos. Sin embargo, un servidor puede pasar al estado FALLIDO debido a la pérdida de un permiso en menos de 2 minutos con la configuración de arrendamiento por defecto. Por lo tanto, se puede disparar automáticamente un reinicio de Oracle WebLogic Server durante una operación de switchover o failover de Oracle Data Guard si ese servidor WebLogic utiliza leasing de base de datos.
Hay dos parámetros para mejorar la resiliencia a las interrupciones de la base de datos para los servidores que utilizan el leasing de bases de datos. Estos parámetros son database-leasing-basis-connection-retry-count (1 reintento por defecto) y database-leasing-basis-connection-retry-delay (1 segundo por defecto). El aumento de estos parámetros prolonga el tiempo antes de que se produzca un error de permiso perdido. Esto permite a los servidores WebLogic tolerar interrupciones más largas de la base de datos sin reiniciar automáticamente; simplemente se vuelven a conectar a la base de datos una vez que vuelva a estar disponible. Aunque los intentos de conexión fallarán mientras la base de datos está caída, los servidores WebLogic no se reiniciarán.
Por lo tanto, en un cluster ampliado, se recomienda aumentar los valores de Recuento de reintentos de conexión de leasing de base de datos y Timeout para que el servidor WebLogic sea más resistente a las interrupciones de la base de datos. Para cambiar estas propiedades, use los comandos de WLST. Por ejemplo:
$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()Sugerencia:
Cuando un servidor pasa al estado FAILED (Error), el gestor de nodos intenta dos reinicios para el servidor por defecto. Si el servidor no se puede iniciar correctamente, se marca como FAILED_NOT_RESTARTABLE. Puede ajustar el número de reinicios en el separador Health (Estado) del servidor. Utilice el parámetro Max Restarts Within Interval para definir el número de veces que el gestor de nodos puede reiniciar el servidor dentro del intervalo especificado en Restart Interval.Configurar Coherence
Por ejemplo, Oracle SOA Suite utiliza Oracle Coherence para propagar despliegues de compuestos y actualizaciones de metadatos (MDS) en un cluster.
Oracle Coherence soporta tanto la comunicación de multidifusión como de unidifusión para la detección y mensajería de miembros de cluster. Unicast es especialmente adecuado en entornos donde la multidifusión no está disponible o no es compatible, como en varios centros de datos o regiones en la nube. Mediante la función de direcciones conocidas (WKA), los miembros del cluster pueden detectar y unirse al cluster sin depender de la multidifusión. Cuando WKA está configurado, todas las comunicaciones de multidifusión están desactivadas. Por defecto, los productos de Oracle Fusion Middleware utilizan unidifusión con una lista de WKA predefinida para Coherence.
Oracle Coherence es sensible a los retrasos durante la formación del cluster y en la respuesta a los latidos de los miembros del cluster. Sin embargo, las versiones recientes han mejorado la tolerancia a los retrasos en la comunicación a través de funciones como allowable variance. allowable variance define las variaciones de temporización permitidas en las comunicaciones de red dentro de un cluster de Coherence. Este parámetro configurable (maximum-time-variance), que se establece por defecto en 16 ms, establece la latencia máxima permitida para las comunicaciones UDP de tiempo de ida y vuelta (RTT). Coherence ajusta dinámicamente este valor en respuesta a las latencias o inconsistencias de red observadas, manteniendo la estabilidad y el rendimiento del cluster al acomodar mayores desviaciones en el tiempo esperado. El mensaje Increasing allowable variance to XX indica dicho ajuste. Consulte Elementos de configuración operativa en Desarrollo de aplicaciones con Oracle Coherence.
Con esta mejora en Oracle Coherence, no se informan errores en la formación del cluster si la latencia se mantiene dentro de los límites recomendados para la topología de cluster ampliado de FMW (<10 ms RTT). Pero aún así, los largos retrasos en los latidos del cluster pueden causar contención en los despliegues y malos tiempos de reacción a las interrupciones.
Si detecta errores en las operaciones o la formación del cluster de Coherence, puede ajustar los siguientes parámetros de timeout de red de Coherence:
<multicast-listener><join-timeout-milliseconds>. A pesar de estar diseñado originalmente para configuraciones de multidifusión, el impacto de tiempo de espera de unión también en unidifusión. Determina cuánto tiempo tardará el nodo inicial en formar un cluster y, después de eso, cuánto tiempo pasará cada nodo buscando el cluster antes de intentar formar el suyo propio (si están en la lista de WKA). El valor por defecto es 3000, en una red poco fiable puede que necesite aumentar este valor, para intentar durante un período de tiempo más largo encontrar un cluster antes de iniciar uno nuevo.<packet-publisher><packet-delivery><resend-milliseconds>. El intervalo de reenvío de paquetes especifica la cantidad mínima de tiempo, en milisegundos, que el editor de paquetes espera para un paquete ACK correspondiente, antes de reenviar un paquete. Este debe ser un par de múltiplos del RTT, 10x debe estar bien. El valor por defecto es 200.<packet-publisher><packet-delivery><timeout-milliseconds>. Para los paquetes que requieren confirmación, especifica la cantidad máxima de tiempo, en milisegundos, que se vuelve a enviar un paquete. Una vez que caduca este timeout, Coherence determina si el destinatario se va a considerar terminado. El valor por defecto de 5 min debe ser suficiente, pero puede aumentarlo para evitar timeouts al unirse al cluster.<packet-publisher><packet-delivery><heartbeat-milliseconds>Este parámetro es el intervalo de latidos para la detección de muerte de tcp-ring. El valor predeterminado de latido es 1 segundo. Puede aumentar el valor para aliviar el tráfico de red, pero esto también prolonga la detección de miembros con fallos.<tcp-ring-listener><ip-timeout>y<ip-attempts>. Estos son la cantidad de tiempo e intentos antes de determinar que un equipo que aloja miembros del cluster se ha vuelto inaccesible. El tiempo de espera de IP debe estar en el área de 10x el RTT o superior, con un mínimo de 5s.<cluster-config><tcp-ring-listener><enabled>. Incluso puede desactivar la detección de muertes por tcp-ring para aliviar el tráfico de red, pero también hace que la detección de miembros fallidos tarde más. Para desactivar la detección de muerte, configúrela en false. Si se desactiva, un miembro del cluster utiliza el intervalo de tiempo de espera de reenvío del editor de paquetes para determinar que otro miembro ha dejado de responder a los paquetes UDP (de forma predeterminada, establecido en 5 minutos).
Para modificar los valores de configuración por defecto, utilice un archivo de sustitución de Coherence. Cree un archivo denominado custom-coherence-override-<name>.xml y asegúrese de que sea coherente y accesible para todos los servidores del cluster. Especifique este archivo en la propiedad java tangosol.coherence.override. Puede definirla en la propiedad java EXTRA_JAVA_PROPERTIES en el archivo setUserOverrides.sh. Por ejemplo:
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dtangosol.coherence.override=/u01/oracle/config/coherence_custom/custom-coherence-override.xml"Ejemplo de archivo de sustitución de 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>
Ejemplo de archivo de sustitución de Coherence para ajustar el intervalo tcp-ring:
<?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>Ejemplo de archivo de sustitución de Coherence para desactivar la detección de muerte de tcp-ring:
<?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>
Configuración del rendimiento del servicio de red
Es posible que algunas configuraciones predeterminadas del sistema operativo no estén optimizadas, y es muy importante ajustar algunos parámetros para que la transferencia de datos sea más eficiente. Estos ajustes son especialmente significativos cuando hay una alta latencia entre los clientes y servidores JDBC. Los servidores que experimentan la latencia más alta en el acceso a la base de datos deben guiar la configuración de los buffers de red y los valores de Oracle Net Services para optimizar el rendimiento.
Una de las métricas clave para determinar la configuración óptima es el producto de retraso de ancho de banda (BDP). Representa la cantidad máxima de datos que pueden estar en tránsito en una red en cualquier momento dado. Se calcula multiplicando la capacidad (ancho de banda) de un enlace de red por su tiempo de retraso de ida y vuelta (latencia):
BDP = Bandwidth × Round-Trip Time (RTT)- RTT: en OCI, puede obtener el RTT medio entre regiones desde la página Latencia entre regiones en la consola de OCI. También puede determinar el tiempo de ida y vuelta (RTT) con comandos como ping de un host a otro durante unos minutos y utilizar los tiempos de respuesta devueltos.
- Ancho de banda: no hay un ancho de banda garantizado entre las regiones de OCI, y OCI no ofrece una herramienta de medición de ancho de banda de OCI específica. Para mediciones precisas de ancho de banda, puede utilizar herramientas como iPerf para realizar pruebas. El ancho de banda probado entre Frankfurt y Amsterdam es de alrededor de 2-2,5 Gbps.
La configuración del buffer de socket TCP controla cuántos paquetes se envían a la vez a través de la red. Para lograr un rendimiento óptimo, se recomienda establecer el tamaño del buffer de socket al menos en el BDP. En muchos casos, establecer el tamaño del buffer en el doble del BDP puede mejorar aún más el rendimiento, especialmente en redes de alta latencia. Sin embargo, los buffers excesivamente grandes pueden aumentar el uso de memoria. Por lo tanto, es aconsejable establecer el tamaño del buffer dentro del rango del BDP a tres veces el BDP:
BDP ≤ Socket Buffer Size ≤ 3 × BDPConfiguración de Tamaños de Buffer de E/S en la Base de Datos
SEND_BUF_SIZE en el servidor suele ser suficiente.
Si el servidor de base de datos está recibiendo solicitudes grandes, defina también el parámetro RECV_BUF_SIZE. Se recomienda ajustarlos en el nivel de Oracle Net Services de la base de datos en lugar del nivel del sistema operativo, para que las sesiones de TCP normales, como SSH, etc., no utilicen memoria adicional.
Para configurar estos parámetros para el servidor de base de datos, defina el tamaño del espacio de buffer en los archivos listener.ora o sqlnet.ora.
-
En el archivo
listener.ora, especifique los parámetros de espacio de buffer para una dirección de protocolo concreta o para una descripción. A continuación se muestra un ejemplo de la configuración de un listener de Oracle RAC típico en un sistema de base de datos base en 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)))) -
Si los parámetros se definen en
sqlnet.ora, se aplican globalmente a todos los listeners. A continuación, se muestra un ejemplo de la configuración del archivosqlnet.ora:RECV_BUF_SIZE=10485760 SEND_BUF_SIZE=10485760
Configuración de Tamaños de Buffers de E/S en Nodos de Capa Media
El sistema operativo Linux utiliza el ajuste automático tanto para el buffer de recepción como para el de remitente.
Para el buffer de recepción, el ajuste automático está determinado por el parámetro /proc/sys/net/ipv4/tcp_moderate_rcvbuf. Si el parámetro tiene un valor de 1, se activa el ajuste automático. Con el ajuste automático, el tamaño del buffer del receptor (y el tamaño de la ventana TCP) se actualiza dinámicamente para cada conexión, con un tamaño de buffer máximo de 4 MB.
Para el buffer de remitente, el ajuste automático también está activado por defecto. Aunque el ajuste automático del buffer de recepción se puede controlar mediante el parámetro tcp_moderate_rcvbuf, el ajuste automático del buffer de envío no tiene un conmutador directo. Al definir tamaños de buffer fijos, se desactiva el ajuste automático del buffer de envío.
Estos procesos de ajuste automático se rigen por varios parámetros del núcleo que gestionan la asignación de memoria para enviar y recibir datos:
- Por tamaños de buffer de conexión
La asignación de memoria para cada conexión TCP se define mediante dos parámetros:
/proc/sys/net/ipv4/tcp_rmem, que especifica la memoria reservada para los buffers de recepción de TCP./proc/sys/net/ipv4/tcp_wmem, que especifica la memoria reservada para los buffers de envío TCP.
Ambos parámetros aceptan tres valores:
- Tamaño mínimo de buffer: el tamaño de buffer más pequeño asignado para un socket TCP.
- Tamaño de Buffer por Defecto: el tamaño de buffer inicial asignado a un socket TCP tras la creación.
- Tamaño máximo de buffer: el tamaño de buffer más grande que se puede asignar automáticamente para un socket TCP.
Estos valores establecen los límites para los mecanismos de ajuste automático y ayudan a equilibrar el uso de memoria, especialmente durante los períodos de esfuerzo de memoria.
- Tamaños de buffer por aplicación
Las aplicaciones pueden solicitar tamaños de buffer específicos, pero estas solicitudes están sujetas a los límites definidos por los siguientes parámetros:
/proc/sys/net/core/rmem_max, es la ventana de recepción máxima, que define el límite superior para el tamaño de buffer de recepción que pueden solicitar las aplicaciones./proc/sys/net/core/wmem_max, es la ventana de envío máxima, que define el límite superior para el tamaño de buffer de envío que pueden solicitar las aplicaciones.
Para ajustar los tamaños de buffer de E/S:
El ajuste automático de TCP permanece activado con límites de tamaño para el producto de retraso de ancho de banda de la red, lo que mejora el rendimiento sin sobredimensionar el uso de la memoria del sistema.
Configuración del Tamaño de Unidad de Datos de Sesión
Oracle Net Services espera a que estas unidades se completen antes de enviarlas a través de la red. Cada uno de estos buffers es una unidad de datos de sesión (SDU). Ajustar el tamaño de la SDU a la cantidad de datos proporcionados a Oracle Net Services puede mejorar el rendimiento, la utilización de la red y el consumo de memoria en un cluster ampliado de Oracle Fusion Middleware con latencias superiores a 5 ms RTT.
El tamaño de la SDU se puede establecer de 512 bytes a 2 MB. En Oracle Database 23ai, el tamaño predeterminado de la SDU es 64 KB (65.536 bytes). Las versiones anteriores de la base de datos establecen el tamaño predeterminado de la SDU en 8 KB.
El tamaño real de SDU utilizado se negocia entre el cliente y el servidor en el momento de la conexión y es el menor de los dos valores. La configuración de un tamaño de SDU diferente del predeterminado requiere la configuración de la SDU en los equipos cliente y servidor. Oracle recomienda definir la SDU en el valor máximo posible (64k).
Los clientes y los servidores negocian la SDU en el momento de la conexión; la configuración de ambos lados garantiza que se utilice la SDU deseada.