Member since
07-14-2020
168
Posts
15
Kudos Received
3
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 526 | 02-23-2026 03:55 AM | |
| 1716 | 05-24-2024 12:56 AM | |
| 4580 | 05-16-2024 12:20 AM |
02-23-2026
03:55 AM
The lock held above has 6-8 sec lock this will not cause the slowness also above is from service rpc while block is reporting to NN, Check any lock held more than 10-15 sec, Heap utilisation and Heap required is completely different for keeping 300M block you should required 300GB although the heap utilisation is for current utilising jobs please review below doc: https://docs.cloudera.com/cdp-private-cloud-upgrade/latest/upgrade/topics/cdpdc-hdfs.html
... View more
02-23-2026
02:04 AM
Thanks @ganzuoni As per the current size of NN 160GB for 300M blocks is very less you will see these type of GC allocation failure in the cluster, please increase it to 300-320GB and DN to 40GB atleas handler count has the calculation you can review the below blog for such: https://community.cloudera.com/t5/Support-Questions/Can-we-check-how-many-namenode-handler-count-are-used-in-a/td-p/281142 Your cluster is already over-utilised with not enough resource the moment you decommission the DN ti will start a replication policy which is again a huge BW job causing much performance issue. First we need to fix the cluster with enough resources , can you give us a write lock held complete thread Also you find anything in audit logs
... View more
02-22-2026
10:09 PM
Hello @ganzuoni , Thanks for reaching us out below is your answer: As per the current config you have reached to the limition as CLDR doesnt recommend to have block more than 300M its the dead end and 10M block in each DN but you have 40 M blocks Setting dfs.blockreport.split.threshold to 0 is good plan but does this is causing the slowness please confirm that first while checking "Block report queue is full" in Namenode logs, More-over please check the NN logs for read lock held and write lock held anyone surpassing more than 10sec if yes then read the thread where its stuck, also check out: 1. Any snapshot policy is running 2. Balancer is running 3. Which user is doing which operation mostly in NN audit logs you will find 4. check out the pause if you have any in NN and DN logs, we recommend 1GB for 1M of blocks Suppose in audit logs you find XXX@user is doing 1000's of getfile rpc more than other user then try to stop that job for sometimes to confirm if other speed up.
... View more
11-19-2025
01:30 AM
While loading fsimage why the permissions=nifi:hdfs:rwx in-place of hdfs:hadoop Encountered exception on operation MkdirOp
... View more
07-30-2025
07:42 AM
bc3dcd485adfa1c339eab38f1516c6c5 >> These alpha numeric related to tablet from kudu, region from habse or container for ozone, did you get a chance to check recon ui
... View more
07-07-2025
01:57 AM
COuld you please confirm what is below in tmp dir looks like container to me, you can confirm the same form recon ui and find out the path it belongs to 405 GB /tmp/24c9e15e52afc47c225b757e7bee1f9d/ 134 GB /tmp/5af6b2617513b81608501adea4166625/ 21 GB /tmp/bc3dcd485adfa1c339eab38f1516c6c5/
... View more
06-30-2025
03:05 AM
ozone admin namespace du ofs://<ozone nameservice> please use this command
... View more
06-30-2025
03:03 AM
Hi @satvaddi Thanks for connecting with cloudera, could you please let me know the current CDP version and whats the size of disk you provide for ozone, open your Recon webui and check if container has been created and it's the one storing the disk size i suspect this should be the case
... View more
11-15-2024
02:26 AM
1 Kudo
HI Team, if you are storing the back in HDFS like above -rootPath file:/// [***DIRECTORY TO USE FOR BACKUP***] then use the below command: hdfs dfs -du -s -h file:/// [***DIRECTORY TO USE FOR BACKUP***] if its different storage like ozone(ofs/o3) then also hdfs command will work if its S3 then use the aws command
... View more
11-15-2024
02:20 AM
1 Kudo
Hi Team, It does looks like too much data is writting to TS which causing it to reach 100%, did you check from TOP command how much kudu process is taking To fix it: 1. Please us the API in batch mode dont run all the jobs at one go as kudu works better in batch process 2. if possible reduce the load via increasing TS and data disk 3. Also check if any TP is running like antivirus which is not recommend and can cause a huge spike in CPU
... View more