首页 文章 精选 留言 我的

精选列表

搜索[失败归因],共10006篇文章
优秀的个人博客,低调大师

MaxCompute 费用暴涨之新增SQL分区裁剪失败

现象:因业务需求新增了SQL任务,这SQL扫描的表为分区表,且SQL条件里表只指定了一个分区,按指定的分区来看数据量并不大,但是SQL的费用非常高。费用比预想的结果相差几倍甚至10倍以上。 若只知道总体费用暴涨,但是没明确是什么任务暴涨,可以可以参考查看账单详情-使用记录文档,找出费用异常的记录。 分析:我们先明确MaxCompute SQL后付费的计费公式:一条SQL执行的费用=扫描输入量 ️ SQL复杂度 ️ 0.3(¥/GB)。 变量主要是输入量和复杂度,但实际上复杂度最高也就为4,由复杂度引起的费用暴涨是比较罕见,我们不妨先把排查重点放在输入量上。 排查:查看Logview的inputs信息 如上图会发现input的分区量是14个,这个与预想的(SQL条件中只指定一个分区)不一致。问题就出在这里,此时基本可以判断这个SQL的分区

优秀的个人博客,低调大师

挂载失败-日志中显示僵尸pod的问题

当节点出现pod挂载不上,且查看节点日志(/var/log/message)发现不断有“Orphaned pod”字段的日志打印出来,如下: Jan 21 03:07:08 abc_k8s_worker01 kubelet: E0121 03:07:08.894211 6507 kubelet_volumes.go:140] Orphaned pod "0401c09a-1b0c-11e9-94f8-00163e14dc48" found, but volume paths are still present on disk : There were a total of 4 errors similar to this. Turn up verbosity to see them. 说明当前有pod(0401c09a-1b0c

优秀的个人博客,低调大师

Android 分享微信小程序失败二三事

小菜这两天接入分享微信小程序的入口,本来很简单的几行代码,可最后搞得我头昏脑胀。微信小程序官网上的接入方式已经说的非常清楚,可在小菜自己实践的过程中,却始终不成功。其实真的很简单,而卡住了还真的是很头疼,因此特意记录一下。 集成方式 build.gradle 中添加 compile 'com.tencent.mm.opensdk:wechat-sdk-android-with-mta:+'; 在需要调用分享功能的入口添加如下代码,如果配置参数都正常的话基本就可以正常分享了: public void shareToMiniWX() { WXMiniProgramObject miniProgramObj = new WXMiniProgramObject(); miniProgramObj.webpageUrl = "http://www.qq.com"; // 兼容低版本的网页链接 miniProgramObj.miniprogramType = WXMiniProgramObject.MINIPTOGRAM_TYPE_RELEASE;// 正式版:0,测试版:1,体验版:2 miniProgramObj.userName = Constants.miniProgramId; // 小程序原始id miniProgramObj.path = "pages/home/home"; //小程序页面路径 WXMediaMessage msg = new WXMediaMessage(miniProgramObj); msg.title = "小程序消息Title"; // 小程序消息title msg.description = "小程序消息Desc"; // 小程序消息desc Bitmap bmp = BitmapFactory.decodeResource(mContext.getResources(), R.drawable.share_friend_circle_icon_new); Bitmap thumbBmp = Bitmap.createScaledBitmap(bmp, 90, 90, true); bmp.recycle(); msg.thumbData = BitmapUtil.bmpToByteArray(thumbBmp, true); SendMessageToWX.Req req = new SendMessageToWX.Req(); req.transaction = "" + System.currentTimeMillis(); req.message = msg; req.scene = SendMessageToWX.Req.WXSceneSession; // 目前支持会话 WXAPIFactory.createWXAPI(mContext, AppID).sendReq(req); } 问题说明 问题一:无法分享到微信【由于不支持的分享类型,无法分享到微信】 出现这种情况的问题基本上都是分享的ID有问题,一定一定不要认定自己写的绝对正确,多多核对几次,当时小菜就吃了这个亏。原始ID 和 AppID 一定要写对: 原始ID 是类似于 gh_... 的15位字符串; AppID 是类似于 wx... 的18位字符串。 问题二:无法分享到微信【未在同一应用下】 出现这种情况时一般是 原始ID 与 AppID 不匹配,小菜在测试的时候刚开始用的微信官方提供的 Demo 测试的,AppID 没有更改,便会出现这个问题。 问题三:分享进入小程序,该页面不存在? 分享小程序正常,但是点进去出现错误,是 miniProgramObj.path = "pages/home/home"; 路径错误,尤其是在路径传参时特别注意。 小提示 miniProgramObj.miniprogramType = WXMiniProgramObject.MINIPTOGRAM_TYPE_RELEASE; 建议用正式版进行测试; 目前微信分享小程序只支持 WXSceneSession 聊天页面分享; 分享小程序展示的图为 Bitmap 格式,url 图片建议在一个新线程中转为 Bitmap 在进行传参。 整个接入过程真的很简单,最主要就是两个ID正确,而且千万不要自以为是对的!希望各位不会出现小菜遇到的这些坑。

优秀的个人博客,低调大师

hive_学习_02_hive整合hbase(失败

一、前言 本文承接上一篇:hive_学习_01_hive环境搭建(单机),主要是记录 hive 整合hbase的流程 二、环境准备 1.环境准备 操作系统 : linux CentOS 6.8 jdk :1.7 cdh版本为: 5.9.3 mysql : 5.1.73 hadoop-2.6.0-cdh5.9.3 hbase-1.2.0-cdh5.9.3 hive-1.1.0-cdh5.9.3 2.安装mysql 3.安装hadoop 参考:hadoop_学习_02_Hadoop环境搭建(单机) 4.安装 hbase 参考:hbase_学习_01_HBase环境搭建(单机) 5.安装hive 参考:hive_学习_01_hive环境搭建(单机) 三、服务器基本配置 1.配置主机名 (1)修改 hostname sudo vim /etc/sysconfig/network 将HOSTNAME修改为 rayner (改成你自己的,所有的地方一致即可) (2)映射主机 ip 与主机名 sudo vim /etc/hosts 加入以下配置: 192.168.1.102 rayner 2.关闭防火墙 关闭防火墙,这样就可以在本机 window 中访问虚拟机的所有端口了 CentOS 7版本以下输入: service iptables stop CentOS 7 以上的版本输入: systemctl stop firewalld.service 3.时间设置 输入: date 查看服务器时间是否一致,若不一致则更改 更改时间命令 date -s ‘MMDDhhmmYYYY.ss’ 四、知识准备 1.Hive和HBase的通信意图 Hive与HBase整合的实现是利用两者本身对外的API接口互相通信来完成的,其具体工作交由Hive的lib目录中的hive-hbase-handler-*.jar工具类来实现,通信原理如下图所示。 2.Hive整合HBase后的使用场景: (一)通过Hive把数据加载到HBase中,数据源可以是文件也可以是Hive中的表。(二)通过整合,让HBase支持JOIN、GROUP等SQL查询语法。(三)通过整合,不仅可完成HBase的数据实时查询,也可以使用Hive查询HBase中的数据完成复杂的数据分析。 五、hive整合hbase 因为Hive与HBase整合的实现是利用两者本身对外的API接口互相通信来完成的,其具体工作交由Hive的lib目录中的hive-hbase-handler-.jar工具类来实现。 所以只需要将hive的 hive-hbase-handler-.jar 复制到hbase/lib中就可以了。 六、hive 和 hbase 测试 在进行测试的时候,确保hadoop、hbase、hive环境已经成功搭建好,并且都成功启动了。 七、参考资料 1.大数据学习系列之五 ----- Hive整合HBase图文详解 2.Hive HBase Integration

优秀的个人博客,低调大师

对一个“失败”项目的审视—分析

洋洋洒洒写了好多字啊,我都没想到我能写这么多字来。看了上面的架构一定有人会想“不对吧,你在第一篇中可是写的是11种服务器啊,你数一数上面的架构图上才几个?老兄啊,你别是为了点击率而忽悠我们吧”。对于存有这种看法的看客,我只能说“您看的可真细致啊!”上面的这个架构图的确和我第一篇中写的11种服务器的架构不同,那是因为上面的图是目前的架构图,而11种服务器则是第一版的产品架构。大家可以来看看第一版和目前版本架构图的区别。 后来将网关服务器和逻辑处理服务器合并;帐号服务器和认证服务器合并;统计服务器、公告服务器、在线服务器砍掉;计费服务器拆分成上报服务器和同步服务器。所以大家就看到了上一篇中的架构图。 看到上面的架构图以后不知道大家会有何感想,反正我听到领导好几次用Perfect来形容。当时自己也沾沾自喜了好久。 不过随着项目的完成,以及性能测试和压力测试的开展,却发现了一个非常大的问题—性能低下。更有甚者当网吧的一个结账业务发送到上报服务器以后,上报服务器竟然需要2-3秒钟才能处理完毕。这几乎是灾难性的,要知道每个网吧我们的评估是每天上报2000条数据,这样一来,一组服务器所能支持的网吧数量则少的可怜。同时处理速度过慢,会在业务上出现很大的漏洞。例如以连锁网吧为例,用户1在连锁网吧中的A进行消费100块钱以后,抢在连锁网吧数据同步之前(由于处理速度太慢,而造成了延迟)又在连锁网吧B中进行消费,这样以来相当于用户1进行了重复性消费。容易造成网吧账目出现大量的负帐(用户1消费完后,不再进行消费),这对目前薄利的网吧行业的打击无疑是巨大的。 究其原因,我觉得主要是因为我们在处理所有业务的时候都是采取了先从SQL SERVER数据库中查询数据,然后再进行计算,并将SQL SERVER数据库中的相关数据进行修改的方式。要知道对于一个复杂的业务,这种查询是多次的。修改的内容也会涉及到好几张不同的表。 就拿网吧用户表为例,一张表中会存放将近3000万条的数据,即便是通过分库分表的方式,虽然可以缓解,但也只能指标不能治本。 第二个问题是由于网吧数据是放在网吧服务器上,网吧每次交班时的交班金额是按照网吧本地数据计算出来的。而网吧的每一条业务都上报给中心服务器,中心服务器会重新对数据计算一次;并且当网吧服务器重启的时候,对于网吧服务器和中心服务器上不一致的数据进行强制更新。这个流程中出现了两次计算,并且在不同的业务中以不同的计算结果作为依据(网吧中的交班和中心服务器中的强制数据更新)。这样一来势必会出现数据不正确的问题(事实上,在产品刚上线不久的时候,我们的DBA都是在进行数据的修正,即将中心服务器的数据修改成网吧的数据)。 以上两个问题一直困扰着我很久,因为如果产品做成这样的话,在市场上就几乎无法进行推广的。直到后来我离开这家公司以后,才想到了使用NOSQL来实现。 本文转自狗窝博客51CTO博客,原文链接http://blog.51cto.com/fxh7622/1544726如需转载请自行联系原作者 fxh7622

优秀的个人博客,低调大师

对一个“失败”项目的审视—架构

衡量一个产品的成败,往往所站的角度不同理解也就不同。站在一个开发人员的角度来看,判断一个产品是否成功,往往首先判断这款产品是否满足用户的需求。对于有性能扩展要求的产品,则还要考虑其是否具有较高的性能、是否便于后期扩展;对于具有代码洁癖的开发者来说,则还要看代码编写是否规范等等。 今天我们先来了解一下这款产品的架构是如何设计的,再说说它的各服务器的功能。 首先我简单说明一下架构中需要重点考虑的几点: 1:网吧断网时的处理:架构设计中要考虑到网吧和中心服务器断网的情况,所以简单的按照MMO游戏的设计方式是不可行的(这种情况虽不常见,但是经常会由于网络不稳定而出现,有时也会因为一些其它原因而导致,例如某地区曾出现一整年断网情况),所以架构设计时需要处理:当网吧服务器和中心服务器断开后,网吧要能进行正常的业务处理;同时,当网吧服务器和中心服务器重新建立连接以后,需要将网吧在断线时间段内所处理的所有数据重新的发送到中心服务器上,并进行继续处理。 2:网吧业务连续性:对于网吧业务来说会存在一定的业务连续性,例如网吧的业务一定是先上机,后下机。这种业务如果处理顺序错乱,后果不堪设想。 3:网吧数据不准确:由于可能出现网吧网管勾结外部人员修改网吧营业数据的情况,因此网吧本地的数据不存在可信性(这里的数据指的是诸如营业流水等数据),需要中心服务器记录网吧所有的营业情况,并以重新计算得到的数据为准。 4:网吧数据产生的时段性:去过网吧的人都知道,网吧在一天之中业务数据产生的时间并非都是均匀的,例如在晚上10点以后到第二天7点左右(各网吧情况不同而定)一般是很少产生业务数据的,因为这段时间属于通宵包机时间;而在早晨8-9点属于网吧清场开业时间,这段时间会有数据大量产生。同时在周末的时候网吧也会出现业务数据产生的高峰期。基于以上的情况,架构的设计要能处理网吧业务数据瞬间变高的情况。 以上4点是系统设计时所要重点考虑的,尤其是第一点(是不是觉得考虑得很周到?但我要剧透的是,这种面面俱到的考虑其实是华丽丽的自虐。这个问题我以后会详说)。 我设计的架构图是这样的: 在这个架构中每个核心服务器的功能概要说明: 1:网关服务器: (1):用来接收大量的并发网吧服务端连接请求。 (2):接收网吧服务端的业务请求后,根据请求类型进行分析,并将请求发送给相应的后端业务处理服务器。 (3):接收后端业务处理服务器返回的业务处理数据,并将此数据转发给相应的网吧服务端。 2:帐号服务器: (1):对网吧的帐号信息进行合法性验证。 3:上报服务器: (1):接收网吧业务中需要上报的业务(例如:用户上机、下机、加钱、积分转换等等)进行业务逻辑处理。 (2):由于网吧业务存在前后逻辑关系,因此在处理的时候需要对网吧上传的业务进行顺序性处理。 4:同步服务器: (1):检测网吧服务端相关数据是否和中心数据库中的一致(费率数据、会员数据、营业流水等等),对于不一致的数据,采用同步方式强行让网吧数据和中心数据库数据一致。 外围服务器功能概要说明: 1:负载均衡服务器: (1):针对网吧帐号、所在区域等等信息对网吧应该连接的反向代理服务器的IP和端口进行指定。 (2):为了防止恶意连接反向代理服务器,负载均衡服务器为每一个网吧生成具有一定时效性的session。 (3):接收反向代理服务器的消息,对网吧帐号和session进行认证。 2:日志服务器: (1):记录所有服务器的日志信息。 (2):对所有日志进行相关分析,提取出Error级别的日志,并将此类日志保存在数据库中。 3:监控服务器: (1):监控所有服务器的运行情况,对于出现异常而宕掉的服务器程序进行自动运行,并向相关负责人发送短信报警。 (2):定时从Error日志数据库中提取相关日志,并将信息进行汇总后以短信(邮件)的方式发送给相关责任人。 本文转自狗窝博客51CTO博客,原文链接http://blog.51cto.com/fxh7622/1535702如需转载请自行联系原作者 fxh7622

优秀的个人博客,低调大师

大量删除contact导致Office365同步失败

新年一大早豆子就接到同事的问题,早上很多新建的用户无法同步到Office365上。 Office365同步不了是个常见问题,豆子检查了AD的设置,ProxyAddresses 属性的设置,Office365的状态,IDFix工具扫描了同步属性状态,貌似都很正常?这就奇怪了。 最后在 miisclient 工具里面看见以下报错状态 结果研究,发现Office365有个默认限制条件超过500个对象如果需要删除,必须手动disable掉这个限制。这是为了避免无意中在AD上删掉了整个OU导致同步删除。 https://jaapwesselius.com/2016/06/17/deletion-threshold-in-office-365-or-azure-ad-connect/ 关掉很容易 Disable-ADSyncExportDeletionThreshold 然后重新执行一次delta同步 Start-ADSyncSyncCycle-PolicyTypeDelta 可以看见有1054个删除的操作,怪不得被自动禁止了 确认成功同步以后再重新打开关掉的限制。 Enable-ADSyncExportDeletionThreshold-DeletionTreshold500

优秀的个人博客,低调大师

HDFS读取文件失败Incorrect value for packet payload size

一、现象 Hadoop-2.7.2中,使用hadoop shell命令行读取文件内容时,针对大文件,会有如下报错,小文件则不会。 hadoop fs -cat /tmp/hue_database_dump4.json 16/09/29 15:13:37 WARN hdfs.DFSClient: Exception while reading from BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 of /tmp/hue_database_dump4.json from DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK] java.io.IOException: Incorrect value for packet payload size: 57616164 at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doRead(PacketReceiver.java:159) at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.receiveNextPacket(PacketReceiver.java:102) at org.apache.hadoop.hdfs.RemoteBlockReader2.readNextPacket(RemoteBlockReader2.java:201) at org.apache.hadoop.hdfs.RemoteBlockReader2.read(RemoteBlockReader2.java:152) at org.apache.hadoop.hdfs.DFSInputStream$ByteArrayStrategy.doRead(DFSInputStream.java:775) at org.apache.hadoop.hdfs.DFSInputStream.readBuffer(DFSInputStream.java:831) at org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:891) at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934) at java.io.DataInputStream.read(DataInputStream.java:100) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:85) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:59) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:119) at org.apache.hadoop.fs.shell.Display$Cat.printToStdout(Display.java:107) at org.apache.hadoop.fs.shell.Display$Cat.processPath(Display.java:102) at org.apache.hadoop.fs.shell.Command.processPaths(Command.java:317) at org.apache.hadoop.fs.shell.Command.processPathArgument(Command.java:289) at org.apache.hadoop.fs.shell.Command.processArgument(Command.java:271) at org.apache.hadoop.fs.shell.Command.processArguments(Command.java:255) at org.apache.hadoop.fs.shell.Command.processRawArguments(Command.java:201) at org.apache.hadoop.fs.shell.Command.run(Command.java:165) at org.apache.hadoop.fs.FsShell.run(FsShell.java:287) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84) at org.apache.hadoop.fs.FsShell.main(FsShell.java:340) 16/09/29 15:13:37 WARN hdfs.DFSClient: Exception while reading from BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 of /tmp/hue_database_dump4.json from DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] java.io.IOException: Incorrect value for packet payload size: 57616164 at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doRead(PacketReceiver.java:159) at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.receiveNextPacket(PacketReceiver.java:102) at org.apache.hadoop.hdfs.RemoteBlockReader2.readNextPacket(RemoteBlockReader2.java:201) at org.apache.hadoop.hdfs.RemoteBlockReader2.read(RemoteBlockReader2.java:152) at org.apache.hadoop.hdfs.DFSInputStream$ByteArrayStrategy.doRead(DFSInputStream.java:775) at org.apache.hadoop.hdfs.DFSInputStream.readBuffer(DFSInputStream.java:831) at org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:891) at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934) at java.io.DataInputStream.read(DataInputStream.java:100) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:85) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:59) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:119) at org.apache.hadoop.fs.shell.Display$Cat.printToStdout(Display.java:107) at org.apache.hadoop.fs.shell.Display$Cat.processPath(Display.java:102) at org.apache.hadoop.fs.shell.Command.processPaths(Command.java:317) at org.apache.hadoop.fs.shell.Command.processPathArgument(Command.java:289) at org.apache.hadoop.fs.shell.Command.processArgument(Command.java:271) at org.apache.hadoop.fs.shell.Command.processArguments(Command.java:255) at org.apache.hadoop.fs.shell.Command.processRawArguments(Command.java:201) at org.apache.hadoop.fs.shell.Command.run(Command.java:165) at org.apache.hadoop.fs.FsShell.run(FsShell.java:287) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84) at org.apache.hadoop.fs.FsShell.main(FsShell.java:340) 16/09/29 15:13:37 INFO hdfs.DFSClient: Could not obtain BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 from any node: java.io.IOException: No live nodes contain block BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 after checking nodes = [DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK], DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK]], ignoredNodes = null No live nodes contain current block Block locations: DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK] DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] Dead nodes: DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK]. Will get new block locations from namenode and retry... 16/09/29 15:13:37 WARN hdfs.DFSClient: DFS chooseDataNode: got # 1 IOException, will wait for 1086.6056359410977 msec. 16/09/29 15:13:38 WARN hdfs.DFSClient: Exception while reading from BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 of /tmp/hue_database_dump4.json from DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK] java.io.IOException: Incorrect value for packet payload size: 57616164 at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doRead(PacketReceiver.java:159) at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.receiveNextPacket(PacketReceiver.java:102) at org.apache.hadoop.hdfs.RemoteBlockReader2.readNextPacket(RemoteBlockReader2.java:201) at org.apache.hadoop.hdfs.RemoteBlockReader2.read(RemoteBlockReader2.java:152) at org.apache.hadoop.hdfs.DFSInputStream$ByteArrayStrategy.doRead(DFSInputStream.java:775) at org.apache.hadoop.hdfs.DFSInputStream.readBuffer(DFSInputStream.java:831) at org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:891) at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934) at java.io.DataInputStream.read(DataInputStream.java:100) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:85) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:59) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:119) at org.apache.hadoop.fs.shell.Display$Cat.printToStdout(Display.java:107) at org.apache.hadoop.fs.shell.Display$Cat.processPath(Display.java:102) at org.apache.hadoop.fs.shell.Command.processPaths(Command.java:317) at org.apache.hadoop.fs.shell.Command.processPathArgument(Command.java:289) at org.apache.hadoop.fs.shell.Command.processArgument(Command.java:271) at org.apache.hadoop.fs.shell.Command.processArguments(Command.java:255) at org.apache.hadoop.fs.shell.Command.processRawArguments(Command.java:201) at org.apache.hadoop.fs.shell.Command.run(Command.java:165) at org.apache.hadoop.fs.FsShell.run(FsShell.java:287) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84) at org.apache.hadoop.fs.FsShell.main(FsShell.java:340) 16/09/29 15:13:38 WARN hdfs.DFSClient: Exception while reading from BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 of /tmp/hue_database_dump4.json from DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] java.io.IOException: Incorrect value for packet payload size: 57616164 at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doRead(PacketReceiver.java:159) at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.receiveNextPacket(PacketReceiver.java:102) at org.apache.hadoop.hdfs.RemoteBlockReader2.readNextPacket(RemoteBlockReader2.java:201) at org.apache.hadoop.hdfs.RemoteBlockReader2.read(RemoteBlockReader2.java:152) at org.apache.hadoop.hdfs.DFSInputStream$ByteArrayStrategy.doRead(DFSInputStream.java:775) at org.apache.hadoop.hdfs.DFSInputStream.readBuffer(DFSInputStream.java:831) at org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:891) at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934) at java.io.DataInputStream.read(DataInputStream.java:100) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:85) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:59) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:119) at org.apache.hadoop.fs.shell.Display$Cat.printToStdout(Display.java:107) at org.apache.hadoop.fs.shell.Display$Cat.processPath(Display.java:102) at org.apache.hadoop.fs.shell.Command.processPaths(Command.java:317) at org.apache.hadoop.fs.shell.Command.processPathArgument(Command.java:289) at org.apache.hadoop.fs.shell.Command.processArgument(Command.java:271) at org.apache.hadoop.fs.shell.Command.processArguments(Command.java:255) at org.apache.hadoop.fs.shell.Command.processRawArguments(Command.java:201) at org.apache.hadoop.fs.shell.Command.run(Command.java:165) at org.apache.hadoop.fs.FsShell.run(FsShell.java:287) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84) at org.apache.hadoop.fs.FsShell.main(FsShell.java:340) 16/09/29 15:13:38 INFO hdfs.DFSClient: Could not obtain BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 from any node: java.io.IOException: No live nodes contain block BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 after checking nodes = [DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK], DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK]], ignoredNodes = null No live nodes contain current block Block locations: DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK] DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] Dead nodes: DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK]. Will get new block locations from namenode and retry... 16/09/29 15:13:38 WARN hdfs.DFSClient: DFS chooseDataNode: got # 2 IOException, will wait for 6199.040804985275 msec. 16/09/29 15:13:45 WARN hdfs.DFSClient: Exception while reading from BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 of /tmp/hue_database_dump4.json from DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK] java.io.IOException: Incorrect value for packet payload size: 57616164 at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doRead(PacketReceiver.java:159) at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.receiveNextPacket(PacketReceiver.java:102) at org.apache.hadoop.hdfs.RemoteBlockReader2.readNextPacket(RemoteBlockReader2.java:201) at org.apache.hadoop.hdfs.RemoteBlockReader2.read(RemoteBlockReader2.java:152) at org.apache.hadoop.hdfs.DFSInputStream$ByteArrayStrategy.doRead(DFSInputStream.java:775) at org.apache.hadoop.hdfs.DFSInputStream.readBuffer(DFSInputStream.java:831) at org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:891) at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934) at java.io.DataInputStream.read(DataInputStream.java:100) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:85) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:59) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:119) at org.apache.hadoop.fs.shell.Display$Cat.printToStdout(Display.java:107) at org.apache.hadoop.fs.shell.Display$Cat.processPath(Display.java:102) at org.apache.hadoop.fs.shell.Command.processPaths(Command.java:317) at org.apache.hadoop.fs.shell.Command.processPathArgument(Command.java:289) at org.apache.hadoop.fs.shell.Command.processArgument(Command.java:271) at org.apache.hadoop.fs.shell.Command.processArguments(Command.java:255) at org.apache.hadoop.fs.shell.Command.processRawArguments(Command.java:201) at org.apache.hadoop.fs.shell.Command.run(Command.java:165) at org.apache.hadoop.fs.FsShell.run(FsShell.java:287) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84) at org.apache.hadoop.fs.FsShell.main(FsShell.java:340) 16/09/29 15:13:45 INFO hdfs.DFSClient: Could not obtain BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 from any node: java.io.IOException: No live nodes contain block BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 after checking nodes = [DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK], DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK]], ignoredNodes = null No live nodes contain current block Block locations: DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK] Dead nodes: DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK]. Will get new block locations from namenode and retry... 16/09/29 15:13:45 WARN hdfs.DFSClient: DFS chooseDataNode: got # 3 IOException, will wait for 13991.541436655532 msec. 16/09/29 15:13:59 WARN hdfs.DFSClient: DFS Read java.io.IOException: Incorrect value for packet payload size: 57616164 at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doRead(PacketReceiver.java:159) at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.receiveNextPacket(PacketReceiver.java:102) at org.apache.hadoop.hdfs.RemoteBlockReader2.readNextPacket(RemoteBlockReader2.java:201) at org.apache.hadoop.hdfs.RemoteBlockReader2.read(RemoteBlockReader2.java:152) at org.apache.hadoop.hdfs.DFSInputStream$ByteArrayStrategy.doRead(DFSInputStream.java:775) at org.apache.hadoop.hdfs.DFSInputStream.readBuffer(DFSInputStream.java:831) at org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:891) at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934) at java.io.DataInputStream.read(DataInputStream.java:100) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:85) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:59) at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:119) at org.apache.hadoop.fs.shell.Display$Cat.printToStdout(Display.java:107) at org.apache.hadoop.fs.shell.Display$Cat.processPath(Display.java:102) at org.apache.hadoop.fs.shell.Command.processPaths(Command.java:317) at org.apache.hadoop.fs.shell.Command.processPathArgument(Command.java:289) at org.apache.hadoop.fs.shell.Command.processArgument(Command.java:271) at org.apache.hadoop.fs.shell.Command.processArguments(Command.java:255) at org.apache.hadoop.fs.shell.Command.processRawArguments(Command.java:201) at org.apache.hadoop.fs.shell.Command.run(Command.java:165) at org.apache.hadoop.fs.FsShell.run(FsShell.java:287) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84) at org.apache.hadoop.fs.FsShell.main(FsShell.java:340) cat: Incorrect value for packet payload size: 57616164 二、分析 仔细上述异常,主要得到两点信息: 1、Could not obtain BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 from any node: java.io.IOException: No live nodes contain block BP-1776288592-10.7.12.154-1468904160674:blk_1073998236_257465 after checking nodes = [DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK], DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK]], ignoredNodes = null No live nodes contain current block Block locations: DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK] Dead nodes: DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK]. Will get new block locations from namenode and retry... 2、Incorrect value for packet payload size: 57616164 逐个分析,首先看第一个,通过No live nodes contain block,找到相关代码位置,如下: /** * Get the best node from which to stream the data. * @param block LocatedBlock, containing nodes in priority order. * @param ignoredNodes Do not choose nodes in this array (may be null) * @return The DNAddrPair of the best node. * @throws IOException */ private DNAddrPair getBestNodeDNAddrPair(LocatedBlock block, Collection<DatanodeInfo> ignoredNodes) throws IOException { DatanodeInfo[] nodes = block.getLocations(); StorageType[] storageTypes = block.getStorageTypes(); DatanodeInfo chosenNode = null; StorageType storageType = null; if (nodes != null) { for (int i = 0; i < nodes.length; i++) { if (!deadNodes.containsKey(nodes[i]) && (ignoredNodes == null || !ignoredNodes.contains(nodes[i]))) { chosenNode = nodes[i]; // Storage types are ordered to correspond with nodes, so use the same // index to get storage type. if (storageTypes != null && i < storageTypes.length) { storageType = storageTypes[i]; } break; } } } if (chosenNode == null) { throw new IOException("No live nodes contain block " + block.getBlock() + " after checking nodes = " + Arrays.toString(nodes) + ", ignoredNodes = " + ignoredNodes); } final String dnAddr = chosenNode.getXferAddr(dfsClient.getConf().connectToDnViaHostname); if (DFSClient.LOG.isDebugEnabled()) { DFSClient.LOG.debug("Connecting to datanode " + dnAddr); } InetSocketAddress targetAddr = NetUtils.createSocketAddr(dnAddr); return new DNAddrPair(chosenNode, targetAddr, storageType); } 但是这个异常后面的nodes = [DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK], DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK]],和ignoredNodes = null,基本可以确定没有DataNode因为某些原因被排除和忽略。继续往下分析日志,得到如下关键信息: Dead nodes: DatanodeInfoWithStorage[10.7.12.155:50010,DS-87568e9c-b339-4b0e-a09f-292118bcb752,DISK] DatanodeInfoWithStorage[10.7.12.156:50010,DS-80fb296c-1085-40ce-9dcf-e3a08327aa0d,DISK] 两个Node都被标记为Dead了,但是通过Web界面看两个DataNode都是正常的,如下: 这就有点奇怪了。只能继续往下看第二个异常输出:Incorrect value for packet payload size: 57616164,定位源码位置在PacketReceiver的doRead()方法中,如下: if (totalLen < 0 || totalLen > MAX_PACKET_SIZE) { throw new IOException("Incorrect value for packet payload size: " + payloadLen); } 也就是说,在接收数据包的过程中,数据包的总大小超过了阈值MAX_PACKET_SIZE,也就是16M,如下: /** * The max size of any single packet. This prevents OOMEs when * invalid data is sent. */ private static final int MAX_PACKET_SIZE = 16 * 1024 * 1024; 而根据异常输出的57616164,这个数据包的大小达到了54M之多。由此可以想到,小文件本身就很小,数据包也不会大,而大文件数据包就比较大,会超过阈值。但是那个要读的文件,大小也就 50M,为什么会都出4M多呢?继续往下看数据包的结构,如下: // Each packet looks like: // PLEN HLEN HEADER CHECKSUMS DATA // 32-bit 16-bit <protobuf> <variable length> // // PLEN: Payload length // = length(PLEN) + length(CHECKSUMS) + length(DATA) // This length includes its own encoded length in // the sum for historical reasons. // // HLEN: Header length // = length(HEADER) // // HEADER: the actual packet header fields, encoded in protobuf // CHECKSUMS: the crcs for the data chunk. May be missing if // checksums were not requested // DATA the actual block data Preconditions.checkState(curHeader == null || !curHeader.isLastPacketInBlock()); curPacketBuf.clear(); curPacketBuf.limit(PacketHeader.PKT_LENGTHS_LEN); doReadFully(ch, in, curPacketBuf); curPacketBuf.flip(); int payloadLen = curPacketBuf.getInt(); 可以看到,这个数据包时包含Payload length,其值= length(PLEN) + length(CHECKSUMS) + length(DATA),还有Header length,其值= length(HEADER),最后是HEADER、CHECKSUMS和DATA,而除DATA外,其它的都是数据包额外添加的部分,这也就解释了为什么数据包比实际文件大小还大。 为什么数据包会如此之大呢?我们继续往下看数据包的发送过程,在BlockSender中数据包发送方法sendPacket()中,如下: /** * Sends a packet with up to maxChunks chunks of data. * * @param pkt buffer used for writing packet data * @param maxChunks maximum number of chunks to send * @param out stream to send data to * @param transferTo use transferTo to send data * @param throttler used for throttling data transfer bandwidth */ private int sendPacket(ByteBuffer pkt, int maxChunks, OutputStream out, boolean transferTo, DataTransferThrottler throttler) throws IOException { 这个ByteBuffer pkt实际上就是存放待发送数据包数据的缓冲区,它的大小决定了发送数据包的大小,那么它的大小是如何设定的呢?继续分析,在doSendBlock()方法中,如下: ByteBuffer pktBuf = ByteBuffer.allocate(pktBufSize); while (endOffset > offset && !Thread.currentThread().isInterrupted()) { manageOsCache(); long len = sendPacket(pktBuf, maxChunksPerPacket, streamForSendChunks, transferTo, throttler); offset += len; totalRead += len + (numberOfChunks(len) * checksumSize); seqno++; } 先根据pktBufSize申请内存,确定缓冲区ByteBufferpktBuf,然后再sendPacket()发送数据包。很明显,我们只需要知道pktBufSize是如何确定的就行了。如下: if (transferTo) { FileChannel fileChannel = ((FileInputStream)blockIn).getChannel(); blockInPosition = fileChannel.position(); streamForSendChunks = baseStream; maxChunksPerPacket = numberOfChunks(TRANSFERTO_BUFFER_SIZE); // Smaller packet size to only hold checksum when doing transferTo pktBufSize += checksumSize * maxChunksPerPacket; } else { maxChunksPerPacket = Math.max(1, numberOfChunks(HdfsConstants.IO_FILE_BUFFER_SIZE)); // Packet size includes both checksum and data pktBufSize += (chunkSize + checksumSize) * maxChunksPerPacket; } 这个pktBufSize与maxChunksPerPacket相关,而maxChunksPerPacket的大小确定方法如下: maxChunksPerPacket = Math.max(1, numberOfChunks(HdfsConstants.IO_FILE_BUFFER_SIZE)); 也就是和参数IO_FILE_BUFFER_SIZE,即io.file.buffer.size有关,默认为4096,即4KB,如下: public static final String IO_FILE_BUFFER_SIZE_KEY = "io.file.buffer.size"; /** Default value for IO_FILE_BUFFER_SIZE_KEY */ public static final int IO_FILE_BUFFER_SIZE_DEFAULT = 4096; 而实际查看集群中的配置,如下: 足有125M......这也就是为什么数据包会如此之大的原因。 修改参数,重启节点后,读取数据正常。 三、答案 参数io.file.buffer.size配置过大,导致数据包发送超过数据包接收时设定的阈值。

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册