@saivenkatg55  Great, can you gauge the improvement in percentage?   Can you back up your ambari.properties and make the below changes to further enhance the Ambari performance I usually script that as a post-install step. Can you then take time and Accept the solution and close the thread so other members can reference it should they encounter a simpler situation.   Purging in the Ambari database from time to time should be an Admin maintenance task    Backup the ambari server properties file # cp /etc/ambari-server/conf/ambari.properties  /etc/ambari-server/conf/ambari.properties.ORIG   Change the timeout of the ambari server # echo 'server.startup.web.timeout=120' >> /etc/ambari-server/conf/ambari.properties # echo 'server.jdbc.connection-pool.acquisition-size=5' >> /etc/ambari-server/conf/ambari.properties # echo 'server.jdbc.connection-pool.max-age=0' >> /etc/ambari-server/conf/ambari.properties # echo 'server.jdbc.connection-pool.max-idle-time=14400' >> /etc/ambari-server/conf/ambari.properties # echo 'server.jdbc.connection-pool.max-idle-time-excess=0' >> /etc/ambari-server/conf/ambari.properties # echo 'server.jdbc.connection-pool.idle-test-interval=7200' >> /etc/ambari-server/conf/ambari.properties   Hope that helps   Happy hadooping   ... View more

@Kou_Bou    I just deployed a cluster yesterday   and never encountered that error          Can you share your documented  steps in a document  if it's too big  to attach use google, I am sure  you might be skipping a step  but before that can you do the 2 steps below    vi /etc/ambari-agent/conf/ambari-agent.ini force_https_protocol=PROTOCOL_TLSv1_2 vi /etc/python/cert-verification.cfg [https] verify=disable To disable SSL/TLS then retry that should resolve your problem     ... View more

@lalprasanth  That's obvious because you have double $$  in the sqoop command you forgot to remove  the one in the command I posted please do that and revert. Thank you ... View more

@saivenkatg55  Any updates your feedback will be appreciated. ... View more

@mike_bronson7  Sorry I just saw your response while checking my backlog you didn't tag me with @  that expalins why I wasn't notified. That's weird in fact the files you backed should be copied to this faulty node, which is the source of the problems. So thing/process MUST have deleted those files   Then follow the steps I laid out . ... View more

@mike_bronson7  it was a typo error I should have proofread again "In your case, it would good to upgrade to 7.7 and to avoid getting accidental 7.7"  should read In your case, it would good to upgrade to 7.5 and to avoid getting accidental 7.7  this should match the highest version in your cluster  else when you run system update this will automatically upgrade to the latest stable version 7.7 that why you should use the internal repo or set  subscription-manager release --set=7.5 NB. Upgrading to 7.6 as you said would mean a lot of upgrade work for  both clusters  Happy hadooping   ... View more

@mike_bronson7    I would say NO from a technical perspective, too many things changed since RHEL 7.2 mixing Family OS's in the same major release RHEL 7.2 and CentOS 7.5 is possible but while less likely, even that could lead to issues as it isn't tested. You'll want to pay close attention to versions of java, yum, python, etc on each node. You might have to edit the /usr/lib/python2.6/site-packages/ambari_server/os_type_check.sh to bypass some incompatibility and you will need to take care of the Kafka conflicts too are they the same versions?? Don't be afraid the fresh installation and configuration takes less time than fixing dependency problems and other issues but the better option is a rolling upgrade to the higher version 7.5 Between RHEL 7.5 and 7.2 you skip two releases not to speak about the jump from GNOME 3.14 to GNOME 3.26, in case the version Server with GUI is in use. Even if (only) upgrading from RHEL 7.2 to RHEL 7.4 - this is something where several problems are possible I think both ways have pros and cons. Take precautions to avoid accidental updates by using an internal repo like Red Hat Satellite Server for content and configuration management hence protecting any necessary configurations, data, and attempt the yum update. You can do an echo n | yum update to see if it generates any yum errors. In your case, it would good to upgrade to 7.7 and to avoid getting accidental 7.7 What you can do is to create a local repository that contains the packages from the RHEL 7.5 release and perform an offline upgrade to that edition, but you should disable the network in this case. Otherwise (when you run an online update) yum will pull in the latest stable packages ... which actually are from the current RHEL 7.7 release. 🙂   Solution to upgrade to 7.5 Execute the following command:         subscription-manager release --set=7.5 Clean up everything :                                   sudo yum clean all | sudo rm -r /var/cache/yum Update the software sources:                sudo yum update redhat-release-server On the HDP version, 2.5.x to 3.1.x and Ambari 2.5.x to 2.7.x can run without issues on RHEL 7.2 but RHEL 7.5 can only run HDP 2.6.0 to 2.1.4 and Ambari 2.6.2 to 2.7.4 ... View more