Temat: Problemik

Nic się w tym wątku nie dzieje więc coś trzeba było w końcu napisać :)
Temat ogólny, poddany pod dyskusje, proszę o luźne refleksje.

Apex 4.1
ApexListener 1.0
Database 11.2.0.1 64bit Windows 2003 EE

Osobiście nie znam apexa w ogóle i można nawet by rzec, że się nim nie zajmuje no ale jest problem i trzeba go rozwiązać :)

Ogólnie, aplikacja apexa często "zamula"

Co widać na bazie...
waity: library cache lock- > library cache pin -> cursor: pin S wait on X ( nie wiem czy nie chodzi tutaj o "wait na child cursor")
Instrukcja: "begin wwv_flow_log.g_content_length := sys.htp.getcontentlength; end;"
lub instrukcja" "begin f(p=>:1); commit; end;"

select sql_id, count(*)
from v$sql_shared_cursor
group by sql_id
having count(*) > 50
order by 2 desc;
-- większość poleceń zwracanych przez to zapytanie to APEX np:
UPDATE WWV_FLOW_DATA SET ITEM_VALUE = TO_CHAR(:B5 ,:B4 ) WHERE FLOW_INSTANCE = :B3 AND ITEM_ID = NVL(:B2 ,:B1 )
SELECT ID,ON_NEW_INSTANCE_FIRED_FOR,SESSION_LANG,SESSION_TERRITORY FROM WWV_FLOW_SESSIONS$ WHERE ID = :B1
INSERT INTO WWV_FLOW_SESSIONS$ ( ID, ON_NEW_INSTANCE_FIRED_FOR, COOKIE, REMOTE_ADDR ) VALUES ( :B3 , NULL, NVL(:B2 ,'nobody'), :B1 )

Ponadto występują też waity na "virtual circuit wait". Czy to pojawia wtedy kiedy jest wystartowania za mała ilość shared servers i nie ma co obsłużyć żądania? czasami zwiesza się na tym "zdarzeniu oczekiwani" sesja i potrafi wisieć całe dnie :D jedynie orakill pomaga.

Analizując dane z v$shared_server_monitor i v$sga_resize_ops(częste operacje GROW/SHRINK na large pool) wnioskuje, że parametr shared_servers jest ustawiony za mały. Na początku dnia kiedy wszyscy się logują mogą przez to wystąpić problemy ... startowanie nowych procesów shared server i blokady na pamięci aby zwiększyć large pool ( Czy z tego powodu mogę otrzymywać cursor: pin S wait on X :/ ?) Czy ktoś praktykuje dynamiczne zmienianie tego parametru np. o godzinie 5.00 ustawiamy wartość 3*X, a o 18.00 na wartość X?

Jak wspominałem do apexa mam bardzo daleko ale zastanawiam się czy dane z v$reqdist powinny zwracać takie wyniki?
BUCKET COUNT
0, 812716
1, 0
2, 17183
3, 13905
4, 1748
5, 2838
6, 1012
7, 371
8, 694
9, 1070
10, 481
11, 70
Jak to jest z tymi aplikacjami "webowymi", czy powinny mieć takie długie żądania? Szczególnie przy konfiguracji SHARED SEVERS? Jak "Im" to ograniczyć bez wykorzystania Database Resource Manager?

Reasumując
Zeminie wartość parametru shared servers i zobaczę co się będzie działo..

Pozdrawiam
OskarOskar Graliński edytował(a) ten post dnia 11.03.11 o godzinie 14:45

Temat: Problemik

No ja myślałem, że to będzie dobry temat na dyskusje... a tu cisz, tylko ja mam takie problemy czy nie widzę oczywistego rozwiązania? :)

chyba będę musiał przeprowadzić monolog...

Zmiana parametru shared_sever, shared_server_sessions i ustawienie minimalnej wartości dla large pool troszkę pomogło ale wydaje mi się, że bardziej pomógł restart servera :)

A mam też inny problemik z tym apexem.... użytkownik APEX_PUBLIC_USER systematycznie zżera tempa i nic w nim nie zwalnia.. mimo że przez noc nikt na apexie nie pracuje, czym może być to spowodowane?

Aby temu zapobiec musiał ustawić na profilu "autologoff" i joba, który odłącza te sesje
FOR vrec IN (select sid, serial# serial from v$session where STATUS='SNIPED') LOOP
EXECUTE IMMEDIATE('ALTER SYSTEM DISCONNECT SESSION '''||vrec.sid||','||vrec.serial||''' IMMEDIATE');
END LOOP;

Wydaje mi się że przez ten manewr odłączania sesji zostają mi rekordy w v$circuit, mimo że połączenia już nie ma. Może to jest przyczyną "virtual circuit wait", na razie czekam aż to wszystko sie rozkręci i "pozapycha"

Wszystko jakoś na okrętkę ale nie wiem co jest przyczyną tego tempa i jak to znaleźć, a poradzić sobie musiałem.

Pozdrawiam
Oskar

Temat: Problemik

Cisza na temat pierwszego postu była bo część pewnie nie zagląda, a reszta nie wiedziała co odpisać - ja nie wiedziałem.
Z zżeraniem tempa miałem to samo na środowisku developerskim, na testowym albo nie było albo tam nie zaglądałem, a produkcji jeszcze nie uruchomiłem, więc nie mam doświadczeń w rozwiązywaniu tematu.
Miałem wrzucić link do forum APEX Listenera, ale widzę, że nie muszę :-), chociaż jak na razie jeszcze temat nie jest rozwiązany.

Pozdro
Paweł

P.S.
Wydaje mi się, że jak mi się temp przepełnił, to dostawałem błąd http status 500, ale tylko na środowisku dev i nie miałem czasu na walkę z tym.

Temat: Problemik

Odnośnie tempa to ktoś już zgłosił w tej sprawie SR
http://forums.oracle.com/forums/thread.jspa?threadID=2...
więc cierpliwie czekam..

Temat: Problemik

Problem z waiteami rozwiązany (cursor: pin S wait on X) i apex już nic nie muli.

Był to o oczywiste jeden z wielu bug-ów związanych z przejściem latches->mutexes (więcej rozpisywać się nie będę :) ).

Po upgrade z 11.2.0.1 na 11.2.0.2 wszystkie problemy "znikły", a ja nic nie musiałem zmieniać :)

Pozostaje nadal problem TEMPa.

Pozdrawiam
Oskar

Temat: Problemik

Na forum Apex Listenera pojawiła się sugestia rozwiązania problemu TEMPa.

W pliku apex-config.xml zmienić wartość: apex.jdbc.MaxConnectionReuseCount

Domyślną wartość 50000 można zmienić na 1000 (domyślna wartość równoważnego ustawienia w mod_plsql).

Pozdro
Paweł

Temat: Problemik

Zmieniłem, sprawdzę w praniu i dam znać

Pozdrawiam
Oskar

Temat: Problemik

Wygląda na to że sugestia "Colm Divilly" była trafna, po zmianie parametru wszystko wróciło do normy i nie ma już problemu z TEMPem.

Temat można uznać za zamknięty - wszystkie problemy rozwiązane :)

Pozdrawiam
Oskar