sqlldr加载性能问题的排查 (r2第2天)

最近根据业务需要加载一批数据,在生产环境中不到半个小时就完了,可是到了测试环境,竟然跑了6个多小时,另外测试环境和生产环境的数据情况都基本差不多,主机配置也基本类似。 大家的注意力都集中到了sqlldr的加载性能上。等到他们找到我时,已经讨论了不少关于direct,convention加载的各种情况了,看似工作也做了不少了。 然后我通过邮件历史记录看到大家还讨论了可能是index导致的结果。 等到邮件转到我这的时候,已经问题算升了一个等级了。我首先要确定的就是具体的环境,在那台服务器上跑sqlldr,要把数据加载到哪个库。如果在生产上半个小时,可能在环境的某些地方还是有一些差别。 首先和开发协调了下,要到了他们使用的control file和sqlldr的命令。 首先查看control file,可以看到字段并不多,结构也不复杂。

load data
 discardmax 999
 into table GD1_SUBSCR_KEY
 fields terminated by "!"
 TRAILING NULLCOLS
 ( RESOURCE_VALUE ,RESOURCE_TYPE,EFFECTIVE_DATE DATE(19) "YYYY-MM-DD HH24:MI:SS",EXPIRATION_DATE  DATE(19) "YYYY-MM-DD HH24:MI:SS" ,SUBSCRIBER_NO,SUB_STATUS,CUSTOMER_ID,ACTV_CODE_IND,BE,LANGUAGE CHAR TERMINATED BY '!!',ROUTING_POLICY_ID, L9_PORT_IND,L9_SPLIT_PERIOD ) 

查看要加载的数据文件,内容如下,数据信息也没有什么特别的地方。

520002055869828!I!2014-05-06 12:19:42!4700-12-31 00:00:00!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-05-02 14:46:11!2014-05-06 12:19:42!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-05-02 12:46:07!2014-05-02 14:46:11!1003500!U!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-05-02 08:41:12!2014-05-02 12:46:07!1003500!U!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-05-02 08:31:28!2014-05-02 08:41:12!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-02-08 19:39:55!2014-05-02 08:31:28!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-02-08 19:39:52!2014-02-08 19:39:55!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-02-08 19:35:49!2014-02-08 19:39:52!1003500!A!493053!!0!TH!!0!!NONE!

查看sqlldr的命令,和开发确认过,和生产使用的是同一套。所以基本的配置都有。没有太大问题。

sqlldr <USER>/<PSW>@<INSTANCE> <uh_ctrl_GD1_XXXX.ctl> DATA=<UH_CRT_GD_XXXX_DDMMYY_HHMISS> DISCARD=GD1_XXXX.dsc  SILENT=FEEDBACK ERRORS=499 LOG=log_GDY_XXXX.log BAD=bad_ORA_FULL_GDY_XXXX_<YYMMDD>.<HHMISS>.dat rows=1000

有了以上的信息,就可以从cpu,io等方面来排查了。 首先是cpu,在目标的服务器上面有10台db instances,其中大部分都是在特定的应用中才用到,所以服务器上的cpu消耗并不高。 在生产系统中,只有4台db instances,把其它的库都分离到别的服务器上了。查看cpu的负载情况,没有太大的出入。当然了,我查看的时候数据已经加载完成了,也不能确定当时的cpu负载情况,这个时候可以从sqlldr日志中得到印证。加载了6个小时,cpu时间其实就是半个小时左右。这样来说cpu导致的可能性很小。

4096786 Rows successfully loaded.
Run began on Wed Jun 11 08:52:55 2014
Run ended on Wed Jun 11 14:57:40 2014
Elapsed time was:     06:04:44.05
CPU time was:         00:00:38.18

其次从io的角度来看。可能测试环境的Io负载要略微大一些,因为有两套环境在上面,都是使用,但是数据库这边来说测试环境的使用也不是很频繁,只是例行做一些测试而已。而在生产上可能要很多在线业务需要跑一些比较大的查询,从某种角度来说,尽管测试环境的数据库实例多一些,但是负载还要比生产环境小一些。 关于这个可以使用sar,iostat等命令来查看。 cpu,io都没有问题。 看看缓存,有个做性能的哥们查看了一下缓存的情况,说测试环境的paging情况比较多,建议停掉一些其他的库来释放掉一些缓存,提高数据加载的速度,我马上就表示反对,因为这台服务器有180G内存,每个库的sga都基本在8G左右,所以10个库,总共占用的缓存也在100G左右,加上一些额外的paging,因为测试环境的使用频率不是很高。所以在缓存上可能会相比生产环境要差一些,但是缓存还是相对ijiao充足的。 以上的情况都排除,我来看看网络情况,因为个人也对网络不是很在手。不过可以做一些简单的测试来印证。 首先在生产环境中做了一个scp的操作。把一个100m的文件传送到另一个客户端。每秒传送速度在50M左右,很快就完了。 然后我在测试环境做了类似的操作,把文件从客户端传送到测试数据库端。发现网络相比而言,慢了很多。 测试2个文件,开始在150KB/秒的样子,过了一会速度就降下来了。最低的时候再20kb左右的样子。

test.data                                                   0%  288KB 153.3KB/s   0.0KB/s   22:10 ETA^
test.data1                                                  0% 1232KB  22.4KB/s  32.0KB/s 4:35:24 ETA

有了这些信息,之前的纷争一下子就清晰了很多。测试环境在基本类似的情况下,速度那么慢,根源就在于网络。 尽管服务端,客户端的cpu,io,缓存等配置都类似,但是速度就卡在了网络了。想象也是,可能有些复杂的问题的原因其实很简单。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-06-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

DBA和开发同事的一些代沟(五) (r7笔记第92天)

陆陆续续写了四篇和开发同事的代沟,从最开始的吐槽到后面的例行总结,整个过程也是总结经验,看似很小的问题对于DBA来说就是莫大的改进,或者在开发严重越不过去的坎儿...

429100
来自专栏杨建荣的学习笔记

一个简单的bigfile tablespace无法扩展的案例处理 (r8笔记第31天)

最近帮助开发的同学处理了一个简单的问题,想通过这个问题来反思一下。 在一天下午的时候,开发的同事突然找到我说,有一个开发的数据库貌似有些表空间的问题,...

29970
来自专栏微信终端开发团队的专栏

微信移动端数据库组件 WCDB 系列:数据库修复三板斧(二)

之前一篇文章《微信 SQLite 数据库修复实践》介绍了微信对SQLite数据库修复以及降低损坏率的实践, 这次再深入介绍一下微信数据库修复的具体方案和发展历程...

70500
来自专栏数据和云

青铜到王者,看看你的MySQL数据库是什么段位,如何提升?

作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

23640
来自专栏数据库新发现

Oracle数据恢复:格式化、ASM及字典损坏案例三则

链接:http://www.eygle.com/archives/2010/06/asm_format_dictionary.html

14620
来自专栏铭毅天下

实战 | Elasticsearch打造知识库检索系统

题记 源自“死磕Elasticsearch”技术群里的讨论问题: ——我想用es做个类似于知识库的东西,所以需要索引一些pdf、word之类的文件,这个你...

94570
来自专栏杨建荣的学习笔记

增量数据丢失的原因分析(三)(r8笔记第91天)

今天开发的同事找到我说,他们发现一个应用今天应该会同步过来一部分数据,但是今天却没有,所以想让我帮忙看看到底是怎么回事。 对于这类需求也算是轻门熟路,不光维护管...

36040
来自专栏琯琯博客

awesome-mysql-cn资源

MySQL 资源列表,内容包括:分析工具、备份、性能测试、配置、部署、GUI 等。 分析工具 性能,结构和数据分析工具 Anemometer - 一个 SQL ...

45380
来自专栏Spark学习技巧

Flink:动态表上的连续查询

越来越多的公司在采用流处理技术,并将现有的批处理应用程序迁移到流处理或者为新的应用设计流处理方案。其中许多应用程序专注于分析流数据。分析的数据流来源广泛,如数据...

23530
来自专栏文渊之博

史上最大的CPU Bug(幽灵和熔断的OS&SQLServer补丁)

背景 原文地址(http://www.cnblogs.com/wenBlog/p/8435229.html) 最近针对我们的处理器出现了一系列的严重的bug。这...

40650

扫码关注云+社区

领取腾讯云代金券