[
https://issues.apache.org/jira/browse/PHOENIX-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208732#comment-14208732
]
Samarth Jain commented on PHOENIX-1435:
---------------------------------------
{code}
@Test
public void testPhoenixPerformanceOnHighNumberofGuidePosts() throws
Exception {
Connection conn;
Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
conn = DriverManager.getConnection(getUrl(), props);
conn.createStatement().execute(
"CREATE TABLE TEST (k VARCHAR PRIMARY KEY, v VARCHAR) " +
HColumnDescriptor.KEEP_DELETED_CELLS + "=" + Boolean.FALSE);
conn.createStatement().execute("CREATE TABLE SMALL_TEST (k VARCHAR
PRIMARY KEY, v VARCHAR) " + HColumnDescriptor.KEEP_DELETED_CELLS + "=" +
Boolean.FALSE);
PreparedStatement stmt = conn.prepareStatement("UPSERT INTO TEST VALUES
(? ,?)");
PreparedStatement stmt2 = conn.prepareStatement("UPSERT INTO SMALL_TEST
VALUES (?, ?)");
// upsert records. Each row ends up exceeding 20 bytes provided for
guide post width.
// So we will have numRecords guide posts.
// upsert records in bigger table.
int numRecords = 10000;
for (int i = 0; i < numRecords; i++) {
stmt.setString(1, "key" + i);
stmt.setString(2, "value");
stmt.executeUpdate();
if (i % 10000 == 0 && i > 0) {
conn.commit();
}
}
conn.commit();
// upsert records in smaller table.
int smallNumRecords = 10;
for (int i = 0; i < smallNumRecords; i++) {
stmt2.setString(1, "key" + i);
stmt2.setString(2, "value");
stmt2.executeUpdate();
}
conn.commit();
// flush the two tables.
ConnectionQueryServices services =
conn.unwrap(PhoenixConnection.class).getQueryServices();
flush(services, "TEST");
flush(services, "SMALL_TEST");
// Get stats collected
TestUtil.analyzeTable(conn, "TEST");
TestUtil.analyzeTable(conn, "SMALL_TEST");
// check number of guide posts.
ResultSet rs = conn.createStatement().executeQuery("SELECT
GUIDE_POSTS_COUNT, REGION_NAME FROM SYSTEM.STATS WHERE PHYSICAL_NAME='TEST' AND
REGION_NAME IS NOT NULL");
assertTrue(rs.next());
assertEquals(numRecords, rs.getLong(1));
assertFalse(rs.next());
rs = conn.createStatement().executeQuery("EXPLAIN SELECT * FROM TEST");
assertEquals("CLIENT " + (numRecords+1) + "-CHUNK " + "PARALLEL 1-WAY
FULL SCAN OVER TEST", QueryUtil.getExplainPlan(rs));
rs = conn.createStatement().executeQuery("EXPLAIN SELECT * FROM
SMALL_TEST");
assertEquals("CLIENT " + (smallNumRecords+1) + "-CHUNK " + "PARALLEL
1-WAY FULL SCAN OVER SMALL_TEST", QueryUtil.getExplainPlan(rs));
// Execute a query that will use all the 10K guide posts. The query
should fail and get rejected by the job manager.
// Futures that were not started should get cleaned up.
try {
rs = conn.createStatement().executeQuery("SELECT * FROM TEST");
while(rs.next()) {}
fail("Query execution should have failed");
} catch (Exception expected) {}
// try a 10-way parallel query. This should work if the queue clean up
worked correctly.
rs = conn.createStatement().executeQuery("SELECT * FROM SMALL_TEST");
while(rs.next());
}
private void flush(ConnectionQueryServices services, String tableName)
throws Exception {
services.getAdmin().flush(SchemaUtil.getTableNameAsBytes(null,
tableName));
}
{code}
The test fails when it is trying to execute the second query which uses 10-way
parallelization. Not sure if the queue clean up/cancelling futures is working
correctly. For the test I had a thread pool size of 20 and a queue depth of
5000.
Stacktrace:
java.sql.SQLException: java.util.concurrent.RejectedExecutionException
at
org.apache.phoenix.query.ConnectionQueryServicesImpl.metaDataCoprocessorExec(ConnectionQueryServicesImpl.java:938)
at
org.apache.phoenix.query.ConnectionQueryServicesImpl.getTable(ConnectionQueryServicesImpl.java:1164)
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:321)
at
org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.<init>(FromCompiler.java:231)
at
org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:160)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:304)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:1)
at
org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:215)
at
org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:1)
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.executeQuery(PhoenixStatement.java:1013)
at
org.apache.phoenix.end2end.StatsCollectorIT.testPhoenixPerformanceOnHighNumberofGuidePosts(StatsCollectorIT.java:441)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1774)
at
java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:768)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:656)
at
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92)
at
org.apache.hadoop.hbase.client.HTable.coprocessorService(HTable.java:1538)
at
org.apache.hadoop.hbase.client.HTable.coprocessorService(HTable.java:1511)
at
org.apache.phoenix.query.ConnectionQueryServicesImpl.metaDataCoprocessorExec(ConnectionQueryServicesImpl.java:921)
... 41 more
> Create unit test that uses 15K guideposts
> -----------------------------------------
>
> Key: PHOENIX-1435
> URL: https://issues.apache.org/jira/browse/PHOENIX-1435
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Samarth Jain
>
> We're seeing memory issues when 14K guideposts are used to execute a query.
> Although other issues are contributing to the high number of guideposts
> (PHOENIX-1434), and we don't need to execute some LIMIT queries in parallel
> (PHOENIX-1432), we should still get to the bottom of why this is causing
> memory and/or CPU issues.
> One question with this kind of scenario - why didn't the query get rejected,
> as it seems like it would fill up the queue past the allowed 5000 threads?
> Also, do the temp files get cleaned up in this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
