A test batch file containing only "@ECHO OFF" without the quote mark is being called every minute by the scheduler.

Each time, my used memory jumps. 90% it's a 12k jump. The rest of the time, it can go up to 100k or to 8k.

The memory used by all applications remain stable at all times. The only thing different is that page definition for 24/7 increments by 44 in task manager column almost every second.

The batch file is called from a network drive.

Example H:\WINDOWS\24x7\submitstratto.bat

If i run the same command line from the run dialog box of windows NT4 SP4, the memory jumps for the execution and then goes back to where it was.

I then tried C:\WINNT\SYSTEM32\CMD /C H:\WINDOWS\24x7\submitstratto.bat to force the end of CMD with no success.

Am i missing anything ?

Thanks !

1. Disable logging for a job that runs every minute (but keep "notify" on error).
2. Set reasonable maximum log size in the 24x7 system options.

: A test batch file containing only "@ECHO OFF" without the quote
: mark is being called every minute by the scheduler.

: Each time, my used memory jumps. 90% it's a 12k jump. The rest of the time,
: it can go up to 100k or to 8k.

: The memory used by all applications remain stable at all times. The only
: thing different is that page definition for 24/7 increments by 44 in task
: manager column almost every second.

: The batch file is called from a network drive.

: Example H:\WINDOWS\24x7\submitstratto.bat

: If i run the same command line from the run dialog box of windows NT4 SP4,
: the memory jumps for the execution and then goes back to where it was.

: I then tried C:\WINNT\SYSTEM32\CMD /C H:\WINDOWS\24x7\submitstratto.bat to
: force the end of CMD with no success.

: Am i missing anything ?

: Thanks !

: 1. Disable logging for a job that runs every minute (but keep
: "notify" on error).
: 2. Set reasonable maximum log size in the 24x7 system options.

I disabled loggin in the program options and on the task and set the log count in options to 10.

I restarted the program... no success. The 12k pattern remains.

: I disabled loggin in the program options and on the task and set the log
: count in options to 10.

: I restarted the program... no success. The 12k pattern remains.

We found that if the job type was set asynchronous, you can almost guarantee this problem.

Our workaround has been to use the scheduler to call another instance of itself and launch the job. Use run "24x7 /JOB" (see help file). Change the job type to synchronous. I think then the problem will go away.

We had great support from the 24x7 folks in resolving several other issues as well. The result is a very powerful and stable system.

Good luck with it.

-m-

: We found that if the job type was set asynchronous, you can almost guarantee
: this problem.

: Our workaround has been to use the scheduler to call another instance of
: itself and launch the job. Use run "24x7 /JOB" (see help file).
: Change the job type to synchronous. I think then the problem will go away.

: We had great support from the 24x7 folks in resolving several other issues as
: well. The result is a very powerful and stable system.

: Good luck with it.

: -m-

Thanks for the input. I will surely try it.

What do you use to track the memory?
I setup a job like yours and could not reproduce it. I used NT permonace Monitor, checked Private bytes, Working bytes and Working Set. All of them stop changing after about 10-15 minutes of work. Check if you have some other processes started by the scheduler, may be they cause this memory leak.

: I disabled loggin in the program options and on the task and set the log
: count in options to 10.

: I restarted the program... no success. The 12k pattern remains.

He is running "program type" job. It does not matter how the job is setup as async. or as sync.

: We found that if the job type was set asynchronous, you can almost guarantee
: this problem.

: Our workaround has been to use the scheduler to call another instance of
: itself and launch the job. Use run "24x7 /JOB" (see help file).
: Change the job type to synchronous. I think then the problem will go away.

: We had great support from the 24x7 folks in resolving several other issues as
: well. The result is a very powerful and stable system.

: Good luck with it.

: -m-

Yes, "24x7 /JOB" is anothet option. By the way, I believe that async. script problems were fixed in the last build 2.3.2.

: We found that if the job type was set asynchronous, you can almost guarantee
: this problem.

: Our workaround has been to use the scheduler to call another instance of
: itself and launch the job. Use run "24x7 /JOB" (see help file).
: Change the job type to synchronous. I think then the problem will go away.

: We had great support from the 24x7 folks in resolving several other issues as
: well. The result is a very powerful and stable system.

: Good luck with it.

: -m-

: Yes, "24x7 /JOB" is anothet option. By the way, I believe that
: async. script problems were fixed in the last build 2.3.2.

I didn't pinpoint the leak yet using perfmon. All i am sure of at this point is that using task manager, performance, the memory increases by 12k when the dos box pops to run the batch file.

I appreciate all of your feedback.

Val

What parameter do you check?
In the processes, select 24x7 and check memusage column (after a little while it jumps back and forth around the same number, no matter how many times you ran your batch)

Another thing, why the dos box pops to run the batch file?
For a batch containing just "echo" command, it blinks so quickly that it is not always possible to see it... If you change the task window to run "hidden" or "minimized" you will not see it at all.

: I didn't pinpoint the leak yet using perfmon. All i am sure of at this point
: is that using task manager, performance, the memory increases by 12k when
: the dos box pops to run the batch file.

: I appreciate all of your feedback.

: Val

: What parameter do you check?
: In the processes, select 24x7 and check memusage column (after a little while
: it jumps back and forth around the same number, no matter how many times
: you ran your batch)

: Another thing, why the dos box pops to run the batch file?
: For a batch containing just "echo" command, it blinks so quickly
: that it is not always possible to see it... If you change the task window
: to run "hidden" or "minimized" you will not see it at
: all.

I was checking memory usage in task manager. The reason why i kept the popup even if it only blinks is to check what was moving when it occured. 24/7 doesn't seem to be grabbing more memory and none of the process in there seems to grab any memory but still, my available memory is loosing 12k each time the batch is run. I just got back from lunch and i will try to isolate the leak.

Thanks !

: What parameter do you check?
: In the processes, select 24x7 and check memusage column (after a little while
: it jumps back and forth around the same number, no matter how many times
: you ran your batch)

: Another thing, why the dos box pops to run the batch file?
: For a batch containing just "echo" command, it blinks so quickly
: that it is not always possible to see it... If you change the task window
: to run "hidden" or "minimized" you will not see it at
: all.

Ok, i have been looking around all afternoon and this is what i found. There is a handle leak. When the batch file is called, the number of handles and associated memory grows until the system dies. Problem is... i found no program that pinpoint 24x7 as being the leak. I am sure that if it runs the batch, the handle leak starts. A way to view this is to select in perfmon, object, threads. The count goes up and up. Shouldn't it go down when the batch finished executing ? Also, running the batch from a shortcut does not change the handle count. Hope it helps !

I send a request for "in depth" investigation to support. I will keep you posted.

: Ok, i have been looking around all afternoon and this is what i found. There
: is a handle leak. When the batch file is called, the number of handles and
: associated memory grows until the system dies. Problem is... i found no
: program that pinpoint 24x7 as being the leak. I am sure that if it runs
: the batch, the handle leak starts. A way to view this is to select in
: perfmon, object, threads. The count goes up and up. Shouldn't it go down
: when the batch finished executing ? Also, running the batch from a
: shortcut does not change the handle count. Hope it helps !

: I send a request for "in depth" investigation to support. I will
: keep you posted.

Thanks !

: I send a request for "in depth" investigation to support. I will
: keep you posted.

Thanks !