Menu
▾
▴
#557 CPU LOAD 100%
An ooRexx - ooDialog application that runs the whole day (6..8 hours) requires 100% CPU load and slows down the PC although there is no action on the dialog.
After stop and restart of the application all works fine again and the cpu load is 00% .
Until know we were not able to identify the reason for that behavior.
Discussion
Anonymous
Martin,
There is not much I can do about this, since I can not reproduce it.
I'm going to paste in a little information here from our e-mail conversations.
Martin informed me that the program is started in 2 ways, from a batch file and from another Rexx program.
The batch file has this code:
START "CallSearch" /B /D ".\" rexx ".\CallSearch"
EXIT
The other Rexx program uses essentially the same command:
/--------------------------------------------------------------------/
/ Start the CallSearch Module /
/--------------------------------------------------------------------/
'START "CallSearch" /B /D ".\"' ,
'REXX ".\CallSearch"' ,
Callsearch_Parms
From Martin:
"today I got an information from one of our users. He told me that the
program was started at 10am and during lunch the screen saved has been
started.
after stopping screen saver the program still works fine.
at 4pm the guys had a coffee brake and again the screen saver starts,
When they come back, the CPU for the REXX.Exe has 70%.
The User has killed the rexx session and all works fine."
From Martin:
"I got again some information from the users, but I think this doesn't
really help to find the problem.
The problem occures always with the same rexx program (we are using 3
different) but this program runs the whole day the other one is started and
closed several times a day."
From Martin:
"Furthermore the problem may hw-related.
Users that complains, uses a T41&T42 Think pad, user that have a T6* TP
does not complain about that...."
Hi Martin,
There are a few things still unclear to me, so I'm going to ask some specific questions here. Would you answer each one please.
1.) You said that you found out the problem always happens with one specific program (you are using 3 different programs.)
Is that program started from the .bat file? From the other Rexx program? Or, is it started both ways?
2.) The one instance of the problem that you report, says it happens after a screen saver starts. Can you verify whether the problem only happens after the screen saver starts?
3.) You also said that the problem only happens on 1 piece of hardware. Can you verify that the problem only happens on that hardware and not on the other hardware?
Can you please try these things:
A.) On the system where the problem happened. Have the user turn off the screen saver completely and work that way for several days. See if the problem stops happening.
B.) For the program that has the problem. Take out the /B option in the command to start it. This may / probably will have an extra console window open. Ask your users to just ignore the extra window and only run the program that way for a number of days. 4 or 5 days at least. See if the problem goes away.
In the batch file the command should look like this:
START "CallSearch" /D ".\" rexx ".\CallSearch"
In the rexx program the code should look like this:
'START "CallSearch" /D ".\"' ,
'REXX ".\CallSearch"' ,
Callsearch_Parms
Thanks.
--
Mark Miesfeld
I had a similar problem: I had two dialogs, one that worked fine and one that took 100% CPU when doing nothing. Stopping and restarting didn't fix the problem. After lots of method swapping and testing, I found the RUN method to "be at fault". Both dialogs initially had a RUN method, but the first created a few objects and created another thread, then did a RUN:SUPER. The second didn’t do anything in RUN (so I’d deleted it). If I copied RUN from the first to the second, the second started working fine, but I didn’t want or need the additional objects or thread.
I decided that timing was the only real difference in the two and created a RUN method that only does a SYSSLEEP .1 then a RUN:SUPER and it fixed the problem. I hope this helps.
Hi Mark,
i just noticed your comment from 9 months ago. You may have noticed an exchange I had with Jon on RexxLA recently. I'm going to repeat it for you. You really shouldn't be over-riding the run method. In my opinion, the method should never have been documented. Anything you are doing in a run() method, you could do in initDialog().
You're work around, is similar to a work around I had. Today I discovered a scenario where the work around didn't work. This in turn helped me find what I believe is a correct fix.
Committed revision 5312.
I believe this commit fixes the 100% CPU problem. The fix will be in the next release
It is possible to test this fix on your own installation of either ooRexx 3.2.0 or ooRexx 4.0.0 by replacing your OOD*cls fiiles with the files I am going to attach.
There is one zip file: cpuPeggedFix_3.2.0 for a ooRexx 3.2.0 installation and another file: CPU_Pegged_Fix_v4_0_0.zip for ooRexx 4.0.0.
Either file unzips into a separate directory. There is a read me file included. But, basically all you do is save a copy of the OOD.cls files in your ooRexx installation then copy the OOD.cls files from the zip file ove the top of your existing OOD*.cls files in the installation directory.
Martin Berg - the change is very minimal. Essentially it just ensures that sleeptime is a whole number greater than 0. If you could test the fix on your system where you have been seeing the problem and report back to me, I'd really appreciate it.
Fix for ooDialog in ooRexx 3.2.0
Fix for ooDialog in ooRexx 4.0.0
I installed the replacement files. After that I ran my seven sample dialog execs 4 or 5 times each and all of them worked perfectly. Hooray!
However I then tried out some of the supplied sample execs:
a) samples\oodialog\dlgAreaDemo.rex
- was sluggish responding to a click on its OK button, the first
time I tried it. On subsequent runs it was sometimes fine and
sometimes slow, but never dire.
b) samples\oodialog\ftype.rex
- every time I run this as soon as the dialog box appears asking me
to choose one or other option, cpu% climbs to 100%, taking 2-3
seconds to do so. CPU use is split between 'System' at 45-50%,
rexx.exe and rxapi.exe (not all that much), and vsmon.exe (which
I think is the internet traffic monitor for Zone Alarm Pro) at
around 30-40%.
c) samples\oodialog\calculator.rex
- like ftype.rex, cpu hits 100% as soon as dialog is displayed
Wait a minute... I've just noticed that there are copies of the OODxxxx.CLS files in the samples directory. And of course, I only updated the ones in ooRexx\ itself. Why on earth are there copies here too?
There are also copies in \samples\oodialog\source.
As soon as I renamed the ones in the samples directory - just so they'd not be found - the samples described above now work fine.
Okay, thanks a lot Jeremy.
The extra copies of the OOD*.cls files in the samples directory is a hold over from the IBM Object Rexx distribution. A few months ago I made a change to the packager so that the distribution will no longer contain those extra files.
The fix for this will have to come in a release after 4.0.1
Committed revision 5658.
4.0.1 merge.
The fix for this item was in the 4.0.1 release.