[JAVA] Interbase 6.0...out of virtual memory

[yrew]

Na een succesvolle start van ons kassatransactiesysteem krijgen we steeds regelmatiger de melding dat windows out of virtual memory is.

Het is gebleken dat IBServer het meeste geheugen verbruikt. Hieronder staan de zaken die evt aan IBServer ‘getweaked’ kunnen worden

- Wanneer connecties open blijven staan wordt het geheugen ook niet vrij gegeven. Dit probleem kan zich voordoen wanneer in het verleden de database transacties naar de BDE toe werden gespeeld. Beter is het om zelf alle transactie’s te controleren.

- ????

De implementatie

Het feit dat IBServer veel geheugen verbruikt kan voortvloeien uit de implementatie van de database statements in de software. Hieronder staan op en aanmerkingen om op dit gebied de performance optimaal te houden.

- Bij het wijzigen van de gegevens wordt alles in het geheugen gehouden tot er een commit volgt. Het is dus van belang dit tijdig te doen. Als je pas een commit geeft bij het eindigen van een proces, kan dat problemen geven. De eerste tien keer dat het programma draait zul je niets merken, maar wanneer de gegevens aangroeien gaat dit proces steeds meer resources in beslag nemen. Een counter die het aantal wijzigingen/transacties bijhoudt en om de x aantal keren een commit geeft kan een oplossing zijn.

- ?????

Ik ben benieuwt of er hier mensen zijn die dit probleem herkennen en of ze er een oplossing/workaround voor weten....?

[whoami]

Hmm. Die problemen zullen niet zozeer aan IB zelf te wijten zijn denk ik, eerder aan jullie programma.

Zorg ervoor dat je connecties altijd sluit, transacties mogen niet te lang duren (open transactie, wijzig gegevens, commit transactie, en dit doe je dus best allemaal na elkaar (bv. in een onclick event van een save button).

[yrew]

Er zullen inderdaad wel wijzigingen plaats moeten vinden in onze implementatie, maar er zijn vast ook interbase specifieke dingen die je kan wijzigen.

We maken gebruik van connectionpool en tot dusver wordt ik doodgekeken als ik begin over niet gesloten connecties begin, de man die het inmekaar gezet heeft is er heilig van overtuigd dat hij goed omspringt met resources.

Denk overigens niet dat ik niet ergens zelf aan het zoeken ben hoor...maar ik hoop hier toch die ene nederlands sprekende wizzkid te vinden die dat ene parametertje uit legt.

[whoami]

[nohtml]

yrew schreef op 07 januari 2003 @ 11:05:
Er zullen inderdaad wel wijzigingen plaats moeten vinden in onze implementatie, maar er zijn vast ook interbase specifieke dingen die je kan wijzigen.

Ik denk toch dat je eerst en vooral naar uw implementatie moet kijken, en dan pas naar eventuele configuratie instellingen van IB.
De meeste problemen zullen wel door uw code veroorzaakt worden.

We maken gebruik van connectionpool en tot dusver wordt ik doodgekeken als ik begin over niet gesloten connecties begin, de man die het inmekaar gezet heeft is er heilig van overtuigd dat hij goed omspringt met resources.

Waarom sluit je niet al je connecties? Dat is niet goed omspringen met resources.
Als je gebruik maakt van connection-pooling kan je beter een connectie sluiten als je die niet meer nodig hebt.

[yrew]

Ok...dat zal ik eens voorstellen hoewel er volgens mij een duidelijke reden was waarom de connecties open moetsen blijven.

Ik heb net nogeens de processen goed bekeken en het viel me op dat het voornamelijk select statements zijn. Nemen deze queries evenveel resources in als update queries ???? Er wordt in geen geval een select * from x.

Bedankt tot dusver, ik had ook gedacht aan die pool, maar ik begin hier net. Om dan meteen moeilijk te gaan doen over zo'n onderdeel voor ik echt heel zeker ben van mijn zaak zie ik niet zitten. Nog wat extra argumenten bij mekaar sprokkelen en het begin is er.

[ Voor 28% gewijzigd door yrew op 07-01-2003 11:17 ]

[whoami]

yrew schreef op 07 januari 2003 @ 11:14:

Ik heb net nogeens de processen goed bekeken en het viel me op dat het voornamelijk select statements zijn. Nemen deze queries evenveel resources in als update queries ???? Er wordt in geen geval een select * from x.

Als je een select doet, dan moet de DBMS de opgevraagde data returnen naar de client. Dat vergt wel wat netwerk-traffic, maar eens de gegevens opgehaald zijn uit de tabellen, worden de gebruikte resources afaik weer vrijgegeven.

[Verwijderd]

whoami schreef op 07 January 2003 @ 11:16:

[...]


Als je een select doet, dan moet de DBMS de opgevraagde data returnen naar de client. Dat vergt wel wat netwerk-traffic, maar eens de gegevens opgehaald zijn uit de tabellen, worden de gebruikte resources afaik weer vrijgegeven.

Als er 2 phase locking toegepast wordt wel ja. Bij een SELECT wordt er dan ook alleen maar een write-lock geplaatst.

[yrew]

ok dat is handig om te weten (db's zijn voor mij echt nog een groot grijs gebied) Wordt het wel moeilijker als er 50 kolommen per tabel zijn? Cruciaal moeilijker dan.

Beetje jammer dat ik dit precies aan het uitzoeken ben wanneer de verantwoordelijke ontwikkelaar (incl source) thuis zit....

Was da? Two phase locking?

[ Voor 6% gewijzigd door yrew op 07-01-2003 11:26 . Reden: vraagje over two phase locking ]

[whoami]

[nohtml]

yrew schreef op 07 January 2003 @ 11:22:
ok dat is handig om te weten (db's zijn voor mij echt nog een groot grijs gebied) Wordt het wel moeilijker als er 50 kolommen per tabel zijn? Cruciaal moeilijker dan.

Nee.

[Verwijderd]

Er worden toch niet toevallig (per ongeluk) Carthesian products opgevraagd he ??

[ Voor 12% gewijzigd door Verwijderd op 07-01-2003 11:29 ]

[yrew]

HUH??!?!?!? cathesian ?

one day you can visit my condo, on the big hill you know like nine o two one o.

[whoami]

Verwijderd schreef op 07 januari 2003 @ 11:29:
Er worden toch niet toevallig (per ongeluk) Carthesian products opgevraagd he ??

Dan zouden die queries wel merkelijk trager gaan lopen.

't Is misschien zowiezo ook een idee om eens je queries van dichtbij te gaan bekijken. Waar kun je ze tweaken? Haal je enkel de nodige gegevens op? Gebruik je indexen? etc...

[whoami]

yrew schreef op 07 januari 2003 @ 11:30:
HUH??!?!?!? cathesian ?

one day you can visit my condo, on the big hill you know like nine o two one o.

Bv:

code:

SELECT *
FROM tabel1, tabel2

zal leiden tot een cartesiaans product. Je haalt nl. de gegevens op van tabel1 en tabel2, maar je specifeert niet hoe deze moeten gejoined worden.
Het DBMS zal dus aantal records in tabel1 x aantal records in tabel 2 returnen.
(Voor ieder record in tabel1, zal ieder record in tabel 2 opgehaald worden).

[yrew]

Many thnx....Ik zal zodra de dag van morgen weer begint met een bak espresso uit de koffieautomaat meteen vragen om het database gedeelte te mogen bekijken. Hij is er alleen nu niet en de boel is iets te complex om het zelf te pakken :-s.

Dit is wel de info waar ik naar op zoek ben. Nice one!!!

aaaah ok...Dat heb ik 1 keer eerder gehad met access, maar ik denk niet dat deze fout in dit geval gemaakt is.

[ Voor 17% gewijzigd door yrew op 07-01-2003 11:36 ]

[yrew]

kan iemand mij uitleggen wat ik hieruit af kan leiden?
Database header page information:
Flags 0
Checksum 12345
Generation 3313
Page size 1024
ODS version 10.0
Oldest transaction 2675
Oldest active 3302

Oldest transaction en oldest active ben ik benieuwd naar. Wat is bijv de eenheid van die cijfers...?

[ari3]

Wanneer je veel geheugen gebruikt kun je vaak de instellingen van de JVM tweaken zodat ie meer beschikbaar heeft. Ik heb een soortgelijk probleem gehad met in het geheugen houden van heel veel query-resultaten. Toen bleek dat de Sun JVM implementatie standaard maximaal 1/2 van het fysieke geheugen gebruikt. Toen de heapsize verdubbeld werd was het probleem er niet meer

Dit geeft een overzicht van de opties voor de Sun JVM, zijn zeer waarschijnlijk anders als je een andere smaak JVM gebruikt:

code:

java -X

[whoami]

[nohtml]

ari3 schreef op 07 January 2003 @ 13:59:
Wanneer je veel geheugen gebruikt kun je vaak de instellingen van de JVM tweaken zodat ie meer beschikbaar heeft. Ik heb een soortgelijk probleem gehad met in het geheugen houden van heel veel query-resultaten. Toen bleek dat de Sun JVM implementatie standaard maximaal 1/2 van het fysieke geheugen gebruikt. Toen de heapsize verdubbeld werd was het probleem er niet meer

Hmmm, ja...
Maar ik denk toch dat dit een van de allerlaatste stappen mag zijn die je neemt. Eerst je eigen code tweaken, redesignen whatever....
(Zoals die connecties die niet worden afgesloten... )

[yrew]

ok...ik heb net weer het zelfde probleem gehad en tussen mijn oudste transactie en mijn laatst actieve connectie zat 12000.

Ik weet alleen niet waar die 12000 voor staat...zijn dit appels of koeien of seconden ?????

[yrew]

2 ari: Het zou evt. Een oplossing kunnen zijn, maar wel 1 van de laatste...Dit is gewoon een structurele fout die in de code opgelost dient te worden

[yrew]

sorry...heb dit antwoord nog steeds niet gevonden.....
Flags 0
Checksum 12345
Generation 3313
Page size 1024
ODS version 10.0
Oldest transaction 2675
Oldest active 3302

deze info komt uit interbase maar ik kan nergens vinden wat de eenheid van die cijfers is.

[yrew]

laaste kick

[Bobco]

Heb de thread even snel doorgelezen, maar niet in detail. Negeer dus opmerkingen van mijn kant die al door anderen zijn geplaatst.

Als je zegt dat IBserver het meeste geheugen gebruikt is dat inderdaad de meest geschikte kandidaat om mee te beginnen. Een database server heeft resources nodig voor het bijhouden van connecties en wat er aan statements voorbijkomtl. Dit is inclusief de nodige caching.

Als je database server de geest geeft omdat er te weinig geheugen is, kun je volgens mij drie dingen doen:

1. meer geheugen bijprikken (als het mogelijk is). Dit is vaak veruit de goedkoopste oplossing. Dit is niet structureel, maar verplaatst het probleem. Als je mazzel hebt zie je het probleem dan niet meer, ondanks dat het er natuurlijk nog steeds is.
2. Regelmatig de database server down en up gooien om resources vrij te maken. Niet echt professioneel en ook geen structurele oplossing.
3. Kijken welke resources er gebruikt worden en of er wel resources worden vrijgegeven.

Ik ken Interbase niet, maar de meeste databases hebben de mogelijkheid om te laten zien hoeveel sessies/connecties er openstaan en wanneer deze voor het laatst actief zijn geweest. Zijn dit er enorm veel dan moet je toch kritisch gaan kijken naar de manier waarop je applicatie omgaat met de connection pooling.

Kijk ook nog eens naar de manier waarop je JDBC driver omgaat met dingen als PreparedStatements. De JDBC driver die Microsoft levert voor SQL Server opent bijvoorbeeld een connectie per PreparedStatement dat je klaarzet. Dat gaat vrij snel oplopen als je applicatie parallel in 10 threads de database wil benaderen...

Connection pooling is mooi, maar niet iets om blind op te vertrouwen. Als jullie code zo in elkaar is gezet dat de data access gebeurt door eerst een connectie uit de pool te halen, dan de query uit te voeren en vervolgens de connectie terug geven aan de pool dan zul je toch kritisch moeten kijken naar de connection pooling code.

Succes!

[yrew]

Bedankt voor de uitleg.....Ik kies voor het laatste. Ik had de info over de connecties die in leven waren en voor het laatst gebruikt teruggevonden in ibserver maar er staan wat cijfertjes...maar nergens staat de eenheid van die getallen.

Volgende week ga ik eens kijken naar dat pooling....lijkt me leuk als ik met een beter concept kan komen...