[jira] [Created] (PHOENIX-1515) explain cost
yang ming created PHOENIX-1515: -- Summary: explain cost Key: PHOENIX-1515 URL: https://issues.apache.org/jira/browse/PHOENIX-1515 Project: Phoenix Issue Type: Bug Reporter: yang ming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1515) explain time is too long
[
https://issues.apache.org/jira/browse/PHOENIX-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yang ming updated PHOENIX-1515:
---
Affects Version/s: 4.2
explain time is too long
Key: PHOENIX-1515
URL: https://issues.apache.org/jira/browse/PHOENIX-1515
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.2
Reporter: yang ming
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_SUMMARY_NEW
where videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_SUMMARY_NEW
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (0.056 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_REGION
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (8.109 seconds)
{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-1515) explain time is too long
[
https://issues.apache.org/jira/browse/PHOENIX-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yang ming updated PHOENIX-1515:
---
Description:
There are two Phoenix tables:YK.VIDEO_SUMMARY_NEW,YK.VIDEO_REGION,primary key
contains videoid.
Each table has about 60,000 million rows,before query likes the following cost
in millisecond,but now quering table YK.VIDEO_REGION cost nearly 10s,table
YK.VIDEO_SUMMARY_NEW still in millisecond.
Also the explains have the same results,so what cause this problem?
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++-+++++++++
| VIDEOID |DATE | PLATFORM | DEVICE | SYSTEMGROUP |
SYSTEM | VV | TS | UP |DOWN| COMMENT |
FAVORI | FAVO |
++-+++-+++++++++
| 183705534 | 2014-12-03 | app| computer | windows |
windows| 870| 663450 | null | null | null |
null | null |
| 183705534 | 2014-12-03 | app| mobile | android |
android| 21639 | 9232508| null | null | null |
null | null |
++-+++-+++++++++
2 rows selected (0.325 seconds)
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++++++
| VIDEOID |DATE | PLATFORM | DEVICE | PROVINCEID |
CITYID | VV | TS |
++-+++++++
| 183705534 | 2014-12-03 | app| computer | 11 |
11 | 39 | 30925 |
| 183705534 | 2014-12-03 | app| computer | 12 |
12 | 20 | 6021 |
++-+++++++
2 rows selected (8.169 seconds)
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_SUMMARY_NEW
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (0.056 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_REGION
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (8.109 seconds)
{color}
was:
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_SUMMARY_NEW
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (0.056 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_REGION
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (8.109 seconds)
{color}
explain time is too long
Key: PHOENIX-1515
URL: https://issues.apache.org/jira/browse/PHOENIX-1515
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.2
Reporter: yang ming
There are two Phoenix tables:YK.VIDEO_SUMMARY_NEW,YK.VIDEO_REGION,primary key
contains videoid.
Each table has about 60,000 million rows,before query likes the
[jira] [Updated] (PHOENIX-1515) explain time is too long
[
https://issues.apache.org/jira/browse/PHOENIX-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yang ming updated PHOENIX-1515:
---
Description:
There are two Phoenix tables:YK.VIDEO_SUMMARY_NEW,YK.VIDEO_REGION,primary key
contains videoid.
Each table has about 60,000 million rows,before query likes the following cost
in millisecond,but now quering table YK.VIDEO_REGION cost nearly 10s,table
YK.VIDEO_SUMMARY_NEW still in millisecond.
Also the explains have the same results,so what cause this problem?
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++-+++++++++
| VIDEOID |DATE | PLATFORM | DEVICE | SYSTEMGROUP |
SYSTEM | VV | TS | UP |DOWN| COMMENT |
FAVORI | FAVO |
++-+++-+++++++++
| 183705534 | 2014-12-03 | app| computer | windows |
windows| 870| 663450 | null | null | null |
null | null |
| 183705534 | 2014-12-03 | app| mobile | android |
android| 21639 | 9232508| null | null | null |
null | null |
++-+++-+++++++++
{color:red}
2 rows selected (0.325 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++++++
| VIDEOID |DATE | PLATFORM | DEVICE | PROVINCEID |
CITYID | VV | TS |
++-+++++++
| 183705534 | 2014-12-03 | app| computer | 11 |
11 | 39 | 30925 |
| 183705534 | 2014-12-03 | app| computer | 12 |
12 | 20 | 6021 |
++-+++++++
{color:red}
2 rows selected (8.169 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_SUMMARY_NEW
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (0.056 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_REGION
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (8.109 seconds)
{color}
was:
There are two Phoenix tables:YK.VIDEO_SUMMARY_NEW,YK.VIDEO_REGION,primary key
contains videoid.
Each table has about 60,000 million rows,before query likes the following cost
in millisecond,but now quering table YK.VIDEO_REGION cost nearly 10s,table
YK.VIDEO_SUMMARY_NEW still in millisecond.
Also the explains have the same results,so what cause this problem?
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++-+++++++++
| VIDEOID |DATE | PLATFORM | DEVICE | SYSTEMGROUP |
SYSTEM | VV | TS | UP |DOWN| COMMENT |
FAVORI | FAVO |
++-+++-+++++++++
| 183705534 | 2014-12-03 | app| computer | windows |
windows| 870| 663450 | null | null | null |
null | null |
| 183705534 | 2014-12-03 | app| mobile | android |
android| 21639 | 9232508| null
[jira] [Commented] (PHOENIX-1515) explain time is too long
[
https://issues.apache.org/jira/browse/PHOENIX-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240603#comment-14240603
]
yang ming commented on PHOENIX-1515:
[~jamestaylor], my cluster use the same version 4.2.
create table if not exists yk.video_summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
create table if not exists yk.video_region
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
provinceid varchar not null,
cityid varchar not null,
vv bigint,
ts bigint
constraint pk primary key (videoid, date,platform, device, provinceid, cityid)
)salt_buckets = 30,versions=1,compression='snappy';
explain time is too long
Key: PHOENIX-1515
URL: https://issues.apache.org/jira/browse/PHOENIX-1515
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.2
Reporter: yang ming
There are two Phoenix tables:YK.VIDEO_SUMMARY_NEW,YK.VIDEO_REGION,primary key
contains videoid.
Each table has about 60,000 million rows,before query likes the following
cost in millisecond,but now quering table YK.VIDEO_REGION cost nearly
10s,table YK.VIDEO_SUMMARY_NEW still in millisecond.
Also the explains have the same results,so what cause this problem?
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++-+++++++++
| VIDEOID |DATE | PLATFORM | DEVICE | SYSTEMGROUP |
SYSTEM | VV | TS | UP |DOWN| COMMENT |
FAVORI | FAVO |
++-+++-+++++++++
| 183705534 | 2014-12-03 | app| computer | windows |
windows| 870| 663450 | null | null | null |
null | null |
| 183705534 | 2014-12-03 | app| mobile | android |
android| 21639 | 9232508| null | null | null |
null | null |
++-+++-+++++++++
{color:red}
2 rows selected (0.325 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++++++
| VIDEOID |DATE | PLATFORM | DEVICE | PROVINCEID |
CITYID | VV | TS |
++-+++++++
| 183705534 | 2014-12-03 | app| computer | 11 |
11 | 39 | 30925 |
| 183705534 | 2014-12-03 | app| computer | 12 |
12 | 20 | 6021 |
++-+++++++
{color:red}
2 rows selected (8.169 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_SUMMARY_NEW
where videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_SUMMARY_NEW
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (0.056 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_REGION
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (8.109 seconds)
{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1515) explain time is too long
[
https://issues.apache.org/jira/browse/PHOENIX-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240607#comment-14240607
]
yang ming commented on PHOENIX-1515:
From 2014.12.05,this problem occurs.
And insert 20 million rows into table yk.video_region with 'upsert into' cost
nearly 3 hour now,before just 10 minute.
explain time is too long
Key: PHOENIX-1515
URL: https://issues.apache.org/jira/browse/PHOENIX-1515
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.2
Reporter: yang ming
There are two Phoenix tables:YK.VIDEO_SUMMARY_NEW,YK.VIDEO_REGION,primary key
contains videoid.
Each table has about 60,000 million rows,before query likes the following
cost in millisecond,but now quering table YK.VIDEO_REGION cost nearly
10s,table YK.VIDEO_SUMMARY_NEW still in millisecond.
Also the explains have the same results,so what cause this problem?
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++-+++++++++
| VIDEOID |DATE | PLATFORM | DEVICE | SYSTEMGROUP |
SYSTEM | VV | TS | UP |DOWN| COMMENT |
FAVORI | FAVO |
++-+++-+++++++++
| 183705534 | 2014-12-03 | app| computer | windows |
windows| 870| 663450 | null | null | null |
null | null |
| 183705534 | 2014-12-03 | app| mobile | android |
android| 21639 | 9232508| null | null | null |
null | null |
++-+++-+++++++++
{color:red}
2 rows selected (0.325 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++++++
| VIDEOID |DATE | PLATFORM | DEVICE | PROVINCEID |
CITYID | VV | TS |
++-+++++++
| 183705534 | 2014-12-03 | app| computer | 11 |
11 | 39 | 30925 |
| 183705534 | 2014-12-03 | app| computer | 12 |
12 | 20 | 6021 |
++-+++++++
{color:red}
2 rows selected (8.169 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_SUMMARY_NEW
where videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_SUMMARY_NEW
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (0.056 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_REGION
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (8.109 seconds)
{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1515) explain time is too long
[
https://issues.apache.org/jira/browse/PHOENIX-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240612#comment-14240612
]
yang ming commented on PHOENIX-1515:
@[~jamestaylor],I guess,is the explain or sql compile cause this problem?
explain time is too long
Key: PHOENIX-1515
URL: https://issues.apache.org/jira/browse/PHOENIX-1515
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.2
Reporter: yang ming
There are two Phoenix tables:YK.VIDEO_SUMMARY_NEW,YK.VIDEO_REGION,primary key
contains videoid.
Each table has about 60,000 million rows,before query likes the following
cost in millisecond,but now quering table YK.VIDEO_REGION cost nearly
10s,table YK.VIDEO_SUMMARY_NEW still in millisecond.
Also the explains have the same results,so what cause this problem?
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++-+++++++++
| VIDEOID |DATE | PLATFORM | DEVICE | SYSTEMGROUP |
SYSTEM | VV | TS | UP |DOWN| COMMENT |
FAVORI | FAVO |
++-+++-+++++++++
| 183705534 | 2014-12-03 | app| computer | windows |
windows| 870| 663450 | null | null | null |
null | null |
| 183705534 | 2014-12-03 | app| mobile | android |
android| 21639 | 9232508| null | null | null |
null | null |
++-+++-+++++++++
{color:red}
2 rows selected (0.325 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++++++
| VIDEOID |DATE | PLATFORM | DEVICE | PROVINCEID |
CITYID | VV | TS |
++-+++++++
| 183705534 | 2014-12-03 | app| computer | 11 |
11 | 39 | 30925 |
| 183705534 | 2014-12-03 | app| computer | 12 |
12 | 20 | 6021 |
++-+++++++
{color:red}
2 rows selected (8.169 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_SUMMARY_NEW
where videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_SUMMARY_NEW
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (0.056 seconds)
{color}
0: jdbc:phoenix:10.103.23.82 explain select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++
|PLAN|
++
| CLIENT PARALLEL 30-WAY RANGE SCAN OVER YK.VIDEO_REGION
[0,183705534,'2014-12-03 00:00:00.000'] |
| SERVER FILTER BY PageFilter 2 |
| SERVER 2 ROW LIMIT |
| CLIENT MERGE SORT |
| CLIENT 2 ROW LIMIT |
++
{color:red}
5 rows selected (8.109 seconds)
{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-1515) explain time is too long
[
https://issues.apache.org/jira/browse/PHOENIX-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240630#comment-14240630
]
yang ming commented on PHOENIX-1515:
sqlline version 1.1.2
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_REGION where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++++++
| VIDEOID |DATE | PLATFORM | DEVICE | PROVINCEID |
CITYID | VV | TS |
++-+++++++
| 183705534 | 2014-12-03 | app| computer | 11 |
11 | 39 | 30925 |
| 183705534 | 2014-12-03 | app| computer | 12 |
12 | 20 | 6021 |
++-+++++++
2 rows selected (9.083 seconds)
jstack:
main prio=10 tid=0x0c9f1000 nid=0x3263 waiting on condition
[0x41b2b000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0x000785d24b40 (a
org.apache.phoenix.job.JobManager$JobFutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:425)
at java.util.concurrent.FutureTask.get(FutureTask.java:187)
at
org.apache.hadoop.hbase.client.HTable.coprocessorService(HTable.java:1554)
at
org.apache.hadoop.hbase.client.HTable.coprocessorService(HTable.java:1511)
at
org.apache.phoenix.query.ConnectionQueryServicesImpl.metaDataCoprocessorExec(ConnectionQueryServicesImpl.java:917)
at
org.apache.phoenix.query.ConnectionQueryServicesImpl.getTable(ConnectionQueryServicesImpl.java:1161)
at
org.apache.phoenix.schema.MetaDataClient.updateCache(MetaDataClient.java:348)
at
org.apache.phoenix.schema.MetaDataClient.updateCache(MetaDataClient.java:307)
at
org.apache.phoenix.schema.MetaDataClient.updateCache(MetaDataClient.java:303)
at
org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:299)
at
org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.init(FromCompiler.java:215)
at
org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:159)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:374)
at
org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:139)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:311)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:294)
at
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:215)
at
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:211)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:210)
at
org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1040)
at sqlline.SqlLine$Commands.execute(SqlLine.java:3673)
at sqlline.SqlLine$Commands.sql(SqlLine.java:3584)
at sqlline.SqlLine.dispatch(SqlLine.java:821)
at sqlline.SqlLine.begin(SqlLine.java:699)
at sqlline.SqlLine.mainWithInputRedirection(SqlLine.java:441)
at sqlline.SqlLine.main(SqlLine.java:424)
explain time is too long
Key: PHOENIX-1515
URL: https://issues.apache.org/jira/browse/PHOENIX-1515
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.2
Reporter: yang ming
There are two Phoenix tables:YK.VIDEO_SUMMARY_NEW,YK.VIDEO_REGION,primary key
contains videoid.
Each table has about 60,000 million rows,before query likes the following
cost in millisecond,but now quering table YK.VIDEO_REGION cost nearly
10s,table YK.VIDEO_SUMMARY_NEW still in millisecond.
Also the explains have the same results,so what cause this problem?
0: jdbc:phoenix:10.103.23.82 select * from YK.VIDEO_SUMMARY_NEW where
videoid=183705534 and date=to_date('20141203','MMdd') limit 2;
++-+++-+++++++++
| VIDEOID |DATE | PLATFORM | DEVICE | SYSTEMGROUP |
SYSTEM | VV | TS | UP |DOWN| COMMENT |
FAVORI | FAVO |
[jira] [Commented] (PHOENIX-1081) CPU usage 100% With phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059493#comment-14059493
]
yang ming commented on PHOENIX-1081:
IPC Server handler 69 on 60020 daemon prio=10 tid=0x4def5000
nid=0x31ed runnable [0x48c36000]
java.lang.Thread.State: RUNNABLE
at
org.apache.phoenix.filter.SkipScanFilter.navigate(SkipScanFilter.java:288)
at
org.apache.phoenix.filter.SkipScanFilter.filterKeyValue(SkipScanFilter.java:112)
at
org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.match(ScanQueryMatcher.java:354)
{color:red}
at
org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:390)
{color}
at
org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:143)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.populateResult(HRegion.java:4047)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:4123)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:3990)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:3980)
at
org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver.scanUnordered(GroupedAggregateRegionObserver.java:384)
at
org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver.doPostScannerOpen(GroupedAggregateRegionObserver.java:133)
at
org.apache.phoenix.coprocessor.BaseScannerRegionObserver.postScannerOpen(BaseScannerRegionObserver.java:66)
at
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postScannerOpen(RegionCoprocessorHost.java:1316)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.internalOpenScanner(HRegionServer.java:2588)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.openScanner(HRegionServer.java:2556)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:323)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1434)
CPU usage 100% With phoenix
Key: PHOENIX-1081
URL: https://issues.apache.org/jira/browse/PHOENIX-1081
Project: Phoenix
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: yang ming
Priority: Critical
Attachments: JMX.jpg, jstat.jpg, the jstack of all threads, the
jstack of thread 12725.jpg, the jstack of thread 12748.jpg, the threads of
regionserver process.jpg
The concurrent of the system is not high,but CPU usage often up to 100%.
I had stopped the system,but regionserver's CPU usage is still high.
what can case this problem?
table row count：6000 million
table ddl：
create table if not exists summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
query 1：
select sum(vv) as sumvv,sum(comment) as sumcomment,sum(up) as sumup,sum(down)
as sumdown,sum(reply) as sumreply,count(*) as count from summary(reply
bigint) where videoid
in(137102991,151113895,171559204,171559439,171573932,171573932,171573932,171574082,171574082,171574164,171677219,171794335,171902734,172364368,172475141,172700554,172700554,172700554,172716705,172784258,172835778,173112067,173165316,173165316,173379601,173448315,173503961,173692664,173911358,174077089,174099017,174349633,174349877,174651474,174651474,174759297,174883566,174883566,174987670,174987670,175131298)
and date=to_date('2013-09-01','-MM-dd') and
date=to_date('2014-07-07','-MM-dd')
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PHOENIX-1081) CPU usage 100% With phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059499#comment-14059499
]
yang ming commented on PHOENIX-1081:
Hbase version is 0.94.19.I had added some debug log,may be the endless loop is
here.
LOOP: while((kv = this.heap.peek()) != null) {
// Check that the heap gives us KVs in an increasing order.
assert prevKV == null || comparator == null ||
comparator.compare(prevKV, kv) = 0 :
Key + prevKV + followed by a + smaller key + kv + in cf
+ store;
prevKV = kv;
{color:red}
ScanQueryMatcher.MatchCode qcode = matcher.match(kv);
{color}
switch(qcode) {
case INCLUDE:
case INCLUDE_AND_SEEK_NEXT_ROW:
case INCLUDE_AND_SEEK_NEXT_COL:
Filter f = matcher.getFilter();
outResult.add(f == null ? kv : f.transform(kv));
count++;
CPU usage 100% With phoenix
Key: PHOENIX-1081
URL: https://issues.apache.org/jira/browse/PHOENIX-1081
Project: Phoenix
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: yang ming
Priority: Critical
Attachments: JMX.jpg, jstat.jpg, the jstack of all threads, the
jstack of thread 12725.jpg, the jstack of thread 12748.jpg, the threads of
regionserver process.jpg
The concurrent of the system is not high,but CPU usage often up to 100%.
I had stopped the system,but regionserver's CPU usage is still high.
what can case this problem?
table row count：6000 million
table ddl：
create table if not exists summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
query 1：
select sum(vv) as sumvv,sum(comment) as sumcomment,sum(up) as sumup,sum(down)
as sumdown,sum(reply) as sumreply,count(*) as count from summary(reply
bigint) where videoid
in(137102991,151113895,171559204,171559439,171573932,171573932,171573932,171574082,171574082,171574164,171677219,171794335,171902734,172364368,172475141,172700554,172700554,172700554,172716705,172784258,172835778,173112067,173165316,173165316,173379601,173448315,173503961,173692664,173911358,174077089,174099017,174349633,174349877,174651474,174651474,174759297,174883566,174883566,174987670,174987670,175131298)
and date=to_date('2013-09-01','-MM-dd') and
date=to_date('2014-07-07','-MM-dd')
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (PHOENIX-1081) CPU usage 100% With phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059493#comment-14059493
]
yang ming edited comment on PHOENIX-1081 at 7/11/14 11:37 PM:
--
IPC Server handler 69 on 60020 daemon prio=10 tid=0x4def5000
nid=0x31ed runnable [0x48c36000]
java.lang.Thread.State: RUNNABLE
at
org.apache.phoenix.filter.SkipScanFilter.navigate(SkipScanFilter.java:288)
at
org.apache.phoenix.filter.SkipScanFilter.filterKeyValue(SkipScanFilter.java:112)
{color:blue}at
org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.match(ScanQueryMatcher.java:354){color}
{color:red}at
org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:390){color}
at
org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:143)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.populateResult(HRegion.java:4047)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:4123)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:3990)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:3980)
at
org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver.scanUnordered(GroupedAggregateRegionObserver.java:384)
at
org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver.doPostScannerOpen(GroupedAggregateRegionObserver.java:133)
at
org.apache.phoenix.coprocessor.BaseScannerRegionObserver.postScannerOpen(BaseScannerRegionObserver.java:66)
at
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postScannerOpen(RegionCoprocessorHost.java:1316)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.internalOpenScanner(HRegionServer.java:2588)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.openScanner(HRegionServer.java:2556)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:323)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1434)
was (Author: yangming860101):
IPC Server handler 69 on 60020 daemon prio=10 tid=0x4def5000
nid=0x31ed runnable [0x48c36000]
java.lang.Thread.State: RUNNABLE
at
org.apache.phoenix.filter.SkipScanFilter.navigate(SkipScanFilter.java:288)
at
org.apache.phoenix.filter.SkipScanFilter.filterKeyValue(SkipScanFilter.java:112)
at
{color:blue}org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.match(ScanQueryMatcher.java:354){color}
{color:red}at
org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:390){color}
at
org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:143)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.populateResult(HRegion.java:4047)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:4123)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:3990)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:3980)
at
org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver.scanUnordered(GroupedAggregateRegionObserver.java:384)
at
org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver.doPostScannerOpen(GroupedAggregateRegionObserver.java:133)
at
org.apache.phoenix.coprocessor.BaseScannerRegionObserver.postScannerOpen(BaseScannerRegionObserver.java:66)
at
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postScannerOpen(RegionCoprocessorHost.java:1316)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.internalOpenScanner(HRegionServer.java:2588)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.openScanner(HRegionServer.java:2556)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:323)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1434)
CPU usage 100% With phoenix
Key: PHOENIX-1081
URL: https://issues.apache.org/jira/browse/PHOENIX-1081
Project: Phoenix
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: yang ming
[jira] [Comment Edited] (PHOENIX-1081) CPU usage 100% With phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059499#comment-14059499
]
yang ming edited comment on PHOENIX-1081 at 7/11/14 11:37 PM:
--
Hbase version is 0.94.19.I had added some debug log,may be the endless loop is
here.
{color:red}at
org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:390){color}
LOOP: while((kv = this.heap.peek()) != null) {
// Check that the heap gives us KVs in an increasing order.
assert prevKV == null || comparator == null ||
comparator.compare(prevKV, kv) = 0 :
Key + prevKV + followed by a + smaller key + kv + in cf
+ store;
prevKV = kv;
{color:red}
ScanQueryMatcher.MatchCode qcode = matcher.match(kv);
{color}
switch(qcode) {
case INCLUDE:
case INCLUDE_AND_SEEK_NEXT_ROW:
case INCLUDE_AND_SEEK_NEXT_COL:
Filter f = matcher.getFilter();
outResult.add(f == null ? kv : f.transform(kv));
count++;
was (Author: yangming860101):
Hbase version is 0.94.19.I had added some debug log,may be the endless loop is
here.
LOOP: while((kv = this.heap.peek()) != null) {
// Check that the heap gives us KVs in an increasing order.
assert prevKV == null || comparator == null ||
comparator.compare(prevKV, kv) = 0 :
Key + prevKV + followed by a + smaller key + kv + in cf
+ store;
prevKV = kv;
{color:red}
ScanQueryMatcher.MatchCode qcode = matcher.match(kv);
{color}
switch(qcode) {
case INCLUDE:
case INCLUDE_AND_SEEK_NEXT_ROW:
case INCLUDE_AND_SEEK_NEXT_COL:
Filter f = matcher.getFilter();
outResult.add(f == null ? kv : f.transform(kv));
count++;
CPU usage 100% With phoenix
Key: PHOENIX-1081
URL: https://issues.apache.org/jira/browse/PHOENIX-1081
Project: Phoenix
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: yang ming
Priority: Critical
Attachments: JMX.jpg, jstat.jpg, the jstack of all threads, the
jstack of thread 12725.jpg, the jstack of thread 12748.jpg, the threads of
regionserver process.jpg
The concurrent of the system is not high,but CPU usage often up to 100%.
I had stopped the system,but regionserver's CPU usage is still high.
what can case this problem?
table row count：6000 million
table ddl：
create table if not exists summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
query 1：
select sum(vv) as sumvv,sum(comment) as sumcomment,sum(up) as sumup,sum(down)
as sumdown,sum(reply) as sumreply,count(*) as count from summary(reply
bigint) where videoid
in(137102991,151113895,171559204,171559439,171573932,171573932,171573932,171574082,171574082,171574164,171677219,171794335,171902734,172364368,172475141,172700554,172700554,172700554,172716705,172784258,172835778,173112067,173165316,173165316,173379601,173448315,173503961,173692664,173911358,174077089,174099017,174349633,174349877,174651474,174651474,174759297,174883566,174883566,174987670,174987670,175131298)
and date=to_date('2013-09-01','-MM-dd') and
date=to_date('2014-07-07','-MM-dd')
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (PHOENIX-1081) CPU usage 100% With phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059499#comment-14059499
]
yang ming edited comment on PHOENIX-1081 at 7/11/14 11:39 PM:
--
Hbase version is 0.94.19.I had added some debug log,may be the endless loop is
here.
{color:red}at
org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:390){color}
And the problem may be in this method.
{color:blue}at org.apache.phoenix.filter.SkipScanFilter.navigate{color}
LOOP: while((kv = this.heap.peek()) != null) {
// Check that the heap gives us KVs in an increasing order.
assert prevKV == null || comparator == null ||
comparator.compare(prevKV, kv) = 0 :
Key + prevKV + followed by a + smaller key + kv + in cf
+ store;
prevKV = kv;
{color:red}
ScanQueryMatcher.MatchCode qcode = matcher.match(kv);
{color}
switch(qcode) {
case INCLUDE:
case INCLUDE_AND_SEEK_NEXT_ROW:
case INCLUDE_AND_SEEK_NEXT_COL:
Filter f = matcher.getFilter();
outResult.add(f == null ? kv : f.transform(kv));
count++;
was (Author: yangming860101):
Hbase version is 0.94.19.I had added some debug log,may be the endless loop is
here.
{color:red}at
org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:390){color}
And the problem may be in this method.
{color:blue}at org.apache.phoenix.filter.SkipScanFilter.navigate{blue}
LOOP: while((kv = this.heap.peek()) != null) {
// Check that the heap gives us KVs in an increasing order.
assert prevKV == null || comparator == null ||
comparator.compare(prevKV, kv) = 0 :
Key + prevKV + followed by a + smaller key + kv + in cf
+ store;
prevKV = kv;
{color:red}
ScanQueryMatcher.MatchCode qcode = matcher.match(kv);
{color}
switch(qcode) {
case INCLUDE:
case INCLUDE_AND_SEEK_NEXT_ROW:
case INCLUDE_AND_SEEK_NEXT_COL:
Filter f = matcher.getFilter();
outResult.add(f == null ? kv : f.transform(kv));
count++;
CPU usage 100% With phoenix
Key: PHOENIX-1081
URL: https://issues.apache.org/jira/browse/PHOENIX-1081
Project: Phoenix
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: yang ming
Priority: Critical
Attachments: JMX.jpg, jstat.jpg, the jstack of all threads, the
jstack of thread 12725.jpg, the jstack of thread 12748.jpg, the threads of
regionserver process.jpg
The concurrent of the system is not high,but CPU usage often up to 100%.
I had stopped the system,but regionserver's CPU usage is still high.
what can case this problem?
table row count：6000 million
table ddl：
create table if not exists summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
query 1：
select sum(vv) as sumvv,sum(comment) as sumcomment,sum(up) as sumup,sum(down)
as sumdown,sum(reply) as sumreply,count(*) as count from summary(reply
bigint) where videoid
in(137102991,151113895,171559204,171559439,171573932,171573932,171573932,171574082,171574082,171574164,171677219,171794335,171902734,172364368,172475141,172700554,172700554,172700554,172716705,172784258,172835778,173112067,173165316,173165316,173379601,173448315,173503961,173692664,173911358,174077089,174099017,174349633,174349877,174651474,174651474,174759297,174883566,174883566,174987670,174987670,175131298)
and date=to_date('2013-09-01','-MM-dd') and
date=to_date('2014-07-07','-MM-dd')
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PHOENIX-1081) With phoenix case CPU usage 100%
[
https://issues.apache.org/jira/browse/PHOENIX-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yang ming updated PHOENIX-1081:
---
Description:
The concurrent of the system is not highly,but CPU usage often up to 100%.
I had stopped the system,but regionserver's CPU usage is still high.
what can case this problem?
table row count：6000 million
table ddl：
create table if not exists summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
query 1：
select sum(vv) as sumvv,sum(comment) as sumcomment,sum(up) as sumup,sum(down)
as sumdown,sum(reply) as sumreply,count(*) as count from summary(reply bigint)
where videoid
in(137102991,151113895,171559204,171559439,171573932,171573932,171573932,171574082,171574082,171574164,171677219,171794335,171902734,172364368,172475141,172700554,172700554,172700554,172716705,172784258,172835778,173112067,173165316,173165316,173379601,173448315,173503961,173692664,173911358,174077089,174099017,174349633,174349877,174651474,174651474,174759297,174883566,174883566,174987670,174987670,175131298)
and date=to_date('2013-09-01','-MM-dd') and
date=to_date('2014-07-07','-MM-dd')
was:
The system is not highly concurrent access,but CPU usage often 100%.
I had stopped the system,but regionserver's CPU usage is still high.
what can case this problem?
table row count：6000 million
table ddl：
create table if not exists summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
query 1：
select sum(vv) as sumvv,sum(comment) as sumcomment,sum(up) as sumup,sum(down)
as sumdown,sum(reply) as sumreply,count(*) as count from summary(reply bigint)
where videoid
in(137102991,151113895,171559204,171559439,171573932,171573932,171573932,171574082,171574082,171574164,171677219,171794335,171902734,172364368,172475141,172700554,172700554,172700554,172716705,172784258,172835778,173112067,173165316,173165316,173379601,173448315,173503961,173692664,173911358,174077089,174099017,174349633,174349877,174651474,174651474,174759297,174883566,174883566,174987670,174987670,175131298)
and date=to_date('2013-09-01','-MM-dd') and
date=to_date('2014-07-07','-MM-dd')
With phoenix case CPU usage 100%
Key: PHOENIX-1081
URL: https://issues.apache.org/jira/browse/PHOENIX-1081
Project: Phoenix
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: yang ming
Priority: Critical
The concurrent of the system is not highly,but CPU usage often up to 100%.
I had stopped the system,but regionserver's CPU usage is still high.
what can case this problem?
table row count：6000 million
table ddl：
create table if not exists summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
query 1：
select sum(vv) as sumvv,sum(comment) as sumcomment,sum(up) as sumup,sum(down)
as sumdown,sum(reply) as sumreply,count(*) as count from summary(reply
bigint) where videoid
in(137102991,151113895,171559204,171559439,171573932,171573932,171573932,171574082,171574082,171574164,171677219,171794335,171902734,172364368,172475141,172700554,172700554,172700554,172716705,172784258,172835778,173112067,173165316,173165316,173379601,173448315,173503961,173692664,173911358,174077089,174099017,174349633,174349877,174651474,174651474,174759297,174883566,174883566,174987670,174987670,175131298)
and date=to_date('2013-09-01','-MM-dd') and
date=to_date('2014-07-07','-MM-dd')
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PHOENIX-1081) CPU usage 100% With phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yang ming updated PHOENIX-1081:
---
Summary: CPU usage 100% With phoenix (was: With phoenix case CPU usage
100%)
CPU usage 100% With phoenix
Key: PHOENIX-1081
URL: https://issues.apache.org/jira/browse/PHOENIX-1081
Project: Phoenix
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: yang ming
Priority: Critical
Attachments: JMX.jpg, jstat.jpg, the jstack of all threads, the
jstack of thread 12725.jpg, the jstack of thread 12748.jpg, the threads of
regionserver process.jpg
The concurrent of the system is not high,but CPU usage often up to 100%.
I had stopped the system,but regionserver's CPU usage is still high.
what can case this problem?
table row count：6000 million
table ddl：
create table if not exists summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
query 1：
select sum(vv) as sumvv,sum(comment) as sumcomment,sum(up) as sumup,sum(down)
as sumdown,sum(reply) as sumreply,count(*) as count from summary(reply
bigint) where videoid
in(137102991,151113895,171559204,171559439,171573932,171573932,171573932,171574082,171574082,171574164,171677219,171794335,171902734,172364368,172475141,172700554,172700554,172700554,172716705,172784258,172835778,173112067,173165316,173165316,173379601,173448315,173503961,173692664,173911358,174077089,174099017,174349633,174349877,174651474,174651474,174759297,174883566,174883566,174987670,174987670,175131298)
and date=to_date('2013-09-01','-MM-dd') and
date=to_date('2014-07-07','-MM-dd')
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PHOENIX-1081) CPU usage 100% With phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14057581#comment-14057581
]
yang ming commented on PHOENIX-1081:
[~jamestaylor]
CPU usage 100% With phoenix
Key: PHOENIX-1081
URL: https://issues.apache.org/jira/browse/PHOENIX-1081
Project: Phoenix
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: yang ming
Priority: Critical
Attachments: JMX.jpg, jstat.jpg, the jstack of all threads, the
jstack of thread 12725.jpg, the jstack of thread 12748.jpg, the threads of
regionserver process.jpg
The concurrent of the system is not high,but CPU usage often up to 100%.
I had stopped the system,but regionserver's CPU usage is still high.
what can case this problem?
table row count：6000 million
table ddl：
create table if not exists summary
(
videoid integer not null,
date date not null,
platform varchar not null,
device varchar not null,
systemgroup varchar not null,
system varchar not null,
vv bigint,
ts bigint,
up bigint,
down bigint,
comment bigint,
favori bigint,
favord bigint,
quote bigint,
reply bigint
constraint pk primary key (videoid, date,platform, device, systemgroup,system)
)salt_buckets = 30,versions=1,compression='snappy';
query 1：
select sum(vv) as sumvv,sum(comment) as sumcomment,sum(up) as sumup,sum(down)
as sumdown,sum(reply) as sumreply,count(*) as count from summary(reply
bigint) where videoid
in(137102991,151113895,171559204,171559439,171573932,171573932,171573932,171574082,171574082,171574164,171677219,171794335,171902734,172364368,172475141,172700554,172700554,172700554,172716705,172784258,172835778,173112067,173165316,173165316,173379601,173448315,173503961,173692664,173911358,174077089,174099017,174349633,174349877,174651474,174651474,174759297,174883566,174883566,174987670,174987670,175131298)
and date=to_date('2013-09-01','-MM-dd') and
date=to_date('2014-07-07','-MM-dd')
--
This message was sent by Atlassian JIRA
(v6.2#6252)
