网银业务系统运行缓慢分析

最新推荐文章于 2023-01-18 17:09:52 发布
最新推荐文章于 2023-01-18 17:09:52 发布
阅读量279 收藏
点赞数
文章标签： 数据库 awk 操作系统
一、 问题描述
    系统的操作用户反映某些操作功能比较慢，并且开发人员在向 数据库导入表数据时也非常慢，10万条数据导入花费近1小时，说明数据库确实有问题。
二、 问题分析
登录操作系统看了一下主机的负载以及数据库的性能状况，CPU总使用率较高，有90%，CPU实用情况如下：
$ topas
Topas Monitor for host:    55A_1                EVENTS/QUEUES    FILE/TTY
Thu Aug  5 16:26:39 2010   Interval:  2         Cswitch    1664  Readch    75343
                                                Syscall 133.9K   Writech 264.3K9
Kernel    3.3   |##                          |  Reads       821  Rawin         0
User     90.3   |##########################  |  Writes      744  Ttyout      386
Wait      0.0   |#                           |  Forks         0  Igets         0
Idle      6.5   |##                          |  Execs         0  Namei        75
                                                Runqueue   12.5  Dirblk        0
Network  KBPS   I-Pack  O-Pack   KB-In  KB-Out  Waitqueue   0.0
en0     154.8    764.0   772.5    57.6    97.2
en1       0.1      0.5     0.5     0.1     0.1  PAGING           MEMORY
lo0       0.1      1.0     1.0     0.0     0.0  Faults      216  Real,MB   32128
                                                Steals        0  % Comp     29.2
Disk    Busy%     KBPS     TPS KB-Read KB-Writ  PgspIn        0  % Noncomp  71.6
hdisk3    3.5    102.0    21.0     0.0   102.0  PgspOut       0  % Client   71.6
hdisk0    2.5     20.0     5.0     0.0    20.0  PageIn        1
hdisk1    2.0     22.0     5.5     2.0    20.0  PageOut      54  PAGING SPACE
hdisk2    1.0    210.0    18.5     4.0   206.0  Sios         56  Size,MB   15744
dac0      0.0      0.0     0.0     0.0     0.0                   % Used     45.7
dac1      0.0    312.0    39.5     4.0   308.0  NFS (calls/sec)  % Free     54.2
hdisk4    0.0      0.0     0.0     0.0     0.0  ServerV2       0
cd0       0.0      0.0     0.0     0.0     0.0  ClientV2       0   Press:
hdisk5    0.0      0.0     0.0     0.0     0.0  ServerV3       0   "h" for help
                                                ClientV3       0   "q" to quit Name            PID  CPU%  PgSp Owner
oracle      1994848   6.7   6.9 oracle
oracle      1302662   6.5   6.0 oracle
oracle      2171122   6.5   6.7 oracle
oracle      2363444   6.5   5.7 oracle
oracle      1773740   6.5   5.6 oracle
oracle      2150436   6.5   5.9 oracle
oracle      2805790   6.5   5.2 oracle
oracle      2228420   6.4   6.1 oracle
oracle      1953872   6.4   5.3 oracle
oracle      2142238   6.4   4.6 oracle
oracle      2470006   6.4   5.3 oracle
oracle      2138304   6.4   5.5 oracle
oracle      1662988   6.3   6.1 oracle
oracle      1999086   6.2   4.7 oracle
oracle      1925318   6.2   5.4 oracle
……..
通过vmstat命令监控内存，虚拟内存利用率同样比较高，FREE（自由表）比较小，物理内存的大部分被用作为文件系统数据的缓存实用。
通过进程查找发现系统后台有大量oracle进程：
ps -ef|grep oracle|grep LOCAL=NO
  oracle  548922       1   0   Jul 21      -  0:25 oracleczcb (LOCAL=NO)
  oracle  561180       1   0   Jul 21      -  0:17 oracleczcb (LOCAL=NO)
  oracle  831668       1   0   Jul 21      -  0:27 oracleczcb (LOCAL=NO)
  oracle  839800       1   0   Jul 21      -  0:00 oracleczcb (LOCAL=NO)
  oracle 1110138       1   0   Jul 21      -  0:02 oracleczcb (LOCAL=NO)
  oracle 1253464       1   0   Jul 21      -  0:39 oracleczcb (LOCAL=NO)
  oracle 1364076       1   0   Jul 21      -  0:00 oracleczcb (LOCAL=NO)
  oracle 1417398       1   0   Jul 21      -  0:16 oracleczcb (LOCAL=NO)
  oracle 1429736       1   0   Jul 21      -  0:08 oracleczcb (LOCAL=NO)
  oracle 1437710       1   0   Jul 21      -  0:07 oracleczcb (LOCAL=NO)
  oracle 1441824       1   0   Jul 21      -  0:18 oracleczcb (LOCAL=NO)
  oracle 1454248       1   0   Jul 21      -  0:00 oracleczcb (LOCAL=NO)
  oracle 1519650       1   0   Jul 21      -  0:03 oracleczcb (LOCAL=NO)
  oracle 1527910       1   0   Jul 21      -  0:10 oracleczcb (LOCAL=NO)
  oracle 1536058       1   0   Jul 21      -  0:03 oracleczcb (LOCAL=NO)
  oracle 1540294       1   0   Jul 21      -  0:17 oracleczcb (LOCAL=NO)
  oracle 1548304       1   0   Jul 21      -  0:13 oracleczcb (LOCAL=NO)
…..
统计分析后发现有400多进程：
ps -ef|grep oracle|grep LOCAL=NO|grep -v grep|awk '{print $2}'|wc
406    3836   29155
数据库共运行有7个实例，经分析发现只有个别实例出现了大量请求未释放，请求连接从3月份到8月份，每个月逐渐累加，随着后台进程的慢慢积累，造成系统资源被大量占用，系统资源紧张，数据库系统逐渐变慢。
但是分析看很多进程为某天晚上积累，比如7月21号，0点后的操作累积了近50个挂起的连接，所以需要开发人员确认当天晚上是否做了系统变更引起，同样其他的挂起进程也需要检查。
通过如下语句查找对应月份的连接进程，kill该月份所有的挂起进程，系统资源被释放。
ps -ef|grep oracle|grep LOCAL=NO |grep Jul |grep -v grep |awk '{print $2}'|xargs kill -9
ps -ef|grep oracle|grep LOCAL=NO |grep Apr |grep -v grep |awk '{print $2}'|xargs kill -9
ps -ef|grep oracle|grep LOCAL=NO |grep Jun |grep -v grep |awk '{print $2}'|xargs kill -9
ps -ef|grep oracle|grep LOCAL=NO |grep Mar |grep -v grep |awk '{print $2}'|xargs kill -9
系统资源被释放：
Topas Monitor for host:    55A_1                EVENTS/QUEUES    FILE/TTY
Thu Aug  5 20:49:11 2010   Interval:  2         Cswitch     377  Readch  167.4K4
                                                Syscall    1158  Writech 253.2K0
Kernel    1.1   |#                           |  Reads        57  Rawin         0
User      0.5   |#                           |  Writes       25  Ttyout      345
Wait      0.4   |#                           |  Forks         0  Igets         0
Idle     98.1   |############################|  Execs         0  Namei        26
                                                Runqueue    0.5  Dirblk        0
Network  KBPS   I-Pack  O-Pack   KB-In  KB-Out  Waitqueue   0.0
en0       1.9      5.5     5.0     0.8     1.1
en1       0.2      1.0     1.0     0.1     0.1  PAGING           MEMORY
lo0       0.2      2.0     2.0     0.1     0.1  Faults       55  Real,MB   32128
                                                Steals        0  % Comp     25.2
Disk    Busy%     KBPS     TPS KB-Read KB-Writ  PgspIn        2  % Noncomp  75.6
hdisk1    4.9     35.8     8.9    11.9    23.9  PgspOut       0  % Client   75.6
dac0      0.0      0.0     0.0     0.0     0.0  PageIn        2
dac1      0.0    335.9    41.2     0.0   335.9  PageOut      65  PAGING SPACE
hdisk0    0.0     23.9     6.0     0.0    23.9  Sios         68  Size,MB   15744
hdisk2    0.0    246.5    23.4     0.0   246.5                   % Used     34.9
cd0       0.0      0.0     0.0     0.0     0.0  NFS (calls/sec)  % Free     65.0
hdisk3    0.0     89.4    17.9     0.0    89.4  ServerV2       0
hdisk4    0.0      0.0     0.0     0.0     0.0  ClientV2       0   Press:
hdisk5    0.0      0.0     0.0     0.0     0.0  ServerV3       0   "h" for help
                                                ClientV3       0   "q" to quit
Name            PID  CPU%  PgSp Owner
syncd        164026   0.7   0.5 root 
oracle      2805786   0.2   5.2 oracle
oracle      2289824   0.1   5.9 oracle
topas       2748538   0.1   2.5 oracle
oracle      2834676   0.0   4.1 oracle
oracle      1282162   0.0   4.0 oracle
 
编写shell脚本
#vi kill_no_local_connect.sh
#!/bin/sh
ps -e -o pid -o etime -o args|grep oracle|grep LOCAL=NO|grep ->/tmp/tmpfile
# ps -e -o pid -o etime -o args|grep oracle|grep LOCAL=NO|grep -|awk '{print $2}'|awk -F- '{print $1}'
cat /tmp/tmpfile|while read LINE
do
TIME=`echo $LINE|awk '{print $2}'`
TIME=`echo $TIME|awk -F- '{print $1}'`
if [ $TIME -gt 3 ]
then
echo $LINE|awk '{print $1}'|xargs -t -n1 kill -9
fi
done
rm -f /tmp/tmpfile
 
加入定时任务
0 23 * * * /opt/kill_no_local_connect.sh

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25369863/viewspace-688247/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25369863/viewspace-688247/

cpk86585
关注
信息化系统项目实施方案模板
珞圻的博客
02-23 1013
不动产统一登记信息系统 实施方案 自然资源和不动产确权登记中心 2020年9月
东软集团业务的波特五力模型分析
热门推荐
XiufengWu的博客
04-28 2万+
东软集团介绍：         东软是一家面向全球提供IT解决方案与服务的公司，致力于通过创新的信息化技术来推动社会的发展与变革，为个人创造新的生活方式，为社会创造价值。公司创立于1991年，目前拥有近20000名员工，在中国建立了8个区域总部，10个软件研发基地， 16个软件开发与技术支持中心，在60多个城市建立营销与服务网络; 在美国、日本、欧洲、中东、南美设有子公司。东软是中国第一个上市的
某银行网上业务系统操作缓慢问题分析及解决
cj3100412012的博客
11-18 765
一、问题描述 系统的操作用户反映某些操作功能比较慢，并且开发人员在向数据库导入表数据时也非常慢，10万条数据导入花费近1小时，说明数据库确实有问题。二、问题分析登录操作系统看了一下主机的负载以及数据库的性能状况，CPU...
关于某业务访问慢问题详细分析
cctimingroad的博客
01-18 307
通过抓包定位和DNS配置修改分析访问慢原因
运行几年后，业务系统变得越来越复杂，性能变得越来越慢的常用解决方案，分享13年架构经验方案
一火的专栏
11-13 1270
公司业务系统使用5年了，系统越来越臃肿，数据量越来越多，系统时不时卡顿，再结合自己10多年工作经历，给大家分析一下常用的解决方案。 方案一：找出问题最大的模块，定位原因，老系统做下简单优化，同时搭建新架构模块化或服务化根除病根。 注意：要规避一次性大规模架构调整的方案，来替换老系统。 根据定位问题-》指定方案-》执行并上线三部曲，一步一步去做，涉及细节比较多，本文只提供思路，不讨论具体实现，...
网银因系统拥堵变慢 SOA成罪魁祸首
项立纲
10-10 699
                                    IT管理者本来寄希望于SOA解决系统运维中的一些问题，而这个治病的良药，偏偏又可能带来新的疾病，如网银因系统拥堵而变慢。如何克服SOA架构下的新问题，也就成了IT管理者所要面临的首要任务。  系统运行维护一直是企业IT部门的重头戏，而在银行这样拥有众多应用系统的大型企业，运维问题显得更加突出。当SOA架构出现时，银行的
如果网站访问速度比较慢，你该如何处理？
newxwj的博客
03-09 1612
有哪些方面的因素会导致网站网站访问慢？ 1、服务器出口带宽不够用 本身服务器购买的出口带宽比较小。一旦并发量大的话，就会造成分给每个用户的出口带宽就小，访问速度自然就会慢。 跨运营商网络导致带宽缩减。例如，公司网站放在电信的网络上，那么客户这边对接是长城宽带或联通，这也可能导致带宽的缩减。 2、服务器负载过大，导致响应不过来 可以从两个方面入手分析： 分析系统负载，使用 w 命...
网上报销管理系统解决方案_.doc
最新发布
07-10
网上报销系统集成账务核算、预算管理和网上银行，确保报销信息的实时反映和费用支出的规范收集，实现数据共享和集成。系统通过预算控制，强化了费用管理，为决策者提供了详细的费用支出和预算执行情况。 1.2 公司...
对XX市银行卡现状调查分析及联网联合发展之思考.doc
02-19
三是服务功能滞后，信用卡发展缓慢，消费信贷功能未充分开发，卡支付在大宗消费领域的应用不足，同时网上银行功能受到安全性和支付网关统一性的限制。四是技术条件有待提升，ATM和POS机的故障率较高，影响了用户的...
项目一 认识Linux操作系统
tx16_38381516139的博客
03-13 762
任务一   查找Linux系统的基本概况第1步：通过搜索引擎搜索“Linux”在QQ浏览器搜索引擎中搜索“UNIX”,"Linux","Linux操作系统"等关键词，阅读与之相关的文字材料。unix 锁定本词条由“科普中国”百科科学词条编写与应用工作项目 审核 。UNIX操作系统（尤尼斯），是一个强大的多用户、多任务操作系统，支持多种处理器架构，按照操作系统的分类，属于分时操作系统，最早由KenT...
WEB项目从浏览器发起交易响应缓慢，简述从哪些方面入手分析
weixin_44227923的博客
02-26 1249
1、查看网络的ping值 ，网络使用情况（主查，服务器到核心交换机的ping 值，当前客户端和核心交换机的ping 值，小于1正常，大于10说明你核心交换机有大负载）。 2、查看服务器CPU占用率（主查，服务器的CPU占用率，大于80%说明服务器CPU并发不够） 3、查看服务器的内存（内存空闲小于10%时，完全靠硬盘的读写来支撑，肯定慢，这种情况下硬盘寿命也短） 4、查看你的数据库占用率（占...
一个典型业务系统卡顿故障分析
littleandbig的专栏
08-04 2315
背景提要： 今年在一家客户单位驻场，遇到了一个很是经典的业务系统故障。首先是客户反馈的信息成扩大化和添油化，某日下午17点接到前台的一个科室故障反馈，第二天又反馈已经有一周了，第三天又反馈全单位都有系统使用卡顿情况，同时有反馈情况出现有半个月了。其次是无法测试定位，因为出现这种情况随机测试并无发现卡顿情况，爆发卡顿情况的时间和情况比较笼统，当前台反馈后，后端直接测试访问无异常。最后是时间，由于客户单位负责人性格直率，发现问题要求立刻解决，对于问题产生的情况原因漠不关心，急促的要...
银行核心系统批处理面临的挑战
weixin_42306441的博客
01-17 1983
银行核心系统批处理面临的挑战 众所周知，银行核心系统每天晚上都要进行批处理。这个批处理主要进行的工作包括账户利息计提、利息结算、收入摊销、贷款还款、自动转账、自动处理账户冻结、账户挂失等。 但是随着银行业务发展，这种批处理的模式存在着一些的挑战。 银行财务报告延时问题 按目前的方式，银行一般需要在T+1才能得到T日的财务报告，即使有些银行开始实施准实时总账，也是把一天分为多个时段，每个时段一个批次，按批次处理总账，并没有解决晚上集中大量处理计提摊销结息的引起的报表差别较大的问题。 24小时准点日切的
系统运行缓慢排查思路
stulcc的博客
05-20 561
添加链接描述
系统运行缓慢该怎么排查
qq_44936336的博客
09-30 1745
对于系统运行缓慢问题，要分情况讨论： 如果该问题导致线上系统不可用 出现这种情况可能的原因主要有两种： 代码中某个位置读取数据量较大，导致系统内存耗尽，从而导致 Full GC 次数过多，系统缓慢。 代码中有比较耗 CPU 的操作，导致 CPU 过高，系统运行缓慢。 解决方法：导出 jstack 和内存信息，然后重启系统，尽快保证系统的可用性。 另外有几种情况也会导致某个功能运行缓慢，但是不至于导致系统不可用： 代码某个位置有阻塞性的操作，导致该功能调用整体比较耗时，但出现是比较随机的。 某个
综合业务会计应用系统风险及防范
包包的专栏
09-02 1569
作者：罗娅丹、杨名、刘璐、康喆… 文章来源：政策金融网 点击数：184 更新时间：2009-3-31 9:00:09综合业务会计应用系统（以下简称系统）自上线运行以来，一直演绎着农发行管理核算的“心脏”角色，它的平稳安全高效运行关系着农发行经营管理的发展，关系着农发行资金营运的安全，关系着农发行结算服务的效率，关系着农发行对外形象的展示，如何有效防范系统风险，提高运行管理水平是系统运行
从一次 FULL GC 卡顿谈对服务的影响
Weiguang_123的专栏
09-19 1万+
问题的发现： 看到线上的服务机器一些节点时不时地有TCP报警 ， 所以我们断定是TCP的连接出现了问题。 让我们来回顾一下TCP的三次握手和四次挥手，借网上的一个图： sinai full gc with promotion failed > image2015-9-16 22:15:46.png" height="250" src="http://wiki.sa
解Bug之路-记一次中间件导致的慢SQL排查过程
weixin_34259232的博客
12-27 210
2019独角兽企业重金招聘Python工程师标准>>> ...
银行网银系统访问缓慢：深度分析与解决方案
"某银行网银系统访问缓慢的分析案例，由CSNA网络分析专家李辉提供，展示了如何深入分析并解决网银系统性能问题。报告指出，访问缓慢可能由流量拥塞、网络延迟、设备转发故障或服务器响应慢等因素引起，并通过流量...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值