That's an interesting point, I didn't think that CPU throttling was relevant here, but under Linux at least, that seems to be an issue because LB reads from /proc/cpuinfo.
I agree that the LB algorithm would seem to need some improving, both the default automatic algorithm (possibly consider factoring in processor generation i.e. Pentium 4 vs. Core 2, total RAM, or even current load and available RAM) and the ability to manually tweak. William Yang > -----Original Message----- > From: [email protected] [mailto:sunray-users- > [email protected]] On Behalf Of Sammy Atmadja > Sent: Tuesday, March 16, 2010 3:35 AM > To: SunRay-Users mailing list > Subject: Re: [SunRay-Users] Failover group load balancing on servers with > lots of cores > > P.S.M.Swamiji wrote: > > On 3/16/2010 3:04 AM, William Yang wrote: > >> Are CPU frequency and count the only things the load balance algorithm > >> considers? > > It is consistent with the behaviour we're seeing: > > server 1, 4 core opteron 1.8GHz, 6GiB RAM, doesn't support powersaving > server 2, 4 core opteron 2.8GHz, 8GiB RAM, powernow/ondemand freq governor > > In theory server 2 should be much more powerful, as it has more RAM and > more > powerful cpu's. But since /proc/cpuinfo shows it's clock freq as 1GHz > because of > the powernow cpu throttling, server 1 gets all the sessions, and runs out > of RAM > long before server 2 starts breaking sweat. As is mentioned on the sun- > rays wiki > somewhere, available RAM should be a much more important factor than CPU. > I > would much rather have somewhat slower cpu's and lots of free RAM than > fast > cpu's twiddling thumbs while waiting for swap. > > > > It also considers number of sessions running/idle... > >> That concerns me a bit especially since with recent processors, > >> increasing speed no longer necessarily means increasing performance. > Can > >> the LB algorithm be manually tweaked if necessary? > > How about an external command (shell script?) that computes the > "desirability" > of the server in question? (feature request) > > Sammy Atmadja > This is a message from the E-MAIL server of Transtrend B.V. > > The information contained in this communication is confidential and > intended solely for the use of the individual or entity to whom it is > addressed. You should not copy, disclose, or distribute this communication > without the authority of Transtrend B.V. Transtrend B.V. is neither liable > for the proper and complete transmission of the information contained in > this communication nor for any delay in its receipt. Transtrend B.V. does > not guarantee that the integrity of this communication has been maintained > nor that the communication is free of viruses, interceptions or > interference. > > If you are not the intended recipient of this communication please return > the communication to the sender and delete and destroy all copies. > > De informatie verzonden in dit e-mailbericht is vertrouwelijk en > uitsluitend bestemd voor de geadresseerde. Openbaarmaking, > vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan > derden is, behoudens voorafgaande schriftelijke toestemming van Transtrend > B.V. niet toegestaan. Transtrend B.V. staat niet in voor de juiste en > volledige overbrenging van de inhoud van een verzonden e-mailbericht, noch > voor tijdige ontvangst daarvan. Transtrend B.V. kan niet garanderen dat > een > verzonden e-mailbericht vrij is van virussen, noch dat e-mailberichten > worden overgebracht zonder inbreuk of tussenkomst van onbevoegde derden. > > Indien bovenstaand e-mailbericht niet aan u is gericht, verzoeken wij u. > vriendelijk doch dringend het e-mailbericht te retourneren aan de afzender > en het origineel en eventuele kopieen te verwijderen en te vernietigen. > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
