Fondamentalement, la stratégie par défaut d'Oracle pour les jars ojdbc récents consiste à "pré-allouer" un tableau par ligne "prefetch" qui s'adapte à la plus grande taille possible à renvoyer à partir de cette requête. Pour toutes les rangées. Donc, dans mon cas, j'avais du VARCHAR2 (4000) là-dedans, et 50 threads (Statements) * 3 colonnes de varchar2 * 4000 totalisaient plus de gigaoctets de RAM avec un setFetchSize de quelques centaines [yikes]. Il ne semble pas y avoir d'option pour dire "ne pré-allouez pas ce tableau, utilisez simplement la taille au fur et à mesure qu'ils arrivent". Ojdbc conserve même ces tampons préalloués autour entre les instructions préparées (en cache/connexion) afin qu'il puisse les réutiliser. Certainement un porc de mémoire.
Une solution :utilisez setFetchSize à une somme raisonnable. La valeur par défaut est 10, ce qui peut être assez lent sur les connexions à latence élevée. Profilez et n'utilisez que le maximum de setFetchSize qui permet réellement d'améliorer considérablement la vitesse.
Une autre solution consiste à déterminer la taille réelle maximale de la colonne, puis à remplacer la requête par (en supposant que 50 est la taille réelle maximale connue) select substr(column_name, 0, 50)
Autres choses que vous pouvez faire :diminuer le nombre de lignes de prélecture, augmenter java -Xmx paramètre, ne sélectionnez que les colonnes dont vous avez réellement besoin.
Une fois que nous avons pu utiliser au moins la prélecture 400 [assurez-vous de profiler pour voir quels chiffres sont bons pour vous, avec une latence élevée, nous avons vu des améliorations jusqu'à la taille de prélecture 3-4K] sur toutes les requêtes, les performances se sont considérablement améliorées.
Je suppose que si vous vouliez être vraiment agressif contre les lignes clairsemées "très longues", vous pourriez être en mesure de relancer la requête lorsque vous rencontrez ces [rares] grandes lignes.
Détails ad nauseum ici
