Title: Re: [Firebird-devel] True SMP support in SuperClassic and V3
Vince, FB 3 snapshot is already available for download, so you can check it by yourself (and if so, please report the results here).

Actually, with such "heavy" server, I think you can help the "Project" a lot with FB 3 tests. Personally, I got "weird" results using FB 3 in my notebook (4 cores, 2 real and 2 HT and 8GB RAM) and TPC-C tests. The same tests showed much better results (at last 10x better) in a quad core desktop (this time, 4 real cores but only 4GB RAM). Nobody was able to explain why such big difference. Interesting that the performance was similar in both machines when loading the database with information. The huge difference only appeared when "using" the database.

[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br




Hi all, 

I have been doing a lot of testing on a monster Windows server so that we can move from a Solaris 2.1.3 build (thanks Paul) to 2.5 on preferably Windows, or perhaps Linux. 

The box has 8 processors, each with  8 cores. These are arranged into 4 NUMA nodes, each with 2 processors. Windows reports 4 processors (i.e. each NUMA node is seen as one processor) , each with 16 cores. 

128GB RAM, Windows 2008 R2. 

Firebird Version: WI-V2.5.2.26539 Firebird 2.5 

My concern is that in this article: 
http://www.firebirdsql.org/manual/qsg25-classic-or-super.html 

it is stated that  SuperServer uses one processor (unless CPUAffinityMask is changed) and that Classic and SuperClassic ignore CPUAffinityMask, and use all processors. 

When running under load (150+ busy connections) SuperClassic clearly uses only one NUMA node (threads are spread across 16 cores), while Classic is spread evenly across all 64 cores. CPUAffinityMask makes no difference (as stated in the docs). 

How is this going to run in V3? Will we see full use of all cores on all processors, or will the behaviour be as in SuperClassic. 

Is this a machine architectural issue? i.e. the NUMA node architecture makes it a little more difficult for one NUMA node to access the memory 'allocated' to another NUMA node? which implies that V3's shared cache may be restricted to one node, and not spread across all nodes? 

Regards

Vince

Vince Duggan
I.T.  Architect 
Virgin Active South Africa (Pty) Ltd
Tel (+27) (0)21 684 3525
Fax (+27) (0)21 684 3225
Cell (+27) (0)82 747 6127
Email: vince.dug...@virginactive.co.za

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to