We are not yet tuning specifically for NUMA. This recent testing had both NUMA and nonNUMA.
I count 64 logical cores in your example, so +S 32:32. On Aug 14, 2013, at 9:31 AM, Jeremiah Peschka <[email protected]> wrote: > Final question - does NUMA matter? > > e.g. quad socket system with 8 cores per socket + HT > > should it be +S 8:8 or +S 32:32 ? > > --- > Jeremiah Peschka - Founder, Brent Ozar Unlimited > MCITP: SQL Server 2008, MVP > Cloudera Certified Developer for Apache Hadoop > > > On Wed, Aug 14, 2013 at 4:14 AM, Matthew Von-Maszewski <[email protected]> > wrote: >> Yes, use logical CPU count. >> >> Matthew >> >> >> On Aug 13, 2013, at 23:17, Jeremiah Peschka <[email protected]> >> wrote: >> >>> When you say "CPU" does that mean "logical CPU core"? Or is this actually >>> referring to physical CPU cores? >>> >>> E.g. On my laptop with 4 physical cores + HyperThreading, should I set +S >>> to +S 4:4 >>> >>> You hint that it doesn't matter, but I just wanted to trick you into >>> explicitly saying something. >>> >>> --- >>> Jeremiah Peschka - Founder, Brent Ozar Unlimited >>> MCITP: SQL Server 2008, MVP >>> Cloudera Certified Developer for Apache Hadoop >>> >>> >>> On Tue, Aug 13, 2013 at 5:38 PM, Matthew Von-Maszewski <[email protected]> >>> wrote: >>>> ** The following is copied from Basho's leveldb wiki page: >>>> >>>> https://github.com/basho/leveldb/wiki/Riak-tuning-1 >>>> >>>> >>>> >>>> Summary: >>>> >>>> leveldb has a higher read and write throughput in Riak if the Erlang >>>> scheduler count is limited to half the number of CPU cores. Tests have >>>> demonstrated improvements of 15% to 80% greater throughput. >>>> >>>> The scheduler limit is set in the vm.args file: >>>> >>>> +S x:x >>>> >>>> where "x" is the number of schedulers Erlang may use. Erlang's default >>>> value of "x" is the total number of CPUs in the system. For Riak >>>> installations using leveldb, the recommendation is to set "x" to half the >>>> number of CPUs. Virtual environments are not yet tested. >>>> >>>> Example: for 24 CPU system >>>> >>>> +S 12:12 >>>> >>>> Discussion: >>>> >>>> We have tested a limited number of CPU configurations and customer loads. >>>> In all cases, there is a performance increase when the +S option is added >>>> to the vm.args file to reduce the number of Erlang schedulers. The working >>>> hypothesis is that the Erlang schedulers perform enough "busy wait" work >>>> that they always create context switch away from leveldb when leveldb is >>>> actually the only system task with real work. >>>> >>>> The tests included 8 CPU (no hyper threading, physical cores only) and 24 >>>> CPU (12 physical cores with hyper threading) systems. All were 64bit Intel >>>> platforms. Generalized findings: >>>> >>>> • servers running higher number of vnodes (64) had larger >>>> performance gains than those with fewer (8) >>>> • servers running SSD arrays had larger performance gains than >>>> those running SATA arrays >>>> • Get and Write operations showed performance gains, 2i query >>>> operations (leveldb iterators) were unchanged >>>> • Not recommended for servers with less than 8 CPUs (go no lower >>>> than +S 4:4) >>>> >>>> Performance improvements were as high as 80% over extended, heavily loaded >>>> intervals on servers with SSD arrays and 64 vnodes. No test resulted in >>>> worse performance due to the addition of +S x:x. >>>> >>>> The +S x:x configuration change does not have to be implemented >>>> simultaneously to an entire Riak cluster. The change may be applied to a >>>> single server for verification. Steps: update the vm.args file, then >>>> restart the Riak node. Erlang command line changes to schedules were >>>> ineffective. >>>> >>>> This configuration change has been running in at least one large, >>>> multi-datacenter production environment for several months. >>>> >>>> >>>> _______________________________________________ >>>> riak-users mailing list >>>> [email protected] >>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> _______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
