大数据运维问题记录(九)

问题描述:部门承接的某运营商的CRM项目日志查询出现延迟,最高延迟达半小时,严重影响业务运行。
问题解决:首先对他们的数据流向进行了解后得知,数据是从Flume采集到Kafka再由Sparkstreaming到Elasticsearch, Elasticsearch做为数据存储,版本为2.3.2,CRM系统就是在前端对Elasticsearch进行查询,在此之前Elasticsearch集群出现过一次瘫痪,然后启动不起来,他们对Elasticsearch集群做过一次优化,听他们反应之前是没有延迟的,是集群优化后出现了此问题。首先确定一下到底是哪个环节出现的问题,查看原始文件生成时间到Flume日志打印出来的时间,没有出现延迟,kafka这块采用了一个小工具叫KafkaOffsetMonitor,监控进入kafka的速率和从kafka出的速率确认kafka这块的问题不大(顺便说一下,给KafkaOffsetMonitor分配的java heap要大点,要不然数据太大的话界面会显示不出来),查看elasticsearch的入库时间发现这块有延迟,那么问题就基本确定了,要不是sparkstreaming这块处理的慢了,要不就是elasticsearch这块入库慢了。查看sparkstreaming任务发现还算稳定因为每批次任务是一分钟执行一次,任务基本都在一分钟之内能够完成,对spark执行命令和sparkstreaming程序做了些优化,sparkstreaming这边没有太大改变,高峰期延迟依然存在,那么问题就定位到elasticsearch上了,对elasticsearch的cpu,io,内存和gc的情况进行检查没发现什么问题,查看配置文件发现常用的优化点基本都涉及到了,问现场要优化前的配置说没有备份,只能一个一个配置项看,询问现场每小时的数据量,高峰期的话能达到2200多万,现在延迟基本就在高峰期的两个时间点,一个是早上10点,一个是下午4点,其余时间没有延迟,经过一个一个配置项排查,发现有个配置是index.translog.flush_threshold,值设置的是100000,查看官方文档2.3.2版本配置说明, translog flush相关的配置项有index.translog.flush_threshold_size,默认值为512mb,index.translog.flush_threshold_ops,默认值为unlimited(也就是INT.MAX),index.translog.flush_threshold_period,默认值为30m,index.translog.interval,默认值为5s。没有发现index.translog.flush_threshold这个配置项,后来看日志才知道这么设置的话代表index.translog.flush_threshold_ops这个配置项,在这说明一下es 在每次进行index或者delete操作后都会记录到translog中,默认是同步的,也就是每个request都会记录到translog中并flush到磁盘,通过修改index.translog.durability这个参数可以改为异步的,这个配置他们也改成了async,这个异步的执行机制是先将每次的translog放到内存buffer中,每5s(index.translog.interval)进行一次检查看是否满足index.translog.flush_threshold_size,index.translog.flush_threshold_ops,index.translog.flush_threshold_period,这三个条件中的一个,只要满足就进行一次flush操作将translog flush到磁盘,那么结合场景计算高峰期2200万每小时,平均1秒就有6000多次操作,达到index.translog.flush_threshold_ops的100000也就十几秒钟,这个flush频率有些快,影响效率,所以这块用默认值就可以,然后我将index.translog.flush_threshold_size的值设置为1g,可能这块重启集群后测试,在高峰期没有再出现延迟的情况。
总结:首先现场实施人员要对每次配置做备份,其次对每个优化点进行优化时要针对自己实际业务的场景进行优化配置,不要盲目拷贝,还要对每个优化配置项的含义进行较深入的了解,这样才能更好的利用好这些优化点

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,884评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,347评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,435评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,509评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,611评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,837评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,987评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,730评论 0 267
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,194评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,525评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,664评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,334评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,944评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,764评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,997评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,389评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,554评论 2 349

推荐阅读更多精彩内容

  • 上边已经对我配置es集群设置的参数有了简单的说明,但是其实还有许多参数没有设置和说明 -- 修改配置 /etc/e...
    liutoliu阅读 355评论 0 0
  • 上周出现了一次故障,recovery的过程比较慢,然后发现Shard 在做恢复的过程一般都是卡在TRANSLOG阶...
    祝威廉阅读 8,669评论 9 5
  • ES来源 Elasticsearch 来源于作者 Shay Banon 的第一个开源项目Compass库,而这个库...
    maquewy阅读 4,654评论 0 58
  • 笔者:横横丨横 (2)三月急雨细如绵 杭州 湖心岛 许是入了夏的缘故,虽下了场急雨,雨停后却不寒冷,反倒有几分清...
    横横丨横阅读 326评论 0 1
  • 望着满屋的凌乱,“是该整理一下了”,我对自己说。 因为物品的杂乱不仅仅是物品本身,这已经严重影响到我的生活,不能让...
    一叶静莲阅读 664评论 3 11