Básicamente, la estrategia predeterminada de Oracle para los archivos jar ojdbc recientes es "preasignar" una matriz por fila de "búsqueda previa" que se adapte al tamaño más grande posible para devolver de esa consulta. Para todas las filas. Entonces, en mi caso, tenía algunos VARCHAR2 (4000) allí, y 50 subprocesos (Declaraciones) * 3 columnas de varchar2 * 4000 sumaban más de gigabytes de RAM con un setFetchSize de unos pocos cientos [yikes]. No parece haber una opción para decir "no asigne previamente esa matriz, solo use el tamaño a medida que entran". Ojdbc incluso mantiene estos búferes preasignados alrededor de entre declaraciones preparadas (en caché/conexión) para que pueda reutilizarlos. Definitivamente un acaparador de memoria.
Una solución alternativa:use setFetchSize a una cantidad razonable. El valor predeterminado es 10, que puede ser bastante lento en conexiones de alta latencia. Perfile y use solo setFetchSize tan alto como realmente logre mejoras significativas en la velocidad.
Otra solución es determinar el tamaño real máximo de la columna y luego reemplazar la consulta con (suponiendo que 50 es el tamaño real máximo conocido) select substr(column_name, 0, 50)
Otras cosas que puede hacer:disminuir el número de filas de captación previa, aumentar java -Xmx parámetro, solo seleccione las columnas que realmente necesita.
Una vez que pudimos usar al menos la captación previa 400 [asegúrese de crear un perfil para ver qué números son buenos para usted, con una latencia alta vimos mejoras hasta un tamaño de captación previa de 3-4K] en todas las consultas, el rendimiento mejoró drásticamente.
Supongo que si quisiera ser realmente agresivo con las filas dispersas "realmente largas", podría volver a consultar cuando se encuentre con estas [raras] filas grandes.
Detalles hasta la saciedad aquí
