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
