Zasadniczo, domyślną strategią Oracle dla ostatnich plików jar ojdbc jest "wstępne przydzielenie" tablicy na wiersz "pobrania z wyprzedzeniem", który pomieści największy możliwy rozmiar, jaki może zostać zwrócony z tego zapytania. Dla wszystkich rzędów. Tak więc w moim przypadku miałem tam trochę VARCHAR2 (4000), a 50 wątków (Statements) * 3 kolumny varchar2 * 4000 sumowały się do ponad gigabajtów pamięci RAM z setFetchSize równym kilkaset [yikes]. Wygląda na to, że nie ma opcji, aby powiedzieć „nie przydzielaj wstępnie tej tablicy, po prostu użyj rozmiaru, jaki przyjdą”. Ojdbc przechowuje nawet te wstępnie przydzielone bufory między przygotowanymi instrukcjami (z pamięci podręcznej/połączenia), aby mógł je ponownie wykorzystać. Zdecydowanie wieprz pamięci.
Jedno obejście:użyj setFetchSize do pewnej rozsądnej kwoty. Wartość domyślna to 10, co może być dość powolne w przypadku połączeń z dużymi opóźnieniami. Profiluj i używaj tylko tak wysokiej wartości setFetchSize, jak faktycznie powoduje znaczną poprawę szybkości.
Innym obejściem jest określenie maksymalnego rzeczywistego rozmiaru kolumny, a następnie zastąpienie zapytania (zakładając, że 50 to znany maksymalny rzeczywisty rozmiar) select substr(column_name, 0, 50)
Inne rzeczy, które możesz zrobić:zmniejszyć liczbę wierszy pobierania z wyprzedzeniem, zwiększyć java -Xmx parametr, wybierz tylko te kolumny, których faktycznie potrzebujesz.
Gdy byliśmy w stanie użyć co najmniej 400 preselekcji [pamiętaj, aby profilować, aby zobaczyć, jakie liczby są dla Ciebie dobre, z dużym opóźnieniem zauważyliśmy ulepszenia do rozmiaru wstępnego pobierania 3-4 KB] we wszystkich zapytaniach, wydajność znacznie się poprawiła.
Przypuszczam, że jeśli chcesz być naprawdę agresywny wobec rzadkich „naprawdę długich” wierszy, możesz być w stanie ponownie wykonać zapytanie, gdy natkniesz się na te [rzadkie] duże wiersze.
Szczegóły reklamy nudy tutaj
