Hi,
This is definetely not easy subject - that is why I am coming back.
I was complaining on memory leaks, but there may not be any memory leaks
:)
Can anyone explain me what "Free" and "Used" means in below output:
858 16 rx0044 3981556 Port 858 details at 06:08:08 06
FEB 2009
Thread type Normal
Usage Count 72 from 100K
Application Open Files 14654 , Actual
O/S Open Files 181
Memory: Free 43,755,392 Used
2,095,398,288
READ's 192042 , WRITE's 14167
DELETE's 1315 , CLEARFILE's 0
EXECUTE's 3 , INPUT's 0
OPEN's 14676
---- jsh -Jb -c tSA 60
Program performing EXECUTE/PERFORM at
jsh.b,59
---- tSA 60
Program running normally at F.WRITE,72
I am asking because if process will free say 1,8 GB situation will not
change from OS level. Memory once allocated (disregarding from "Free" /
"Used" jBASE indicator) seems not to be given to other processes. Why?
In this way it may happen that multiple processes had their own "peaks"
in processing and each one allocated (but is not longer using) 1 GB.
Then memory runs out.
So why "Free" is not free? I am completely lost :(
Kind regards
Pawel
Dnia 6-02-2009 o godz. 1:47 mike ryder napisał(a):
> Hi Pawel,
>
> I know from previous posts that this is T24 related.
>
> You don't state which T24 release or on which table you are doing the
> select or even if this is Temenos core code or your own local code.
>
> The reason why this may be significant is as follows:
>
> 1. SSELECT on SECURITY related tables can cause a problem. I have seen
> such on SECURITY.POSITION. It occurs because the dictionary says that
> the ID is right justified in 35 spaces and all of the keys take up 35
> characters and you run out of memory. Changing the dictionary to left
> justified solves the problem.
>
> 2. If this is local dev, then doing an internal select can be much
> faster. Where you expect to retrieve more than 50% of the keys and the
> condition is based on the key, then an internal select with code will
> be much faster and not hog the memory.
>
> 3. In local dev, many people try to do all of the processing in one
> job when it would be more performant to select in one agent process
> and process the keys in another. As an addendum to this, if you do
> humongous processing in a job with transaction turned on all sorts of
> memory issues occur.
>
> 4. The selection operation used by EB.READLIST has changed in later
> releases (R6 or maybe R7) where internal select is used if the select
> statement is called without parameters
>
> 5. I believe that SSELECT can be called as an internal selection
> rather than an external selection which means that all of the keys are
> not require to be stored before they can be processed/
>
> Hope this is of interest
> Mike
----------------------------------------------------
Nużą Cię utarte scenariusze?
Wymyśl własną grę flashową i wygraj główną nagrodę 5.500 Euro:
http://klik.wp.pl/?adr=http%3A%2F%2Fwhosegame.pl%2Fcontestcard.php%3Fcontest%3D55&sid=631
--~--~---------~--~----~------------~-------~--~----~
Please read the posting guidelines at:
http://groups.google.com/group/jBASE/web/Posting%20Guidelines
IMPORTANT: Type T24: at the start of the subject line for questions specific to
Globus/T24
To post, send email to [email protected]
To unsubscribe, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
-~----------~----~----~----~------~----~------~--~---
