"threads=8" is the key phrase … +S 4:4 On Aug 14, 2013, at 10:04 AM, Guido Medina <guido.med...@temetra.com> wrote:
> For the following information should it be +S 4:4 or +S 4:8? > > root@somehost# lshw -C processor > *-cpu > description: CPU > product: Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz > vendor: Intel Corp. > physical id: 4 > bus info: cpu@0 > version: Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz > serial: To Be Filled By O.E.M. > slot: CPU 1 > size: 1600MHz > capacity: 1600MHz > width: 64 bits > clock: 133MHz > capabilities: x86-64 fpu fpu_exception wp vme de pse tsc msr pae mce > cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 > ss ht tm pbe syscall nx rdtscp constant_tsc arch_perfmon pebs bts rep_good > nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 > ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi > flexpriority ept vpid cpufreq > configuration: cores=4 enabledcores=4 threads=8 > > Thanks, > > Guido. > > On 14/08/13 01:38, Matthew Von-Maszewski 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 >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
