| Author |
Message
|
| yaakovd |
 Posted: Fri Oct 09, 2009 10:32 am Post subject: Acceptable CU utilization |
 |
|
Partisan
Joined: 20 Jan 2003
Posts: 319
Location: Israel
|
Hi
I have big system which required parse 200 000 files daily built on 2 AIX machines 8 double core CPU each with latest MB version.
On each machine I confiured 8 Execution groups with message flows with Java and MRM/compute parsers - total about 35 threads.
CPU utilization is high (80-90%) when loading all types of files in parallel, but MB working stable and it doesn't affects performance or processing time per file.
Client pushing reduce CPU utilization to lower level.
My question - what is acceptable utilization for completelly backend MB application.
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel |
|
| Back to top |
|
 |
| yaakovd |
| Posted: Fri Oct 09, 2009 10:46 am Post subject: |
|
|
Partisan
Joined: 20 Jan 2003
Posts: 319
Location: Israel
|
Currently we reduced number of threads and CPU utilized 35-40%, but my personal opinion it is waste hardware (we will need configure one more server to cover on required load).
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 09, 2009 11:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The difficulty is this word "acceptable".
It seems acceptable to you personally that the machine runs at 80-90% utilization, but not acceptable to your management.
Generally, CPU utilization is viewed as a 'risk factor', for outages and for capacity planning - that either the machine *will* suffer performance degradation or otherwise impact processing, or the machine will be unable to meet a larger than expected demand. Or that you will have to take an expensive harware upgrade to meet a slight increase in business.
So what is acceptable depends on how those factors are viewed. |
|
| Back to top |
|
|
| yaakovd |
| Posted: Fri Oct 09, 2009 11:20 am Post subject: |
|
|
Partisan
Joined: 20 Jan 2003
Posts: 319
Location: Israel
|
That exactly the point... average CPU utilized 40%, peack time (arrival of files) 90%, part of time completelly idle. It means we can make peak to 60% than average wil be... 20-25%... I think it is nonsense.
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 09, 2009 11:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
An argument can be made that if, this month, the peak is 90%, then six months from now when they are doing twice as much business, then the peak will be 180%...
I personally am not making this argument. I'm just saying that it is a reason for making the decision being made. And I make no judgement of the value of the reason. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Oct 09, 2009 1:00 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
- which version of message broker runtime?
- What style / format of message?
- Which MRM physical format are you using ( CWF / TDS / XML )?
- What size are the messages?
- Have you done any performance analysis to find hot-spots in the message flow(s)? |
|
| Back to top |
|
|
| yaakovd |
| Posted: Fri Oct 09, 2009 10:48 pm Post subject: |
|
|
Partisan
Joined: 20 Jan 2003
Posts: 319
Location: Israel
|
Kimbert
MB version is latest 6.1.3
Flows working file to file:
1. binary files parsed by CWF
2. ASN.1 format parsed by java node
3. ASCI files parsed byTDS
Output of all - CSV format.
Size of files is vary, but I optimized spliting files to smaller messages.
Also Ihave done few cycles of performance analysis using all possible best practice include my own (8 years with MB).
Mqjeff
MAX CPU utilization anyway limited by number of threads. When all flows working in parallel, I have 90%.
One point is correct... recovery from downtime should be taken into consideration... with low CPU delay in delivery from surce will have less affect.
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel |
|
| Back to top |
|
|
|
|
