No salting ? That may be an issue cause. Notice that hot region problem may
occure and
degrade performance a lot.
Thanks,
Sun.
CertusNet
From: Yohan Bismuth
Date: 2015-03-10 17:36
To: user
Subject: Re: Phoenix table scan performance
Hi thanks for your answer,
we're not using
.
Thanks,
Sun.
--
--
CertusNet
*From:* Yohan Bismuth yohan.bismu...@gmail.com
*Date:* 2015-03-10 17:36
*To:* user user@phoenix.apache.org
*Subject:* Re: Phoenix table scan performance
Hi thanks for your answer,
we're not using
During your scan with data on single region server (RS), do you see RS
blocked on disk I/O due to heavy reads or 100% CPU utilized? if that is the
case then having data distributed on 2 RS would effectively cut time in
half.
On Mon, Mar 9, 2015 at 10:01 AM, Yohan Bismuth yohan.bismu...@gmail.com
I've been facing this issue for a long time, so i'm pretty sure a major
compaction already occured.
Running your query returns 27006.
I have run update statistics on my table, this didn't solve my problem. But
if i understand well, these guideposts are used to parallelize scan over a
region, not
Hi Yohan,
Have you done a major compaction on your table and are stats generated
for your table? You can run this to confirm:
SELECT sum(guide_posts_count) from SYSTEM.STATS where
physical_name=your full table name;
Phoenix does intra-region parallelization based on these guideposts as
described
[mailto:yohan.bismu...@gmail.com]
*Sent:* Monday, March 09, 2015 5:02 PM
*To:* user@phoenix.apache.org
*Subject:* Phoenix table scan performance
Hello,
we're currently using Phoenix 4.2 with Hbase 0.98.6 from CDH5.3.2 on our
cluster and we're experiencing some perf issues.
What we need to do
From what i've seen, we're mostly idle during scans.
On Mon, Mar 9, 2015 at 6:11 PM, Mujtaba Chohan mujt...@apache.org wrote:
During your scan with data on single region server (RS), do you see RS
blocked on disk I/O due to heavy reads or 100% CPU utilized? if that is the
case then having
Hello,
we're currently using Phoenix 4.2 with Hbase 0.98.6 from CDH5.3.2 on our
cluster and we're experiencing some perf issues.
What we need to do is a full table scan over 1 billion rows. We've got 50
regionservers and approximatively 1000 regions of 1Gb equally distributed
on these rs (which
files to point to
aliases on the servers ultimately breaks cloudera and isn’t a viable solution
long term.
Thanks
John
From: Yohan Bismuth [mailto:yohan.bismu...@gmail.com]
Sent: Monday, March 09, 2015 5:02 PM
To: user@phoenix.apache.org
Subject: Phoenix table scan performance
Hello,
we're
performance can
be improved greately also.
Thanks,
Sun.
CertusNet
From: Yohan Bismuth
Date: 2015-03-10 01:01
To: user
Subject: Phoenix table scan performance
Hello,
we're currently using Phoenix 4.2 with Hbase 0.98.6 from CDH5.3.2 on our
cluster and we're experiencing some perf issues
10 matches
Mail list logo
