Answered Need to know the sessions occupying by a particular program at a time

[jchellap]

Dear friends,

We are using the MFG/PRO version "QAD Enterprise Applications 2009 - Standard Edition as of Jun 14 2009."

Linux : 2.6.9-103.0.0.0.1.ELsmp.

I need to find the number of sessions which is occupying by a particualar program. unfortunately, the program is not added in Menu.

I am thinking the command like "ps -ef | grep -ic _progres.*xxopht.p". but not getting it correctly.

MFG/PRO batch calling a program which is initiating multiple sessions and calling this program.

I need to place a condition like if the number of sessions occupied by a particalar program is greater then 10 then suspending the process for few minutes.

Can anyone help on this please?

Thanks,
Vijay

 

[Rob Fitzpatrick]

That ps command will only help you if the session's starting procedure matches that regular expression. If the starting procedure is start.p and it in turn runs a procedure matching *xxopht.p, you won't find it by parsing ps.

I'm not sure I fully understand what you're trying to accomplish, or why, or what you mean by "suspending the process". Do you mean kill -SIGSTOP? If these are shared memory clients I think that would be a bad idea as it could cause contention issues if those clients are holding shared resources like latches or record locks when they are suspended.

If you want to know which procedure a given client is currently running, it is possible to figure that out in a couple of ways. If it's a single client you can get its call stack manually, assuming you have sufficient privilege to issue it a kill command, like so:

proGetStack pid
 
or
 
kill -SIGUSR1 pid

where pid is the process ID of the client session. It will create a file called protrace.pid in the client's working directory.

For a programmatic approach, assuming you're on 10.1C or later you can use Client Database Request Statement Caching. You enable it in promon R&D | 1 | 18. This causes clients to send their call stack to the server whenever they do database I/O, and it is stored in an array in their _Connect VST record. At that point you can write ABL code to parse it and take whatever action you deem appropriate.

See this presentation for details:
http://download.psdn.com/media/revolution_2011/oe11/OE1111.wmv

Use this feature cautiously, and heed the warnings in the linked presentation. It could be detrimental to performance.

 

[jchellap]

FIrst of All. Thanks for your reply !
Basically, the MFGPRO batch process initiating multiple sessions and executing the program "xxopht.p" multiple times. I want to place a condition like if the current running sessions of this program exceeding 10. then I am placing a condition "sleep 180" to suspend the process for 3 minutes. I am not killing any sessions.

 

[dulecki]

Based on what you said, you'll have to put some kind of counter logic in xxopht.p (or in what calls it). Store a counter in usrw_wkfl or generalized codes for how many sessions are running xxopht.p, incrementing it when you start running and decrementing it when you finish. If the counter is >=10 (a number I'd also store so I could change my mind more easily), sleep for 180 (another number I'd store).

That said, why is your batch process initiating all these sessions? Should it be? What is it doing, and what are you trying to accomplish? There's probably a better way to handle it.

Good luck.

 

[jchellap]

Thanks for your reply !

My problem is identifying the number of sessions with are running the program "xxopht.p". I am not sure how much time a program will take. I should be able to count the number of sessions which are running the program "xxopht.p" at a time. Is there any unix / progress commands to identity the number of sessions occupying by a single program?. Note: this program is not added in the menu.

 

[Rob Fitzpatrick]

Thanks for your reply !

My problem is identifying the number of sessions with are running the program "xxopht.p". I am not sure how much time a program will take. I should be able to count the number of sessions which are running the program "xxopht.p" at a time. Is there any unix / progress commands to identity the number of sessions occupying by a single program?. Note: this program is not added in the menu.

If you're parsing ps output then you only get what's in the process command line, which at best will be the starting procedure, not the currently-running procedure. A given .p or .r is not a process; it is application code run by the AVM, an _progres process. I don't think you'll find a nice way of finding the information you want with OS utilities.

This really sounds like you want to change (or constrain) application behaviour without changing application code or configuration. Have you explored the possibility of having the vendor make code changes to meet your needs?

 

[dulecki]

Thanks for your reply !

My problem is identifying the number of sessions with are running the program "xxopht.p". I am not sure how much time a program will take. I should be able to count the number of sessions which are running the program "xxopht.p" at a time. Is there any unix / progress commands to identity the number of sessions occupying by a single program?. Note: this program is not added in the menu.

You still haven't explained why you're doing this. I find it much more effective to state my problem than to ask people to make my solution work. Often, they have ideas for a different and/or better solution. Consider that....

Xxopht.p is a custom program. Therefore, you have control over it and can make changes as needed.

Reading between the lines, it sounds like it was not designed to run single-threaded, but you're experiencing problems when too many threads are started. And you've apparently decided that the proper way to address this is to cap the number of threads at 10 or some other number.

My first response is to add counter logic to xxopht.p. Let it do the counting and not launch if there are too many threads.

My second response is to change xxopht.p so that instead of processing everything directly, all incoming jobs are put into a queue. It then reads and processes the queue. More things come in, they get added to the queue. Want multi-threaded processing, build that into the program.

Hmmm... that last sounds like another method of counter in the program. But it does break the process into pieces.

Regardless, I suggest you take a step back to what the real issue is, not the solution you've decided on.

Good luck.