Jobs submitted on Server takes about 10 minutes to change from 'W' wait Status to 'S' in Queue & 'P' processing Status

[Slibra]

Jobs submitted on Server takes about 10 minutes to change from \'W\' wait Status to \'S\' in Queue & \'P\' processing Status

We are on OneWorld Xe SP22, our enterprise server is RS6000/ AIX O/S and Oracle database, since yesterday afternoon we have start facing the issue with jobs submitted on server. jobs get submitted on server and it shows in 'W' status, But it does not start processing or gets in queue for at least 10 minutes. This is happening for all the JDE Queues Single as well as Multithreaded Queue, I have restarted the JDE Services and checked but it does the same thing.

This issue is becoming a big bottleneck for us, as lot of jobs remain in 'W' status.

Any help or suggestion would be appreciated..

 

[dan_richards]

Re: Jobs submitted on Server takes about 10 minutes to change from \'W\' wait Status to \'S\' in Queue & \'P\' processing Status

Has anything changed in the last couple of days? ESU? SP? JDE.INI changes? New package deployment?

 

[cmanderson]

Re: Jobs submitted on Server takes about 10 minutes to change from \'W\' wait Status to \'S\' in Queue & \'P\' processing Status

Besides what Dan asked, do you have nmon or topas on the box, barring those tools do you have sar enabled? If you don't have any of those, you can find out using the vmstat and iostat tools - but it is a bit cryptic for someone not familiar to UNIX.

The first thing I'd check in a situation like this is whether or not your CPU is 100% utilized. Then check your memory utilization - 'lsps -s' on AIX will show you your swap percentage used. If that is fine, check for errors in the jde.log files.

 

[zhusain90]

Re: Jobs submitted on Server takes about 10 minutes to change from \'W\' wait Status to \'S\' in Queue & \'P\' processing Status

We had the same issue occur on a non frequent basis. It turned out that the CPU's were going into IO Wait status due to a conflict between reading / writing to the same set of drives. Using SAR it turned out that some of the drives were 100% busy.

We are on OneWorld XE - SP22 / Unix (Solaris) / Oracle 8.1.7