In that case, my suggestion is to check for HS2 logs to try to find any queries that takes time to compile. Because HS2 currently can only compile one query at a time, if you have a query that takes a while to compile, it will lock out HS2 and other requests will have to wait. I am not sure if it is the cause, but worth to check the HS2 log. Look for the following example: Completed compiling command(queryId=hive_20170227192424_ee0c5216-bef5-456a-934e-212aabe55b75); Time taken: 0.191 seconds and check if any Time taken values are too big around the time when issue happens. ... View more

Try to go to: CM > Hive > Configuration > search for "Hive Service Environment Advanced Configuration Snippet (Safety Valve)" and put in environment settings you want to update here. Cloudera Manager will then ask you to restart Hive service. This will affect both HS2 and HMS. ... View more

I can see that from JDBC: Start Time: 2017-03-03 11:38:07.269796000 End Time: 2017-03-03 11:38:08.508511000 Operator #Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail ---------------------------------------------------------------------------------------------------------------------- 01:EXCHANGE 1 0.000ns 0.000ns 1 1 0 -1.00 B UNPARTITIONED 00:SCAN HDFS 1 17.999ms 17.999ms 1 1 1.56 MB 768.00 MB default.impala_table   and from impala-shell Start Time: 2017-03-03 11:40:15.660573000 End Time: 2017-03-03 11:40:15.806061000 Operator #Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail ---------------------------------------------------------------------------------------------------------------------- 01:EXCHANGE 1 0.000ns 0.000ns 1 1 0 -1.00 B UNPARTITIONED 00:SCAN HDFS 1 23.999ms 23.999ms 1 1 1.56 MB 768.00 MB default.impala_table   I don't see major differences here, though from JDBC in total it took just above 1 second and through impala-shell in total well below 1 second.   What was the main difference in time from JDBC connection start to finish? Queries will definitely have some overhead when running through JDBC since it is from outside of cluster. You can find more details from the TRACE log you collected. ... View more