hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Multiwal performance with HBase 1.x
Date Fri, 18 Sep 2015 17:14:18 GMT
> You postpone compaction until your test completes by setting number of blocking
stores to 120.

We don't recommend a setting like that for production. I'm not sure what
the consensus would be but in our production that setting is 20. The
default is half that so is very likely typical.



On Fri, Sep 18, 2015 at 9:55 AM, Vladimir Rodionov <vladrodionov@gmail.com>
wrote:

> Hi, Jingcheng
>
> You postpone compaction until your test completes by setting number of
> blocking stores to 120. That is kind of cheating :)
> As I said previously, in a long run, compaction rules the world - not
> number of wal files. In a real production setting, the existing write
> performance
> is more than adequate (avg load per RS usually less than 1MB/sec). Multiwal
> has probably its value if someone need to load quick large volume of data,
> but ... why do not use bulk load instead?
>
> Thank for letting us know that beefy servers with 8 SSDs can sustain such a
> huge load.
>
> -Vlad
>
>
>
> On Thu, Sep 17, 2015 at 10:30 PM, Jingcheng Du <jingcheng.du@intel.com>
> wrote:
>
> > More information for the test.
> > I use ycsb 0.3.0 for the test.
> > The command line is "./ycsb load hbase-10 -P ../workloads/workload
> -threads
> > 200 -p columnfamily=family -p clientbuffering=true -s > workload.dat"
> > The workload is, the data size is slightly less than 1TB:
> > fieldcount=5
> > fieldlength=200
> > recordcount=1000000000
> > maxexecutiontime=86400
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-hbase.679495.n3.nabble.com/Multiwal-performance-with-HBase-1-x-tp4074403p4074731.html
> > Sent from the HBase User mailing list archive at Nabble.com.
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message