On Linux libnuma/numactl can be used to force the programs and the load on all cpu or the specified ones
http://oss.sgi.com/projects/libnuma/ www.redhat.com/summit/2012/pdf/2012-DevDay-Lab-NUMA-Hacker.pdf My guess that it can be done on windows too On Tue, Nov 20, 2012 at 6:11 AM, Poul Dige <p...@tabulex.dk> wrote: > > >> -----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 ------------------------------------------------------------------------------ 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
