4981Application server with multiple tuxedo queues.
- Aug 2, 2013I have added a second tuxedo queue to my application servers (using DK's most excellent guides) and now I see interesting information for the two queues when I do a "ps -ef" command.
Red Hat linux ES5
#ps -ef | grep PSAPPSR[V] | less
... (this is a partial list, there are 10 processes per queue)
psuser 17433 1 0 Jul30 ? 00:01:45 PSAPPSRV -C dom=psprod_56602 -g 99 -i 23 -u sf-psleg-032 -U /peoplesoft/sys/software/pt8.49/appserv/psprod/LOGS/TUXLOG -m 0 -R 20823 -o LOGS/PSAPPQ2.stdout -e LOGS/PSAPPQ2.stderr -- -C psappsrv.cfg -D psprod -S PSAPPSRV
psuser 31842 1 0 Jul03 ? 00:03:30 PSAPPSRV -C dom=psprod_56602 -g 99 -i 1 -u sf-psleg-032 -U /peoplesoft/sys/software/pt8.49/appserv/psprod/LOGS/TUXLOG -m 0 -o LOGS/PSAPPQ1.stdout -e LOGS/PSAPPQ1.stderr -s@../psappsrv.lst -s@../psqcksrv.lst -- -C psappsrv.cfg -D psprod -S PSAPPSRV
Spreading out the above, you will see two PSAPPSRV processes each that use a different tux queue. The interesting thing is that the one with pid 17433 shows different parameters than the 31842 one.
I suspect, but would like verification on two things:
#1: The two queues (though they are load balanced: "LDBAL Y") do not both receive tasks equally because the first one has never been busy enough to queue any traffic. I suspect that, if the server was busy enough, the load would have gotten to the second queue.
#2: The parameter "-R 20823" in pid 17433 indicates that this server has been restarted by the BBL - probably due to reaching the Recycle Count. I kind of can verify this by restarting the services on the server - this will then show all PSAPPSRV processes like the second pid: 31842.
I'd like confirmation on the above, or better information, and I'd also like to be assured that the restarted server processes get the exact same parameters as the start-up ones.
- Next post in topic >>