Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-19 Thread Poul Dige
   Fra: Alex Peshkoff [mailto:peshk...@mail.ru]
  
   On 11/13/12 18:18, Poul Dige wrote:
  
  
   I could put a screen dump here of the Windows 2008R2/63 task
   manager
   with AMD Opteron 6274, 2x16 core running FB2.5.1 SC/32 bit (due to
   some 32 bit UDF). I don't know if you are interested at a gaze. We
   see exactly the same kind of usage, 8 cores are in use and 24 are
   more or
  less doing nothing.
   However, the cores in use are not maxed out - so it COULD be
   something
   with power management that the OS doesn't want to activate more
   CPU's than necessary. I can't tell about that for sure.
   Is it SC or CS?
   Hi Alex,
  
   it is Super Classic.
  
 
  Let me pay your attention that in initially described case use of
  classic made all cores loaded. How does your server behave with classic?
 
 Hi Alex,
 
 It is a very important production server and I can't find a good way to make
 tests on it by switching to classic. Thing is, the connections are very short
 lived, so it is a nice feature that the threads are spawn very quickly by
 Firebird. I have seen another, similar server (32 cores Win2k8R2) with FB2.1
 CS which seems to distribute load evenly, so I guess the problem lies in
 thread handling - not if FB but in Windows itself.
 
 I will try to install an update for Windows as it seems to be a well known
 problem with Windows 7/2008R2 vs AMD Bulldozer architecture, so the
 following hotfix may just be a solution (there are two hotfixes, the other one
 is referred to in the article):
 
 http://support.microsoft.com/kb/2646060
 
 I will re-post once we have had opportunity to update the server, which will
 probably not be until the weekend.
 
I installed the above mentioned hotfix from MS (toghether with the prerequisit 
KB2645594) this past weekend. Today I see: 
   - exactly the same.
 55 threads (according to task manager) in FB 2.5.1.26351 SC (Super Classic) 
spread over only 8 of the 32 cores on the Win2008R2 SP1 server (see hw specs 
above). The cores aren't max'ed out, so at least in princip there is an excuse 
for not firing up the remaining 24 cores. But, somehow I'd be more happy to see 
an equal load on all cores.

In other words - the hotfix didn't change anything noticably. 

Does FB decide anything regarding on which cores to run, or is it entirely a 
Windows decision? I imagine the latter, but of course we have the affinity 
parameter in the config file for super server installations, so at least it is 
possible to influence choice of processor core.

Are there any suggestions what I should try to do next? We have actually 2 
similar servers, both running 2.5.1SC (for now). The other server COULD be 
equipped with CS instead, if that would make a lot of sence as a trial. Even 
SS, as it primarily serves a lot of different databases with only a few 
connections on each.

Your call, Alex :)

Best regards
Poul





--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-19 Thread Alex Peshkoff
On 11/19/12 18:59, Poul Dige wrote:
 Fra: Alex Peshkoff [mailto:peshk...@mail.ru]

 On 11/13/12 18:18, Poul Dige wrote:


 I could put a screen dump here of the Windows 2008R2/63 task
 manager
 with AMD Opteron 6274, 2x16 core running FB2.5.1 SC/32 bit (due to
 some 32 bit UDF). I don't know if you are interested at a gaze. We
 see exactly the same kind of usage, 8 cores are in use and 24 are
 more or
 less doing nothing.
 However, the cores in use are not maxed out - so it COULD be
 something
 with power management that the OS doesn't want to activate more
 CPU's than necessary. I can't tell about that for sure.
 Is it SC or CS?
 Hi Alex,

 it is Super Classic.

 Let me pay your attention that in initially described case use of
 classic made all cores loaded. How does your server behave with classic?
 Hi Alex,

 It is a very important production server and I can't find a good way to make
 tests on it by switching to classic. Thing is, the connections are very short
 lived, so it is a nice feature that the threads are spawn very quickly by
 Firebird. I have seen another, similar server (32 cores Win2k8R2) with FB2.1
 CS which seems to distribute load evenly, so I guess the problem lies in
 thread handling - not if FB but in Windows itself.

 I will try to install an update for Windows as it seems to be a well known
 problem with Windows 7/2008R2 vs AMD Bulldozer architecture, so the
 following hotfix may just be a solution (there are two hotfixes, the other 
 one
 is referred to in the article):

 http://support.microsoft.com/kb/2646060

 I will re-post once we have had opportunity to update the server, which will
 probably not be until the weekend.

 I installed the above mentioned hotfix from MS (toghether with the 
 prerequisit KB2645594) this past weekend. Today I see:
 - exactly the same.
   55 threads (according to task manager) in FB 2.5.1.26351 SC (Super Classic) 
 spread over only 8 of the 32 cores on the Win2008R2 SP1 server (see hw specs 
 above). The cores aren't max'ed out, so at least in princip there is an 
 excuse for not firing up the remaining 24 cores. But, somehow I'd be more 
 happy to see an equal load on all cores.

Ahh - they are not full loaded? Probably I did not notice that fact 
before, sorry. In that case I suppose windows does the best for your 
performance - keeping less cores active lets them run at higher 
frequency (if I understand correctly how does your CPU work).

 In other words - the hotfix didn't change anything noticably.

 Does FB decide anything regarding on which cores to run, or is it entirely a 
 Windows decision? I imagine the latter, but of course we have the affinity 
 parameter in the config file for super server installations, so at least it 
 is possible to influence choice of processor core.

 Are there any suggestions what I should try to do next? We have actually 2 
 similar servers, both running 2.5.1SC (for now). The other server COULD be 
 equipped with CS instead, if that would make a lot of sence as a trial. Even 
 SS, as it primarily serves a lot of different databases with only a few 
 connections on each.

 Your call, Alex :)

If 8 cores are not 100% loaded, this becomes more windows + amd rather 
than firebird issue. I give up.


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-19 Thread Adriano dos Santos Fernandes
On 19-11-2012 14:39, Alex Peshkoff wrote:

 Are there any suggestions what I should try to do next? We have actually 2 
 similar servers, both running 2.5.1SC (for now). The other server COULD be 
 equipped with CS instead, if that would make a lot of sence as a trial. Even 
 SS, as it primarily serves a lot of different databases with only a few 
 connections on each.

 Your call, Alex :)
 
 If 8 cores are not 100% loaded, this becomes more windows + amd rather 
 than firebird issue. I give up.
 
 

What was being tested?

There may be no sense to load all cores and let them wait for disk IO.
Or was the benchmark done with something pure CPU-bound (a stored
procedure doing math in a loop, for example)?


Adriano

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-19 Thread Poul Dige


 -Oprindelig meddelelse-
 Fra: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
 Sendt: 19. november 2012 17:47
 Til: For discussion among Firebird Developers
 Emne: Re: [Firebird-devel] True SMP support in SuperClassic and V3
 
 On 19-11-2012 14:39, Alex Peshkoff wrote:
 
  Are there any suggestions what I should try to do next? We have actually
 2 similar servers, both running 2.5.1SC (for now). The other server COULD be
 equipped with CS instead, if that would make a lot of sence as a trial. Even 
 SS,
 as it primarily serves a lot of different databases with only a few 
 connections
 on each.
 
  Your call, Alex :)
 
  If 8 cores are not 100% loaded, this becomes more windows + amd rather
  than firebird issue. I give up.
 
 
 
 What was being tested?
 
 There may be no sense to load all cores and let them wait for disk IO.
 Or was the benchmark done with something pure CPU-bound (a stored
 procedure doing math in a loop, for example)?
 
 
 Adriano

The test is quite CPU bound, the disk I/O was relatively low (and running on a 
FusionIO SSD).
I do think that this is an AMD/Windows issue, too. It was just for testing.

And Doychin is right about the NUMA-architecture, so the (total of) 32 cores 
are distributed into 4 NUMA nodes. That could explain the behaviour that one 
NUMA node is preferred to minimize memory sharing. The dual processor Opteron 
has two memory banks, which is again optimally equipped with an equal number of 
memory modules - maybe to satisfy each NUMA node with its own memory bank.

I wonder, though, if this is optimal for, say, super server with many different 
DB's. In that case the optimal solution - I think - is to have one DB per core, 
if possible, and not try to keep the threads together on one NUMA node. But 
still that is not a FB problem.

Kind regards
Poul




--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-13 Thread Poul Dige

 Fra: Dmitry Yemanov [mailto:firebi...@yandex.ru]
 
 12.11.2012 16:52, vince.dug...@virginactive.co.za wrote:
 
  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.
 
 Weird, I'd expect them behaving the same way. Perhaps this is somewhat OS
 related.
 
  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.
 
 Supposedly, it would be the same as in SuperClassic. But so far it doesn't 
 look
 like a Firebird issue, it belongs elsewhere.
 
  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?
 
 A little more difficult - true, but it should mean a little slower, not
 preventing that completely.

I could put a screen dump here of the Windows 2008R2/63 task manager with AMD 
Opteron 6274, 2x16 core running FB2.5.1 SC/32 bit (due to some 32 bit UDF). I 
don't know if you are interested at a gaze. We see exactly the same kind of 
usage, 8 cores are in use and 24 are more or less doing nothing. 

However, the cores in use are not maxed out - so it COULD be something with 
power management that the OS doesn't want to activate more CPU's than 
necessary. I can't tell about that for sure.

Best regards
Poul


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-13 Thread Mark Rotteveel
On Tue, 13 Nov 2012 14:18:22 +, Poul Dige p...@tabulex.dk wrote:
 I could put a screen dump here of the Windows 2008R2/63 task manager
with
 AMD Opteron 6274, 2x16 core running FB2.5.1 SC/32 bit (due to some 32
bit
 UDF). I don't know if you are interested at a gaze. We see exactly the
same
 kind of usage, 8 cores are in use and 24 are more or less doing nothing.

 
 However, the cores in use are not maxed out - so it COULD be something
 with power management that the OS doesn't want to activate more CPU's
than
 necessary. I can't tell about that for sure.

I know that Windows 8 will 'park' cores if there is no work for them, and
it will try to assign threads to the active/unparked cores first. When the
load exceeds a certain threshold, then it will unpark an additional core
and schedule threads to that (at least that is what I observed on my
Windows 8 Pro on an 8 'core'(*) FX-8120 at home), as far as I know Windows
2008 server also has similar scheduling algorithms (depending on the
processor).

The reason is simple: it conserves some power, and some processor have a
kind of speed boost when not all cores are loaded (ie: it will 'overclock'
the active cores because there is more thermal 'headroom' as not all cores
are powered and generating heat). This allows for faster processing if work
isn't really multithreaded, and doesn't actually benefit much from running
multicore.

(*): Actually the AMD FX is not fully 8 core, it is more like a 4 core
which allows 2 threads to be scheduled simultaneously by having same
features/instructions twice, and other features/instructions only once per
core.

Mark

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-13 Thread Poul Dige


 Fra: Mark Rotteveel [mailto:m...@lawinegevaar.nl]
 Emne: Re: [Firebird-devel] True SMP support in SuperClassic and V3
 
 On Tue, 13 Nov 2012 14:18:22 +, Poul Dige p...@tabulex.dk wrote:
  I could put a screen dump here of the Windows 2008R2/63 task manager
 with
  AMD Opteron 6274, 2x16 core running FB2.5.1 SC/32 bit (due to some 32
 bit
  UDF). I don't know if you are interested at a gaze. We see exactly the
 same
  kind of usage, 8 cores are in use and 24 are more or less doing nothing.
 
 
  However, the cores in use are not maxed out - so it COULD be something
  with power management that the OS doesn't want to activate more CPU's
 than
  necessary. I can't tell about that for sure.
 
 I know that Windows 8 will 'park' cores if there is no work for them, and it 
 will
 try to assign threads to the active/unparked cores first. When the load
 exceeds a certain threshold, then it will unpark an additional core and
 schedule threads to that (at least that is what I observed on my Windows 8
 Pro on an 8 'core'(*) FX-8120 at home), as far as I know Windows
 2008 server also has similar scheduling algorithms (depending on the
 processor).
 
 The reason is simple: it conserves some power, and some processor have a
 kind of speed boost when not all cores are loaded (ie: it will 'overclock'
 the active cores because there is more thermal 'headroom' as not all cores
 are powered and generating heat). This allows for faster processing if work
 isn't really multithreaded, and doesn't actually benefit much from running
 multicore.
 
 (*): Actually the AMD FX is not fully 8 core, it is more like a 4 core which
 allows 2 threads to be scheduled simultaneously by having same
 features/instructions twice, and other features/instructions only once per
 core.
 
 Mark



Maybe this article about core parking will be of interest - amazing, what you 
can Google nowadays:
http://support.microsoft.com/kb/2646060

Regards,
Poul



--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


[Firebird-devel] True SMP support in SuperClassic and V3

2012-11-12 Thread vince . duggan
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

Live happily ever active


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
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_novFirebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-12 Thread Ivan Arabadzhiev
I might have a theory on that subject. With HT you share the same  
execution blocks among two pipelines (meaning you are trying to balance  
twice as many threads/instructions and so on, without increasing reorder  
caches/registers/data and instruction caches and other important factors).  
On a normal PC you have threads with different profiles - media streaming,  
integer calculations and so on, so most tasks don`t overlap as much and  
you feel a big boost.
With the database (or any other dedicated server for that matter), on the  
other hand, you have basically the same profile for all threads and you  
starve the CPU from certain blocks/registers, while you don`t really  
utilize the others. You also have some kind of synchronization between the  
two pipelines.
When you have a single user (filling the info in the database) you don`t  
feel the difference because it is basically the same CPU core doing the  
work.

I could be wrong on that one, but under ultra heavy loads I guess all  
those things will be noticeable.

 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

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
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


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-12 Thread Dmitry Yemanov
12.11.2012 16:52, vince.dug...@virginactive.co.za wrote:

 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.

Weird, I'd expect them behaving the same way. Perhaps this is somewhat 
OS related.

 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.

Supposedly, it would be the same as in SuperClassic. But so far it 
doesn't look like a Firebird issue, it belongs elsewhere.

 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?

A little more difficult - true, but it should mean a little slower, 
not preventing that completely.


Dmitry


--
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


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-12 Thread vince . duggan
Hi all,

Thanks for the replies and comments.

 Vince, FB 3 snapshot is already available for download, so you can 
 check it by yourself (and if so, please report the results here).
 

I have V3 running on a much smaller VM, just to test if my stress tests 
run at all - short answer : they don't :-) The DB is a Dialect 1 with a 
lot of legacy rubbish.

I will certainly update the tests in order to get them to run properly on 
V3, and will report back. The big box is earmarked as a production server, 
so I won't have access for long, but I will make a plan. I should be able 
to run both 2.5 and 3 on the same box? 

Vince


 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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
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_novFirebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-12 Thread Alex Peshkoff
On 11/12/12 19:18, vince.dug...@virginactive.co.za wrote:
 Hi all,

 Thanks for the replies and comments.

 Vince, FB 3 snapshot is already available for download, so you can
 check it by yourself (and if so, please report the results here).

 I have V3 running on a much smaller VM, just to test if my stress tests
 run at all - short answer : they don't :-) The DB is a Dialect 1 with a
 lot of legacy rubbish.

 I will certainly update the tests in order to get them to run properly on
 V3, and will report back. The big box is earmarked as a production server,
 so I won't have access for long, but I will make a plan. I should be able
 to run both 2.5 and 3 on the same box?


Yes, certainly - but you need some manual configuration to be done and 
on my mind it will be very good idea to try this on non-production box 
first.


--
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


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-12 Thread Carlos H. Cantu
IA When you have a single user (filling the info in the database) you don`t
IA feel the difference because it is basically the same CPU core doing the
IA work.

Here is more information (from my logs and memory):

The LOAD was set to simulate 10 users inserting information at the same
time so, there was 10 connections and 10 threads acting at the same
time to fill up the DB.

Some weird results also appeared when comparing FB 3 TPC-C results in
the notebook. FB 3 performance was 50% worse compared to FB 2.5
SS/CS/SC. From my logs:

2.5.1 CS - TPC-C Throughput: 1390.19 tpmC
2.5.1 SC - TPC-C Throughput: 1221.92 tpmC - Affinity set to 1
2.5.1 SS - TPC-C Throughput: 1306.06 tpmC

2.5.2 CS - TPC-C Throughput: 1144.95 tpmC
2.5.2 SC - TPC-C Throughput: 1156.87 tpmC - Affinity set to 1
2.5.2 SS - TPC-C Throughput: 1358.34 tpmC

3.0 SS - TPC-C Throughput: 514.43 tpmC (SharedCache was true and SharesDatabase 
was false)

Notebook config:

Windows 7 Pro 64bits
Intel Core i5 2410M
500GB Sata 7200rpm
8GB RAM

I agree that in a real scenario, a notebook would not be used as a
server, but I wonder why such bad performance, even when compared to
FB 2.5.2 SS attached to single CPU. Curious that the LOAD process
seems to not suffer from the problem.

I just hope nothing similar will show up in real servers, since it
would be very disappointing to the user if he moves to FB 3 expecting
huge improvement and find out that it started to behave worse than FB
2.5.

I plan to start a global testing campaign at FirebirdNews.org when
FB 3 alpha shows up, in the hope to detect all possible bad
behaviors and bugs, in the hope to speed up the release process.

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


--
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


Re: [Firebird-devel] True SMP support in SuperClassic and V3

2012-11-12 Thread Carlos H. Cantu
Sorry, the affinity setting was about SS, not SC. Wrong copy/paste ;-)

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

IA When you have a single user (filling the info in the database) you don`t
IA feel the difference because it is basically the same CPU core doing the
IA work.

CHC Here is more information (from my logs and memory):

CHC The LOAD was set to simulate 10 users inserting information at the same
CHC time so, there was 10 connections and 10 threads acting at the same
CHC time to fill up the DB.

CHC Some weird results also appeared when comparing FB 3 TPC-C results in
CHC the notebook. FB 3 performance was 50% worse compared to FB 2.5
CHC SS/CS/SC. From my logs:

CHC 2.5.1 CS - TPC-C Throughput: 1390.19 tpmC
CHC 2.5.1 SC - TPC-C Throughput: 1221.92 tpmC - Affinity set to 1
CHC 2.5.1 SS - TPC-C Throughput: 1306.06 tpmC

CHC 2.5.2 CS - TPC-C Throughput: 1144.95 tpmC
CHC 2.5.2 SC - TPC-C Throughput: 1156.87 tpmC - Affinity set to 1
CHC 2.5.2 SS - TPC-C Throughput: 1358.34 tpmC

CHC 3.0 SS - TPC-C Throughput: 514.43 tpmC (SharedCache was true and 
SharesDatabase was false)


--
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