Raising the heap should mostly help with this, as @saranvisa points out. The GC is usually driven by inadequate free heap memory, and adding more allocated heap memory helps with that. However, if the GCs are occurring without any change/increase in load, it could also be related to history retention configurations of the JobTracker. > Cm -> Yarn -> Configuration -> "Garbage Collection Duration Monitoring Period" Increase it from 5 mins to 10 mins I'd not recommend doing this, as it only hides the problem - You should be concerned if there's excessive GC due to heap pressure, and the default alert window and thresholds covers it well. Only increase it if you're absolutely sure the GC spikes are temporary and workload-driven but non-concerning, which doesn't seem determined yet. Also, if you want to check the heap usage before increasing the heap by any value, you may see it in the heap charts shown on the JobTracker instance page of CM. ... View more

You can test cross realm trust by using MIT Kerberos' 'kvno' command: Assuming realms A and B, 1. kinit as any identity from realm A 2. Run: kvno hdfs/namenode-host@B If kvno grabs a service ticket, everything is fine with the trust between B and A Repeat the test in the inverse fashion, with A's namenode-host to check the other direction. P.s. Ensure that the encryption types of all the krbtgt principals is the same on both KDCs (verify with getprinc ), and that both clusters pass the Hosts -> Security Inspector check in CM. ... View more

For your first scenario's error, you appear to be attempting to use an unsecure client config to talk to a remote secure cluster. Perhaps you're using a gateway host that does not have updated client configs? Ideally the error should mirror the second scenario error type. For your second scenario's error, the two realms do not appear to have a cross-realm trust setup. If you're using MIT Kerberos, follow this for your two realms: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/sec-kerberos-crossrealm.html ... View more

Is there any pattern to this? For ex., do the few tasks that hang all run on the same host or specific set of hosts among all nodes in the cluster? A more detailed root cause can be sought by performing a jstack on a task that appears hung live. This is done by first finding which host the hung task is running on (within the task timeout period, after noticing it hanging), discovering its container ID and finding the associated java process on the machine followed by the jstack command run on the PID. ... View more

It seems like your VM either has too little RAM or is unable to get adequate CPU cycles to run the RS continually, per the below snippet: 2017-06-06 22:21:59,870 WARN [regionserver/quickstart.cloudera/127.0.0.1:60020] util.Sleeper: We slept 81086ms instead of 3000ms, this is likely due to a long garbage collecting pause and it's usually bad, see http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired Can you try increasing the RAM available to the VM? ... View more

The command 'pyspark' is for Spark 1.6 so it certainly needs a Spark Gateway to function. If you want to use PySpark with Spark 2, the command is 'pyspark2' instead. ... View more

If you're managing your Hue service via Cloudera Manager, you can do the dump and load via the UI. Stop the Hue service with the SQLite configuration, then click 'Dump Database' under the Hue service page's Actions button. Next, reconfigure the stopped Hue service to use your new MySQL DB, and before starting it go back to the Actions button and click 'Load Database'. ... View more