Community Articles
Find and share helpful community-sourced technical articles.
Check out our newest addition to the community, the Cloudera Innovation Accelerator group hub.
Labels (1)

We have seen performance issue and stability issue in heavy workload system, this is due to disk latency/Shared Disk. I.e frequent namenode failover, longer boot time, slower checkpoint, slower logging, Higher fsync will cause session expiry, etc.

We never recommend a shared disk for Namenode, Journal node and Zookeeper. All of these services should have a dedicated disk.

You can configure following disk type according to your HDFS workload.
 Namenode fsimage directory, dedicated disk => HDD 15K RPM 
 Namenode edit log directory, dedicated disk => SSD 
[dataDir from zoo.cfg]
 Zoookeeper snapshot and transaction logs, for normal usage from ZKFC and HBase => HDD 15K RPM 
 Zoookeeper snapshot and transaction logs, If it used by Nifi/ Accumulo/ Kafka/ Storm/ HBase and ZKFC => SSD 

If you are using RAID for meta-directory( & dfs.journalnode.edits.dir), then disable RAID and check the Non-RAID performance. There is a strong redundant for meta-directory (fsimage & edits are available from Standby NameNode and remaining QJNs).

If RAID is not disabled for JN, then consider using different RAID. RAID 1 and RAID 10 are also good for the dfs.journalnode.edits.dir set rather than RAID 5, due to increased in write latency for small block writes.

if you don't have a faster disk, then don't consider using fsimage replication. It will impact write performance even if one of the disks slower.

Don't have an account?
Version history
Last update:
‎10-04-2018 11:25 AM
Updated by:
Top Kudoed Authors