Thanks!
We will set our chain behavior then to shell after everything is
done so that they do not keep hitting the management node every 5
seconds for instructions.
Unfortunately we did not capture the full execution line of the perl
process that was using 100% of a core, so I do not have that
information to provide. If this occurs again, I will be sure to
attempt to get the full process line and investigate a bit further.
Thanks again for the help!
On 7/26/2011 8:45 AM, Xiao Peng Wang wrote:
In the latest code, xCAT does not support to set the query
interval for the get next destiny (task).
If you set the runcmd=bmcsetup, the node will try to run the
getdestiny to communicate with xcatd to get the next destiny
every 5 seconds.
If you set the standby as the next destiny, it will sleep 15-30
seconds and try to get again.
So the question, what do you want the node to do after running
of bmcsetup? If nothing to do, keep it to 'shell' is a good
idea.
BTW, I am wondering that which perl process used 100% CPU
resource?
Thanks
Best Regards
----------------------------------------------------------------------
Wang Xiaopeng (王晓朋)
IBM China System Technology Laboratory
Tel: 86-10-82453455
Email: [email protected]
Address: 28,ZhongGuanCun Software Park,No.8 Dong Bei Wang West
Road, Haidian District Beijing P.R.China 100193
 Russell Jones ---2011-07-26 00:06:27---Of
course. Thanks for the help! On 7/25/2011 11:00 AM, Lissa
Valletta wrote:
From: Russell
Jones <[email protected]>
To: xCAT
Users Mailing list <[email protected]>
Date: 2011-07-26
00:06
Subject: Re:
[xcat-user] nextdestiny behavior, slow response
Of course. Thanks for the help!
On 7/25/2011 11:00 AM, Lissa Valletta wrote:
> I asked our developer, will let you know. It is always
better to be on a
> supported release though.
>
> Lissa K. Valletta
> 2-3/T12
> Poughkeepsie, NY 12601
> (tie 293) 433-3102
>
>
>
>
>
> From: Russell Jones<[email protected]>
> To: xCAT Users Mailing
list<[email protected]>
> Date: 07/25/2011 11:46 AM
> Subject: Re: [xcat-user] nextdestiny behavior, slow
response
>
>
>
> Thanks Lissa!
>
> Would you happen to know if any of these changes actually
specifically
> changed the getdestiny/nextdestiny behavior?
>
>
>
> On 7/25/2011 10:34 AM, Lissa Valletta wrote:
>> Since xCAT 2.3 has not been supported for a while. I
would suggest you
>> upgrade at least to 2.5, a supported release. There
have been
> tremendous
>> changes in xCAT from 2.3. If you do the upgrade
should be automatic,
> your
>> database will be migrated, etc. One thing you might
need to do since
>> your release is so old, is after the upgrade,
manually stop the xcatd
> and
>> make sure all processes are cleaned up and then restart
it. Also, if you
>> have service node, make sure they are upgraded also.
>>
>> Lissa K. Valletta
>> 2-3/T12
>> Poughkeepsie, NY 12601
>> (tie 293) 433-3102
>>
>>
>>
>>
>>
>> From: Russell Jones<[email protected]>
>> To: xCAT Users Mailing
list<[email protected]>
>> Date: 07/25/2011 11:27 AM
>> Subject: [xcat-user] nextdestiny behavior, slow
response
>>
>>
>>
>> Hi all,
>>
>> When adding a cluster to our network, we are getting
slow responses from
>> what appears to be getdestiny/nextdestiny on our xCAT
2.3 cluster, and I
>> was wondering if any enhancements / changes have been
made in 2.6 to
>> this behavior?
>>
>> The steps of replicating the problem (and how we add a
cluster):
>>
>> * Rack and cable up, power on
>> * Run getmacs
>> * Add cluster nodes to other required tables (we have a
custom script
>> that does this)
>> * makedhcp for the cluster
>> * nodeset cluster runcmd=bmcsetup
>> * Power cycle nodes
>>
>> At this point, as the nodes begin asking the management
node for
>> getdestiny/nextdestiny, the management node begins to
become very slow
>> in responding to the getdestiny/nextdestiny requests.
We are only
>> talking about 30 to 35 nodes at a time, and it happens
when the nodes
>> boot nbfs and get their commands to run bmcsetup. We
also see a perl
>> process consistently using 100% of a CPU core during
this time. What is
>> the process of how these nodes are pulling this data?
Obviously it's
>> getting it from the chain table, but what could cause
this response to
>> be so resource hungry and slow?
>>
>> Also, we are looking to upgrade from 2.3 to 2.6. Has
there been any
>> changes to this process that could assist in correcting
this behavior?
>>
>>
>> Thanks!
>>
>>
>>
>>
>
------------------------------------------------------------------------------
>
>> Storage Efficiency Calculator
>> This modeling tool is based on patent-pending
intellectual property that
>> has been used successfully in hundreds of IBM storage
optimization
> engage-
>> ments, worldwide. Store less, Store more with what you
own, Move data to
>> the right place. Try It Now!
>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>> _______________________________________________
>> xCAT-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/xcat-user
>>
>>
>>
>>
>>
>
------------------------------------------------------------------------------
>
>> Storage Efficiency Calculator
>> This modeling tool is based on patent-pending
intellectual property that
>> has been used successfully in hundreds of IBM storage
optimization
> engage-
>> ments, worldwide. Store less, Store more with what you
own, Move data to
>> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>> _______________________________________________
>> xCAT-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/xcat-user
>>
>
------------------------------------------------------------------------------
>
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual
property that
> has been used successfully in hundreds of IBM storage
optimization engage-
> ments, worldwide. Store less, Store more with what you
own, Move data to
> the right place. Try It Now!
> http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> xCAT-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcat-user
>
>
>
>
------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual
property that
> has been used successfully in hundreds of IBM storage
optimization engage-
> ments, worldwide. Store less, Store more with what you
own, Move data to
> the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> xCAT-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcat-user
>
------------------------------------------------------------------------------
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual
property that
has been used successfully in hundreds of IBM storage
optimization engage-
ments, worldwide. Store less, Store more with what you own,
Move data to
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user
|
