Re: Configuring IDS for multi-threaded processors

David, You cannot take advantage of the virtual threads in the Niagra processors. They were optimized for POSIX threads and perform poorly for single -OS LEVEL- threaded applications such as the oninit processes in IDS. To take best advantage of the Niagra processors with IDS you have to disable the hardware virtual threads and just count on the physical cores when calculating the number of CPU VPs to use. This advice from my own testing with a client, several posts on the Internet, and the experience of some IBM Informix people. Obviously YMMV applies and one should test things oneself, but that's my advice. Note that the individual physical cores of even the fastest Niagra processor are much slower than the cores in the latest Intel, AMD, and PowerPC processors with the obvious results in cross testing. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Sun, Jun 7, 2009 at 8:50 PM, Ian Michael Gumby <im_gumby@hotmail.com>wrote: > > > > From: david@smooth1.co.uk > > > > > On thing you may find is that certain latches/mutexs with in the > > instance run hot as they are not tuned for such a large number of CPU > > VPs, making > > the latches more fine grained make removed bottlenecks with the number > > of CPU VPs. > > > > > > I would get someone from the IBM Developement Labs involved as this is > > probably the instance with the largest number of CPU VPS in existance. > > > > The IBM engineers should be keen to make Informix scale to 100+ cpus > > and would enjoy the task of tuning this instance. > > > > David, > > I'd take networking out of the picture and focus on the engine running > tests via a shared memory connection. > Not that I don't think that there *will* be issues with networking, but > that I think we need some form of isolation to force focus on fewer moving > parts. > > I do agree that there are some issues with context switching you're going > to have issues, but context switching for 128 vcpus should not be that > difficult. Of course having said that... I imagine that when they did > certain design decisions, they didn't consider context switching for > anything remotely close to 128 vcpus. > > So is it safe to say that for massively large databases that going the > shared nothing distributed route like... dare I say it? ... XPS? 8^0 :-P ... > is the way to go? (Each node can be SMPed). The other reason I would > considered a clustered shared nothing is that using OTC components, you can > build it cheaper than massive SMP boxes. (But I could be wrong... Which is > more, a 16 socket Sun box, or a blade center with 8 dual socket blades? > (Assuming Sun's sparc VII+ chips are available for blades... > > I'd wager that IBM is aware of this and working out a solution for it. Of > course I don't know if they'll do a DB2 version first, or an IDS version. My > gut tells me that in the world of IBM, DB2 is still queen and IDS is that > evil stepchild who needs to sweep the floors and do the dishes... ;-) (OK, > so I fractured two fairy tales... but you get the idea!) > > -G > > > ------------------------------ > Windows Live™ SkyDrive™: Get 25 GB of free online storage. Get it on your > BlackBerry or iPhone.<http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_SD_25GB_062009>; > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > >