Hi Jim,

Dnia 17-03-2009 o godz. 0:37 Jim Idle napisał(a):
> Pawel (privately) wrote:
> > Hi,
> >
> > This is not a file corruption I think.
> >
> > Please try to observe memory allocation during runing this select. Use
> > MW42 -m -P<port_number_of_your_session> to monitor MemFree and MemUsed
> > values. Let us know what is behaviour (how they change). I guess that
> > you may notice pretty high MemFree.
> >
> > Please check also ulimit (process limits) and LDR_CNTRL in order to
> > validate if SIGSEGV does not come from exceeded limits.
> >   
> I think it is just running out of memory.
> > (Finally) I think that change of malloc options should help you (try
> > with "export MALLOCTYPE=watson" or
> > "export MALLOCTYPE=buckets").
> >   
> Pawel,
> 
> Did you ever run your tests using teh Watson allocator?
No, we did not tried Watson for a longer period of time.
We have however tried MALLOCOPTION=disclaim on test area and noticed 
real slow down of system. COB was run over a weekend. It was performing 
relatively slow and one of the jobs could not complete. People called me 
and not knowing details I asked to revert .profile settings back to 
standard allocator. Then restarted COB progressed much faster (as usual) 
and completed without troubles. So diclaim is introducing some 
(significant) overhead to our batch processes.
I think that we should test Watson more. The only problem I have is COB 
monitoring. I would like to observe COB, but at the time when it is run 
I am usually already at home.
I can not perform tests in the middle of the week also, because it could 
affect testing.

I did not test Watson much except some SSELECTs. They were throwing 
messages about already freed memory if I remember well (I showed samples 
in the past).

Our real problem is limited amount of memory (physical & swap) available 
on test servers. There are multiple environments and "out of memory" 
problems are occuring relatively seldom. The fact is that when server is 
running out of memory server it practially stops responding. You can not 
launch new session, telnet / ssh daemon may even die. We need to restart 
machine to handle situation.

Recently I was witness of "out of memory" problems on test area and I 
could not help in any way. I wanted to run genkld / somem -v / 
slibclean, but was getting "fork" (sh) or PERFORM (jsh) errors. System 
was also veeeeeeeeeeery slow. I did manage to collect anything valuable.
I explain myself that it was caused by one of COBs that mistakenly was 
set up to 80 sessions (far too much). They must have eaten lot of memory.

I do not see much benefit from Watson allocator and think that in our 
situation we could benefit from "disclaim" option (but it is introducing 
too much overhead). I think that we will try Watson one day, but it is 
not high priorty.

We have been running "buckets" allocator for a month on our main test 
area and did not observe much benfits. We do not monitor COBs well 
however and it was already raised by me.

I hope that in some time we will create something to monitor COB or will 
use Temenos Enterprise Console with custom parameters monitoring. nmon 
charts I got from operators were not really helpfull :(

I would like to come back to the subject, but had more important 
(business related) issues recently.

> > The last undiscussed thing is a sense of running SELECT command on such
> > a big file ;)
> >   
> 
> Ye s- unless it is a SSELECT built into the application, a series of
> smaller more manageable index based KEY-SELECTS will be way faster and
> take up much less resource. You can sort the final item list if you
> really NEED to process items in sorted order (which most people don't).
> 
> 
> Jim

----------------------------------------------------
Nie czekaj na LAST minute! 
Zaplanuj teraz swoje wakacje. 
To się opłaca! Zniżki nawet do 30%. 
Sprawdź: 
http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fznizki30procent.html&sid=665



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to