By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,334 Members | 1,328 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,334 IT Pros & Developers. It's quick & easy.

EEE partitions process performance are different

P: n/a
Hi All,
I have DB2 EEE 7.2 12 db partitions running on AIX 5.1ML5 P690( one
server). The AIX workload manager is on. I started the same peoplesoft
job on all 12 nodes at the same time. But some node(partition)
processing speed are much faster than the others. The fastest node
took 15 hours. But the slowest node took 17 hours.

According to DBA, the data are evenly disributed on 12 partitions. The
configuration of the partitions are same. All the job have same
priority on the OS. The jobs used all the CPU resource (reached WLM
CPU hard limit). I think maybe the partition were compete the CPU
resource which cause the partition speed were different.

Could anyone give me some advice why the DB2 nodes cannot share the
system resource evenly? Why some nodes faster?

Thanks.

John
Nov 12 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Jack Li wrote:
Hi All,
I have DB2 EEE 7.2 12 db partitions running on AIX 5.1ML5 P690( one
server). The AIX workload manager is on. I started the same peoplesoft
job on all 12 nodes at the same time. But some node(partition)
processing speed are much faster than the others. The fastest node
took 15 hours. But the slowest node took 17 hours.

According to DBA, the data are evenly disributed on 12 partitions. The
configuration of the partitions are same. All the job have same
priority on the OS. The jobs used all the CPU resource (reached WLM
CPU hard limit). I think maybe the partition were compete the CPU
resource which cause the partition speed were different.

Could anyone give me some advice why the DB2 nodes cannot share the
system resource evenly? Why some nodes faster?

Thanks.

John


Assume that the average duration is 16 hours. Maximum dispersion is 1/16
or <7%. You're complaining about +|- 7% duration of "identical" tasks in
a multi-tasking environment? I wouldn't be surprised to see that much
dispersion of data that's "evenly" distributed. Even if the data is
exactly divided between the partitions; I/O effects could account for at
least that much difference between the fastest and slowest node.

Phil Sherman

Nov 12 '05 #2

P: n/a
>
Assume that the average duration is 16 hours. Maximum dispersion is 1/16
or <7%. You're complaining about +|- 7% duration of "identical" tasks in
a multi-tasking environment? I wouldn't be surprised to see that much
dispersion of data that's "evenly" distributed. Even if the data is
exactly divided between the partitions; I/O effects could account for at
least that much difference between the fastest and slowest node.

Phil Sherman


I also suspect the I/O effects the nodes performance. For the first
time run, I found the containers of last finished 4 partitions are
located at the same LSS of Shark ( That means they are in same SSA
loop). This may impact the performance. Looks like I almost get the
anwser. But the secound time run, I found the job finish sequence is
different. The slowest 2 nodes on the first test are move to top 3
fastest nodes on the second time test. And the winner of the first
test become to last one on the second test. Looks like the nodes
process speed are random.

Thanks.
Nov 12 '05 #3

P: n/a
What is the number of CPUs ?
What do you mean - I started the same peoplesoft job on all 12 nodes at the
same time? Where do you kick off the peoplesoft job? On the same P690 or on
another application server? (Sorry, I have no ideal about peoplesoft
software.) If it is the same physical node, would you tell us more detailed
information? For example, you setup DB2NODE variable in order to kick off
the job on the node you specified.


"Jack Li" <li******@yahoo.com> wrote in message
news:d5**************************@posting.google.c om...

Assume that the average duration is 16 hours. Maximum dispersion is 1/16
or <7%. You're complaining about +|- 7% duration of "identical" tasks in
a multi-tasking environment? I wouldn't be surprised to see that much
dispersion of data that's "evenly" distributed. Even if the data is
exactly divided between the partitions; I/O effects could account for at
least that much difference between the fastest and slowest node.

Phil Sherman


I also suspect the I/O effects the nodes performance. For the first
time run, I found the containers of last finished 4 partitions are
located at the same LSS of Shark ( That means they are in same SSA
loop). This may impact the performance. Looks like I almost get the
anwser. But the secound time run, I found the job finish sequence is
different. The slowest 2 nodes on the first test are move to top 3
fastest nodes on the second time test. And the winner of the first
test become to last one on the second test. Looks like the nodes
process speed are random.

Thanks.

Nov 12 '05 #4

P: n/a
"Fan Ruo Xin" <fa*****@sbcglobal.net> wrote in message news:<1h*****************@newssvr28.news.prodigy.c om>...
What is the number of CPUs ?
What do you mean - I started the same peoplesoft job on all 12 nodes at the
same time? Where do you kick off the peoplesoft job? On the same P690 or on
another application server? (Sorry, I have no ideal about peoplesoft
software.) If it is the same physical node, would you tell us more detailed
information? For example, you setup DB2NODE variable in order to kick off
the job on the node you specified.


I ran the peoplesoft jobs on one physical P690 server 32 CPUs, 100GB
memory. The Workload manager is turn on and setup the CPU hard limit
to 44% for this application class. We setup 12 db2nodes on this
server. The peoplesoft application engine jobs are called by shell
scirpt. The 12 jobs are exactly same just running on different db2
node to process data seperately.
Nov 12 '05 #5

P: n/a

"Jack Li" <li******@yahoo.com> wrote in message
news:d5*************************@posting.google.co m...
"Fan Ruo Xin" <fa*****@sbcglobal.net> wrote in message

news:<1h*****************@newssvr28.news.prodigy.c om>...
What is the number of CPUs ?
What do you mean - I started the same peoplesoft job on all 12 nodes at the same time? Where do you kick off the peoplesoft job? On the same P690 or on another application server? (Sorry, I have no ideal about peoplesoft
software.) If it is the same physical node, would you tell us more detailed information? For example, you setup DB2NODE variable in order to kick off the job on the node you specified.


I ran the peoplesoft jobs on one physical P690 server 32 CPUs, 100GB
memory. The Workload manager is turn on and setup the CPU hard limit
to 44% for this application class. We setup 12 db2nodes on this
server. The peoplesoft application engine jobs are called by shell
scirpt. The 12 jobs are exactly same just running on different db2
node to process data seperately.


I see. Then do you know why the DBA decide to use 12 db partitions? Do you
also use LPAR, separate the db2 system and peoplesoft system to use its own
dedicated system resources? Is peoplesoft process single thread or
multi-thread?
Nov 12 '05 #6

P: n/a
>
I see. Then do you know why the DBA decide to use 12 db partitions? Do you
also use LPAR, separate the db2 system and peoplesoft system to use its own
dedicated system resources? Is peoplesoft process single thread or
multi-thread?

I know the db partition should base on CPU numbers( 1 or 2 CPU per
partition ). But this environment is used to simulate production
server configuration. So the partition number didn't match the CPU
number. We don't use lpar on this P690. The db2 and peoplesoft system
are on same server. I don't know too much about peoplesoft. I guess
the peoplesoft application engine is multi-thread.
Folloing the description of peoplesoft application engine."In
PeopleSoft Application Engine, a program is a set of SQL statements,
PeopleCode, and program control actions that enable looping and
conditional logic."

Thanks.
Nov 12 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.