Oracle T4CPreparedStatement pierde memoria?

Question

Un poco de historia sobre la aplicación que estoy a hablar de las siguientes líneas:

XYZ es un banco de trabajo enmascaramiento de datos del eclipse de aplicación RCP: le das una columna de tabla de origen, y una tabla de destino columna, aplicaría una transformación (encriptación/mezcla/etc.) y copiaría los datos de la fila de la tabla de origen a la tabla de destino. Ahora, cuando enmascare n tablas a la vez, esta aplicación lanza n hilos.

Aquí es la cuestión:

se han topado con un problema de producción en el primer despliegue de la aplicación anteriormente dicho. Lamentablemente, no tengo ningún registro para llegar a la raíz. Sin embargo, traté de ejecutar esta aplicación en la región de prueba y hacer una prueba de estrés.

Cuando recogí archivos .hprof y los ejecuté a través de un analizador (suKit), noté que los objetos de oracle.jdbc.driver.T4CPreparedStatement mantenían el montón. El análisis también me dice que una de mis clases contiene una referencia a este objeto preparado y, por lo tanto, n hilos tienen n tales objetos. T4CPreparedStatement parecía tener matrices de caracteres: lastBoundChars y bindChars cada uno de los tamaños char [300000].

Entonces, investigué un poco (google!), Obtuve ojdbc6.jar e intenté descompilar T4CPreparedStatement. Veo que T4CPreparedStatement amplía OraclePreparedStatement, que gestiona dinámicamente el tamaño de la matriz de lastBoundChars y bindChars.

Por lo tanto, mis preguntas aquí son:

1. ¿Alguna vez ha topado con un problema como este ?
2. ¿Conoces la importancia de lastBoundChars/bindChars?
3. Soy nuevo en la creación de perfiles, ¿así que usted piensa que no lo estoy haciendo bien? (También me encontré con los hprofs través MAT - y este era el principal problema identificado - así, yo realmente no creo que podría estar equivocado?)

he encontrado algo similar en la web aquí : http://forums.oracle.com/forums/thread.jspa?messageID=2860681

Valora tus sugerencias/consejos.

Answer 1

Mientras sea posible, parece poco probable que haya encontrado una gran pérdida de memoria en 11g. Comenzaría obteniendo el SQL actual de los cursores filtrados y buscando el código donde se crea ese SQL. Una causa muy común de cursores filtrados he encontrado en el pasado es el código de la siguiente manera:

try { 
PreparedStatment stmt = null; 
stmt = con.prepareStatement("SOME AWESOME SQL"); 
//lots of lines of code that masks the problem 
stmt = con.prepareStatment("DIFFERENT SQL"); //You just leaked "SOME AWESOME SQL"!!! 
//lots more code 
} finally { 
stmt.close() //looks like everything is ok, but only the second one actually got closed 
} 

Answer 2

me encontré con el mismo problema. Aunque la fuga de Affe podría ser el problema, ese no era mi problema y encontré una respuesta diferente después de algunas excavaciones:

El controlador JDBC de Oracle mantiene buffers en los que los datos se leen como una optimización del rendimiento. El tamaño del búfer se calcula en función del tamaño de fila máximo posible (por lo que VARCHAR(2000) asignaría algo así como 2000 char s), multiplicado por el tamaño de búsqueda de JDBC. Esto permite que el controlador lea datos directamente en el búfer, en lugar de asignar a pedido lo que (al parecer) sería más lento.

Cada declaración preparada dentro de cada conexión mantiene un búfer de este tipo. Si está utilizando una gran agrupación de conexiones con almacenamiento en caché de sentencias (o almacena en caché los objetos PreparedStatement manualmente, o los filtra ...), puede consumir rápidamente un montón de espacio libre. ¡1.6GB en mi caso!

Todo esto es explicado por Oracle a sí mismos en un PDF here

Mi experiencia se basa en el conductor 11.2.0.3.