双活环境下,银行夜间批量任务(含数据库全表更新步骤)对交易成功率有较大直接影响,如何调优?

这类问题我相信很多银行都会遇到,想交流一下如何解决的,能预想的原因有系统本身参数配置问题,加上双活本身造成的性能损耗,问题影响会成倍的增加,另外也和双活架构部署的先后顺序有关,部分企业是先在单点存储上线的业务,后搭建的存储双活容灾节点,从存储和整体双活架构角度,应该如何调整与均衡这些指标呢?

参与36

7同行回答

pysx0503pysx0503  系统工程师 , 第十区。散人
一般都是从网络带宽和存储Io两方面入手。显示全部

一般都是从网络带宽和存储Io两方面入手。

收起
系统集成 · 2020-04-02
浏览3756
youki2008youki2008  系统架构师 , DDT
存储双活情况下,批量任务的读性能是不会有影响的,主要影响还是在写性能上,这是无法避免的,可以考虑将批量任务只跑在一个存储节点上,另一个存储节点只是实时同步数据,做读写分离,减少相互的竞争来降低影响。...显示全部

存储双活情况下,批量任务的读性能是不会有影响的,主要影响还是在写性能上,这是无法避免的,可以考虑将批量任务只跑在一个存储节点上,另一个存储节点只是实时同步数据,做读写分离,减少相互的竞争来降低影响。

收起
互联网服务 · 2020-04-24
浏览3047
jxnxsdengyujxnxsdengyu  系统工程师 , 江西农信
存储双活情况下,批量任务的读性能是不会有影响的,主要影响还是在写性能上,这是无法避免的,可以考虑将批量任务只跑在一个存储节点上,另一个存储节点只是实时同步数据,减少相互的竞争。另外可以考虑减少更新动作导致数据物理落盘的频率,例如增大数据库日志缓存等参数。...显示全部

存储双活情况下,批量任务的读性能是不会有影响的,主要影响还是在写性能上,这是无法避免的,可以考虑将批量任务只跑在一个存储节点上,另一个存储节点只是实时同步数据,减少相互的竞争。另外可以考虑减少更新动作导致数据物理落盘的频率,例如增大数据库日志缓存等参数。

收起
银行 · 2020-04-07
浏览3592
lfherelfhere  金融行业高级系统工程师 , 戴尔科技金融行业解决方案中心
个人理解交易成功率降低大概率是数据写入出现了问题,首先采集数据库、主机、网络(主要是双活同步网络)和底层存储的日志,然后分析跑批期间的有没有出现资源利用率过高导致写入受到严重影响的环节,具体分析后才能进行有效的调整。所有的双活和同步复制都要求写数据在两个设备的...显示全部

个人理解交易成功率降低大概率是数据写入出现了问题,首先采集数据库、主机、网络(主要是双活同步网络)和底层存储的日志,然后分析跑批期间的有没有出现资源利用率过高导致写入受到严重影响的环节,具体分析后才能进行有效的调整。
所有的双活和同步复制都要求写数据在两个设备的一致写入,跑批期间有大量的过程数据写入,都会面临比较大的挑战。我曾经碰到过一家行因为复制链路带宽过低导致大量IO拥塞导致出现问题,通过带宽扩容解决了问题。但是,前提还是前面说的,找到问题的原因才能优化。

收起
IT其它 · 2020-03-27
浏览4336
bbaimm88bbaimm88  系统架构师 , 银行
批量  属于 OLAP 业务处理,交易属于  OLTP业务处理, 在跑批影响 交易,这个从底层 OS、DB是无法完美解决,需要软件的开发来设计,应对高峰的批量业务保障 业务进行,很多跑批结算日 是自定义 日结切换时间,比如核心切换是每天11:30分, 其他业务也随之同步切换日切记账。...显示全部

批量  属于 OLAP 业务处理,
交易属于  OLTP业务处理, 在跑批影响 交易,这个从底层 OS、DB是无法
完美解决,需要软件的开发来设计,应对高峰的批量业务保障 业务进行,很多跑批结算日 是自定义 日结切换时间,比如核心切换是每天11:30分, 其他业务也随之同步切换日切记账。  通过应用逻辑设计来规避数据表竞争,解决表竞争就能很好解决 交易业务问题。 
这个设计的业务改造就比较大。

收起
银行 · 2020-03-27
浏览4121
summitsummit  架构管理岗 , 某城商银行
双活环境下,夜间批处理任务影响性能的情况主要是大数据量的数据库批处理造成大量的IO读写,两个数据中心同步造成IO读写延迟,如果双活采用存储双活的话,一是增加两个数据中心san网络的链路数量,增加链路带宽,降低同步延迟。二是优化存储配置,采用就近访问策略,保障双活节点的读写...显示全部

双活环境下,夜间批处理任务影响性能的情况主要是大数据量的数据库批处理造成大量的IO读写,两个数据中心同步造成IO读写延迟,如果双活采用存储双活的话,一是增加两个数据中心san网络的链路数量,增加链路带宽,降低同步延迟。二是优化存储配置,采用就近访问策略,保障双活节点的读写只在本数据中心存储,减少跨数据中心的读写操作。

收起
银行 · 2020-03-27
浏览4213
匿名用户匿名用户  其它 , 某银行
不知道你所说的成功率较大影响是因为什么,我所碰到的,影响交易的,一般都是应用设置了超时失败机制而“主动失败的”,所以要去分析一下为什么超时的。一般性交易SQL的执行时间超时,大概率是主机资源被占用(尤其是IO),导致平常1s执行完成的SQL执行了5s,这样就返回超时,碰到这种情况应...显示全部

不知道你所说的成功率较大影响是因为什么,我所碰到的,影响交易的,一般都是应用设置了超时失败机制而“主动失败的”,所以要去分析一下为什么超时的。
一般性交易SQL的执行时间超时,大概率是主机资源被占用(尤其是IO),导致平常1s执行完成的SQL执行了5s,这样就返回超时,碰到这种情况应该说还是比较简单的,增加IO就行,从硬件上更换存储,另外也还要看看SQL的IO开销和写法,看是否能尽可能的减少开销,优化。当然,如果可以,尽可能的缩减核心数据是最理想的办法,将历史、近期数据分离,如果可以的话,能将数据分类剥离更好,从而做到“小核心”。
还有一种,我是没碰到过,但是看你的描述“全表更新”,我姑且认为是全表级别的排它锁?如果真是这样,那应该说在逻辑上就有问题了吧?
另外我没接触过存储双活做容灾的,但是从一般的同步原理可以推测,如果是为了防止数据丢失做的“严格数据一致”,比如在Oracle Dataguard中sync模式,即为了容灾数据一致,要等待容灾接受全部信息返回结果生产才能提交的机制,那么在批量任务这种大IO,大数据变化量的情况下,可以想象也是对生产影响非常大的。

收起
银行 · 2020-04-02
浏览3960

提问者

zhangpeng4007
系统运维工程师某城市商业银行
擅长领域: 存储灾备服务器

问题来自

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2020-03-27
  • 关注会员:8 人
  • 问题浏览:8973
  • 最近回答:2020-04-24
  • X社区推广