HBase写入操作卡住长时间不返回的原因分析

本文出处:http://blog.csdn.net/chaijunkun/article/details/44238163,转载请注明。由于本人不定期会整理相关博文,会对相应内容作出完善。因此强烈建议在原始出处查看此文。


这些天研究HBase,写了一段Demo代码,具体如下:

@Test
public void doTest() throws MasterNotRunningException, ZooKeeperConnectionException, IOException {
	Configuration config = HBaseConfiguration.create();
	config.set(zkSetKey, zkConn);
	HBaseAdmin hBaseAdmin = null;
	try{
		hBaseAdmin = new HBaseAdmin(config);
		ClusterStatus clusterStatus = hBaseAdmin.getClusterStatus();
		ServerName master = clusterStatus.getMaster();
		log.info("Master主机:{},端口号:{}", master.getHostname(), master.getPort());
		Collection<ServerName> servers = clusterStatus.getServers();
		for (ServerName serverName : servers) {
			log.info("Region主机{},端口号:{}", serverName.getHostname(), serverName.getPort());
		}
		HTableDescriptor targetTableDesc = null;
		try{
			targetTableDesc = hBaseAdmin.getTableDescriptor(TableName.valueOf(tableName));
			log.info("表已经存在,显示信息");
			log.info("属性:{}", targetTableDesc.toString());
		}catch(TableNotFoundException notFound){
			log.info("表不存在,创建");
			HTableDescriptor htd = new HTableDescriptor(TableName.valueOf(tableName));
			HColumnDescriptor hcd_info = new HColumnDescriptor("info");
			hcd_info.setMaxVersions(3);
			HColumnDescriptor hcd_data = new HColumnDescriptor("data");
			htd.addFamily(hcd_info);
			htd.addFamily(hcd_data);
			hBaseAdmin.createTable(htd);
			log.info("创建成功");
			targetTableDesc = hBaseAdmin.getTableDescriptor(TableName.valueOf(tableName));
			log.info("属性:{}", targetTableDesc.toString());
		}
		TableName[] listTableNames = hBaseAdmin.listTableNames();
		if (listTableNames == null){
			log.info("无表");
		}else{
			for (TableName tableName : listTableNames) {
				log.info("表名:{}", tableName.getNameAsString());
			}
		}
	}finally{
		IOUtils.closeQuietly(hBaseAdmin);
		log.info("结束");
	}
}
运行这段代码 程序会卡在第28行不动,也就是创建表操作,并且没有报出任何异常,其它的读取操作却很快(例如获取集群状态、列出所有表等操作)。于是本人陷入了深深地思考……

在CSDN找到了一种类似的情况:http://blog.csdn.net/lxpbs8851/article/details/8287471

主要是说HBase所依赖的HDFS进入了安全模式,需要手动退出该模式(运行命令:hdfs dfsadmin -safemode leave)。可是我查询当前的HDFS安全模式状态(hdfs dfsadmin -safemode get)时得到的信息是:Safe mode is OFF,也就是说根本没在安全模式下。


后来偶然地过了一段时间再去看日志发现如下信息:

#1, waiting for some tasks to finish. Expected max=0, tasksSent=9, tasksDone=8, currentTasksDone=8, retries=8 hasError=false, tableName=demo_table
#1, waiting for some tasks to finish. Expected max=0, tasksSent=10, tasksDone=9, currentTasksDone=9, retries=9 hasError=false, tableName=demo_table
#1, table=demo_table, attempt=10/35 failed 1 ops, last exception: java.net.UnknownHostException: unknown host: admin.demo.com on admin.demo.cn,5020,1426211698289, tracking started Fri Mar 13 11:41:19 CST 2015, retrying after 10037 ms, replay 1 ops.


最后一行的主机名:admin.demo.com和admin.demo.cn引起了我的注意。因为我的测试环境为3台实体服务器,配置如下:

IP地址hosts文件配置的主机名linux系统的hostnameHBase角色HDFS角色
192.168.1.21hd-21test-21MasterServerNameNode、DataNode、ZooKeeper
192.168.1.22hd-22test-22RegionServerNameNode、DataNode、ZooKeeper
192.168.1.23hd-23test-23RegionServerDataNode、ZooKeeper
另外,因为是测试环境,在192.168.1.22这台机器上还添加了如下hosts信息:

192.168.1.22 admin.demo.com
192.168.1.22 admin.demo.cn
简单来说就是hosts文件中配置的主机名和真实主机名不一致,并且还加入了额外的hosts配置信息干扰到了正确解析主机名。

运行demo程序的工作机没有配置任何额外的hosts,连接ZooKeeper时直接使用的IP地址,但是HBase Client 底层在进行操作时可能引入了主机名反向连接,作为完全干净的工作机当然找不到对应的服务器,就不断地在后台重试导致生成了上述的日志。当我把出现问题的两个hosts记录加入到工作机后,问题解决


经验:通过上述错误可知,Hadoop集群中hostname一定要与hosts文件中配置的名称一致,并且力求保证集群映射关系的纯净,不要把其他不相干的业务也部署在其中,引起不必要的麻烦。

<think>好的,用户现在问的是“Atlas第一次启动好慢”,需要我详细分析原因并提供解决方案。首先,我得回顾之前的对话历史,用户之前遇到了solr.xml缺失的问题,现在可能已经解决了那个问题,但第一次启动时又遇到了速度慢的情况。 首先,我应该考虑第一次启动慢的常见原因。Apache Atlas在初次启动时需要进行很多初始化工作,比如创建Solr的索引、初始化图数据库(比如JanusGraph)、加载元数据类型和预定义的实体。这些都是耗时的步骤,尤其是如果用户使用的是嵌入式组件而是独立服务的话。 接下来,用户可能的场景是什么?他们可能是在本地环境或者测试环境中部署Atlas,初次启动等待时间过长,影响开发或测试效率。用户可能对Atlas的内部机制太了解,所以需要解释清楚为什么第一次启动会慢,并给出优化建议。 需要区分用户的实际情况,比如他们是否使用了外部Solr或HBase,还是默认的嵌入式服务。如果用户按照之前的解决方案手动配置了Solr,可能已经改为外部服务,但启动依然慢,那可能需要检查配置是否正确,或者是否有其他瓶颈。 然后,我需要列举可能导致启动慢的具体原因,比如资源足(内存、CPU)、依赖服务未优化(如HBase或Solr响应慢)、网络问题、日志级别过高等。同时,应该提供对应的解决方案,如调整JVM参数、优化依赖服务配置、使用外部服务替代嵌入式组件、预加载元数据等。 另外,用户可能知道如何监控启动过程中的瓶颈,可能需要指导他们查看日志,分析哪个阶段耗时最长。例如,检查Atlas的启动日志,看是否有长时间的GC停顿,或者某个初始化步骤卡住。 还需要考虑是否有一些快速启动的技巧,比如在测试环境中禁用某些特性,或者预先执行初始化脚本。此外,文档或社区的最佳实践可能会有帮助,比如推荐的生产环境配置。 最后,要确保回答结构清晰,分点列出原因和解决方案,便于用户逐步排查。同时提醒用户后续启动会比第一次快,减少他们的担忧。如果有必要,可以建议他们查阅官方文档或寻求社区支持,如果问题依然存在的话。</think>Apache Atlas 第一次启动较慢是正常现象,主要原因在于初始化元数据存储、创建核心索引以及加载内置模型。以下是详细分析和优化建议: --- ### **一、启动慢的核心原因** | 阶段 | 耗时原因 | 典型耗时范围 | |---------------------|------------------------------------------------------------------------------------------|----------------| | **HBase表创建** | 首次启动时会自动创建约20张HBase表(如`atlas_titan`、`atlas_audit`) | 2-5分钟 | | **Solr索引初始化** | 为元数据构建全文检索索引(如`fulltext_index`、`edge_index`),涉及大量数据写入和分片配置 | 3-8分钟 | | **内置模型加载** | 加载预定义的元数据模型(`hive`、`hdfs`、`kafka`等)及其血缘关系定义 | 1-3分钟 | | **JVM预热** | 首次启动时JVM需要加载类库、优化字节码(Just-In-Time编译) | 1-2分钟 | --- ### **二、加速方案** #### 1. **硬件资源优化** - **内存调整**:修改`atlas-env.sh`中的JVM堆大小(建议 >= 4GB) ```bash export ATLAS_SERVER_HEAP="-Xms4096m -Xmx4096m -XX:MaxDirectMemorySize=1024m" ``` - **SSD存储**:将HBase和Solr的数据目录挂载到SSD磁盘(如修改`hbase-site.xml`中的`hbase.rootdir`) #### 2. **依赖服务调优** - **HBase预分区**:手动预创建Atlas需要的表(需先创建命名空间`atlas`) ```bash echo "create_namespace 'atlas'" | hbase shell hbase org.apache.hadoop.hbase.util.RegionSplitter atlas_titan HexStringSplit -c 10 -f cf ``` - **Solr配置优化**:调整`solrconfig.xml`中的索引合并策略 ```xml <mergePolicy class="org.apache.solr.index.TieredMergePolicy"> <int name="maxMergeAtOnce">5</int> <int name="segmentsPerTier">10</int> </mergePolicy> ``` #### 3. **启动参数调整** 禁用非必要模块(测试环境适用): ```properties # 修改 conf/atlas-application.properties atlas.notification.embedded=false # 禁用嵌入式Kafka atlas.graph.index.search.backend=noop # 禁用索引(仅限调试) ``` #### 4. **预加载策略** 提前执行初始化(需先启动HBase/Solr): ```bash # 手动触发初始化 $ATLAS_HOME/bin/atlas_start.py -setup ``` --- ### **三、关键日志观察** 通过日志定位瓶颈阶段: ```bash tail -f $ATLAS_HOME/logs/application.log ``` - **HBase初始化完成**: ```log Successfully created HBase table atlas_titan ``` - **Solr索引就绪**: ```log Updated Solr alias atlas_fulltext_index to version 1 ``` - **服务启动完成标志**: ```log Atlas server started at http://0.0.0.0:21000 ``` --- ### **四、生产环境建议** 1. **分离关键服务**: - 使用独立Solr集群(非嵌入式) - 部署HBase到专用集群 2. **缓存预热**: ```java // 调用预加载API(需先认证) curl -u admin:admin http://localhost:21000/api/atlas/v2/types/typedefs ``` 3. **容器化部署**: ```dockerfile FROM apache/atlas:2.4.0 # 预置优化配置到镜像 COPY custom-atlas.properties /opt/atlas/conf/atlas-application.properties ``` --- ### **五、后续启动优化** - 第二次启动时间通常减少**50-70%**(无需重复初始化) - 启用HBase块缓存(提升读取速度): ```xml <!-- hbase-site.xml --> <property> <name>hfile.block.cache.size</name> <value>0.4</value> <!-- 40%堆内存 --> </property> ``` 建议结合`jstack`和`VisualVM`监控JVM状态,确认是否存在GC瓶颈。若问题持续,可检查网络延迟或存储IO性能。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值