读取大量数据时数据时内存溢出怎样分批读取该怎么处理

读取大量数据时数据时内存溢出怎样分批读取该怎么处理,第1张

众所周知,java在处理数据量比较大的时候,加载到内存必然会导致内存溢出,而在一些数据处理中我们不得不去处理海量数据,在做数据处理中,我们常见的手段是分解,压缩,并行,临时文件等方法例如,我们要将数据库(不论是什么数据库)的数据导出到一个文件,一般是Excel或文本格式的CSV对于Excel来讲,对于POI和JXL的接口,你很多时候没有法去控制内存什么时候向磁盘写入,很恶心,而且这些API在内存构造的对象大小将比数据原有的大小要大很多倍数,所以你不得不去拆分Excel,还好,POI开始意识到这个问题,在3.8.4的版本后,开始提供cache的行数,提供了SXSSFWorkbook的接口,可以设置在内存中的行数,不过可惜的是,他当你超过这个行数,每添加一行,它就将相对行数前面的一行写入磁盘(如你设置2000行的话,当你写第20001行的时候,他会将第一行写入磁盘),其实这个时候他些的临时文件,以至于不消耗内存,不过这样你会发现,刷磁盘的频率会非常高,我们的确不想这样,因为我们想让他达到一个范围一次性将数据刷如磁盘,比如一次刷1M之类的做法,可惜现在还没有这种API,很痛苦,我自己做过测试,通过写小的Excel比使用目前提供刷磁盘的API来写大文件,效率要高一些,而且这样如果访问的人稍微多一些磁盘IO可能会扛不住,因为IO资源是非常有限的,所以还是拆文件才是上策而当我们写CSV,也就是文本类型的文件,我们很多时候是可以自己控制的,不过你不要用CSV自己提供的API,也是不太可控的,CSV本身就是文本文件,你按照文本格式写入即可被CSV识别出来如何写入呢?下面来说说。。。在处理数据层面,如从数据库中读取数据,生成本地文件,写代码为了方便,我们未必要1M怎么来处理,这个交给底层的驱动程序去拆分,对于我们的程序来讲我们认为它是连续写即可我们比如想将一个1000W数据的数据库表,导出到文件此时,你要么进行分页,oracle当然用三层包装即可,mysql用limit,不过分页每次都会新的查询,而且随着翻页,会越来越慢,其实我们想拿到一个句柄,然后向下游动,编译一部分数据(如10000行)将写文件一次(写文件细节不多说了,这个是最基本的),需要注意的时候每次buffer的数据,在用outputstream写入的时候,最好flush一下,将缓冲区清空下接下来,执行一个没有where条件的SQL,会不会将内存撑爆?是的,这个问题我们值得去思考下,通过API发现可以对SQL进行一些 *** 作,例如,通过:PreparedStatementstatement=connection.prepareStatement(sql),这是默认得到的预编译,还可以通过设置:PreparedStatementstatement=connection.prepareStatement(sql,ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY)来设置游标的方式,以至于游标不是将数据直接cache到本地内存,然后通过设置statement.setFetchSize(200)设置游标每次遍历的大小OK,这个其实我用过,oracle用了和没用没区别,因为oracle的jdbcAPI默认就是不会将数据cache到java的内存中的,而mysql里头设置根本无效,我上面说了一堆废话,呵呵,我只是想说,java提供的标准API也未必有效,很多时候要看厂商的实现机制,还有这个设置是很多网上说有效的,但是这纯属抄袭对于oracle上面说了不用关心,他本身就不是cache到内存,所以java内存不会导致什么问题,如果是mysql,首先必须使用5以上的版本,然后在连接参数上加上useCursorFetch=true这个参数,至于游标大小可以通过连接参数上加上:defaultFetchSize=1000来设置,例如:jdbc:mysql://xxx.xxx.xxx.xxx:3306/abc?zeroDateTimeconvertToNull&useCursorFetch=true&defaultFetchSize=1000上次被这个问题纠结了很久(mysql的数据老导致程序内存膨胀,并行2个直接系统就宕了),还去看了很多源码才发现奇迹竟然在这里,最后经过mysql文档的确认,然后进行测试,并行多个,而且数据量都是500W以上的,都不会导致内存膨胀,GC一切正常,这个问题终于完结了。我们再聊聊其他的,数据拆分和合并,当数据文件多的时候我们想合并,当文件太大想要拆分,合并和拆分的过程也会遇到类似的问题,还好,这个在我们可控制的范围内,如果文件中的数据最终是可以组织的,那么在拆分和合并的时候,此时就不要按照数据逻辑行数来做了,因为行数最终你需要解释数据本身来判定,但是只是做拆分是没有必要的,你需要的是做二进制处理,在这个二进制处理过程,你要注意了,和平时read文件不要使用一样的方式,平时大多对一个文件读取只是用一次read *** 作,如果对于大文件内存肯定直接挂掉了,不用多说,你此时因该每次读取一个可控范围的数据,read方法提供了重载的offset和length的范围,这个在循环过程中自己可以计算出来,写入大文件和上面一样,不要读取到一定程序就要通过写入流flush到磁盘其实对于小数据量的处理在现代的NIO技术的中也有用到,例如多个终端同时请求一个大文件下载,例如视频下载吧,在常规的情况下,如果用java的容器来处理,一般会发生两种情况:其一为内存溢出,因为每个请求都要加载一个文件大小的内存甚至于,因为java包装的时候会产生很多其他的内存开销,如果使用二进制会产生得少一些,而且在经过输入输出流的过程中还会经历几次内存拷贝,当然如果有你类似nginx之类的中间件,那么你可以通过send_file模式发送出去,但是如果你要用程序来处理的时候,内存除非你足够大,但是java内存再大也会有GC的时候,如果你内存真的很大,GC的时候死定了,当然这个地方也可以考虑自己通过直接内存的调用和释放来实现,不过要求剩余的物理内存也足够大才行,那么足够大是多大呢?这个不好说,要看文件本身的大小和访问的频率其二为假如内存足够大,无限制大,那么此时的限制就是线程,传统的IO模型是线程是一个请求一个线程,这个线程从主线程从线程池中分配后,就开始工作,经过你的Context包装、Filter、拦截器、业务代码各个层次和业务逻辑、访问数据库、访问文件、渲染结果等等,其实整个过程线程都是被挂住的,所以这部分资源非常有限,而且如果是大文件 *** 作是属于IO密集型的 *** 作,大量的CPU时间是空余的,方法最直接当然是增加线程数来控制,当然内存足够大也有足够的空间来申请线程池,不过一般来讲一个进程的线程池一般会受到限制也不建议太多的,而在有限的系统资源下,要提高性能,我们开始有了newIO技术,也就是NIO技术,新版的里面又有了AIO技术,NIO只能算是异步IO,但是在中间读写过程仍然是阻塞的(也就是在真正的读写过程,但是不会去关心中途的响应),还未做到真正的异步IO,在监听connect的时候他是不需要很多线程参与的,有单独的线程去处理,连接也又传统的socket变成了selector,对于不需要进行数据处理的是无需分配线程处理的而AIO通过了一种所谓的回调注册来完成,当然还需要OS的支持,当会掉的时候会去分配线程,目前还不是很成熟,性能最多和NIO吃平,不过随着技术发展,AIO必然会超越NIO,目前谷歌V8虚拟机引擎所驱动的node.js就是类似的模式,有关这种技术不是本文的说明重点将上面两者结合起来就是要解决大文件,还要并行度,最土的方法是将文件每次请求的大小降低到一定程度,如8K(这个大小是经过测试后网络传输较为适宜的大小,本地读取文件并不需要这么小),如果再做深入一些,可以做一定程度的cache,将多个请求的一样的文件,cache在内存或分布式缓存中,你不用将整个文件cache在内存中,将近期使用的cache几秒左右即可,或你可以采用一些热点的算法来配合类似迅雷下载的断点传送中(不过迅雷的网络协议不太一样),它在处理下载数据的时候未必是连续的,只要最终能合并即可,在服务器端可以反过来,谁正好需要这块的数据,就给它就可以才用NIO后,可以支持很大的连接和并发,本地通过NIO做socket连接测试,100个终端同时请求一个线程的服务器,正常的WEB应用是第一个文件没有发送完成,第二个请求要么等待,要么超时,要么直接拒绝得不到连接,改成NIO后此时100个请求都能连接上服务器端,服务端只需要1个线程来处理数据就可以,将很多数据传递给这些连接请求资源,每次读取一部分数据传递出去,不过可以计算的是,在总体长连接传输过程中总体效率并不会提升,只是相对相应和所开销的内存得到量化控制,这就是技术的魅力,也许不要太多的算法,不过你得懂他。类似的数据处理还有很多,有些时候还会将就效率问题,比如在HBase的文件拆分和合并过程中,要不影响线上业务是比较难的事情,很多问题值得我们去研究场景,因为不同的场景有不同的方法去解决,但是大同小异,明白思想和方法,明白内存和体系架构,明白你所面临的是沈阳的场景,只是细节上改变可以带来惊人的效果。

宕机

SQL语句

太复杂可能会过多的消耗CPU资源,也可能由于语句中的

子查询

多,并且数据量又非常大,查询逻辑不合理,导致内存消耗过大

这些都可以引起

数据库服务器

宕机

数据库2个表,各20W数据库左右,每秒

联合查询

3-10次

服务器:

小型机

,4G内存,12个CPU

由于查询语句复杂不合理,系统运行3天就宕机

结果服务器上的6个数据服务都优化SQL语句,现在小型机运行正常

oracle存储过程报937错误的处理办法如下:

(一)Oracle 存储过程异常处理

1、异常的优点

使用异常,可以方便处理错误,而且异常处理程序与正常的事务逻辑分开,提高了可读性,如

BEGIN

SELECT ...

SELECT ...

SELECT ...

...

EXCEPTION

WHEN NO_DATA_FOUND THEN -- catches all ’no data found’ errors

2、异常的分类

有两种类型的异常,一种为内部异常,一种为用户自定义异常.

内部异常是执行期间返回到PL/SQL块的ORACLE错误或由PL/SQL代码的某 *** 作引起的错误,如除数为零或内存溢出的情况。用户自定义异常由开发者显示定义,在PL/SQL块中传递信息以控制对于应用的错误处理。

每当PL/SQL违背了ORACLE原则或超越了系统依赖的原则就会隐式的产生内部异常。因为每个ORACLE错误都有一个号码并且在PL/SQL中异常通过名字处理,ORACLE提供了预定义的内部异常。如SELECT INTO 语句不返回行时产生的ORACLE异常NO_DATA_FOUND。对于预定义异常,现将最常用的异常列举如下:

exception  oracle error  sqlcode value  condition

no_data_found  ora-01403  +100  select into 语句没有符合条件的记录返回

too_many_rows  ora-01422  -1422  select into 语句符合条件的记录有多条返回

dup_val_on_index  ora-00001  -1  对于数据库表中的某一列,该列已经被限制为唯一索引,程序试图存储两个重复的值

value_error  ora-06502  -6502  在转换字符类型,截取或长度受限时,会发生该异常,如一个字符分配给一个变量,而该变量声明的长度比该字符短,就会引发该异常

storage_error  ora-06500  -6500  内存溢出

zero_divide  ora-01476  -1476  除数为零

case_not_found  ora-06592  -6530  对于选择case语句,没有与之相匹配的条件,同时,也没有else语句捕获其他的条件

cursor_already_open  ora-06511  -6511  程序试图打开一个已经打开的游标

timeout_on_resource  ora-00051  -51  系统在等待某一资源,时间超时

如果要处理未命名的内部异常,必须使用OTHERS异常处理器或PRAGMA EXCEPTION_INIT。PRAGMA由编译器控制,或者是对于编译器的注释。PRAGMA在编译时处理,而不是在运行时处理。EXCEPTION_INIT告诉编译器将异常名与ORACLE错误码结合起来,这样可以通过名字引用任意的内部异常,并且可以通过名字为异常编写一适当的异常处理器。

在子程序中使用EXCEPTION_INIT的语法如下:

PRAGMA EXCEPTION_INIT(exception_name, -Oracle_error_number)

在该语法中,异常名是声明的异常,下例是其用法:

DECLARE

deadlock_detected EXCEPTION

PRAGMA EXCEPTION_INIT(deadlock_detected, -60)

BEGIN

... -- Some operation that causes an ORA-00060 error

EXCEPTION

WHEN deadlock_detected THEN

-- handle the error

END

对于用户自定义异常,只能在PL/SQL块中的声明部分声明异常,异常的名字由EXCEPTION关键字引入:

reserved_loaned Exception

产生异常后,控制传给了子程序的异常部分,将异常转向各自异常控制块,必须在代码中使用如下的结构处理错误:

Exception

When exception1 then

Sequence of statements

When exception2 then

Sequence of statements

When others then

3、异常的抛出

由三种方式抛出异常

1. 通过PL/SQL运行时引擎

2. 使用RAISE语句

3. 调用RAISE_APPLICATION_ERROR存储过程

当数据库或PL/SQL在运行时发生错误时,一个异常被PL/SQL运行时引擎自动抛出。

异常也可以通过RAISE语句抛出

RAISE exception_name

显式抛出异常是程序员处理声明的异常的习惯用法,但RAISE不限于声明了的异常,它可以抛出任何任何异常。例如,你希望用TIMEOUT_ON_RESOURCE错误检测新的运行时异常处理器,你只需简单的在程序中使用下面的语句:

RAISE TIMEOUT_ON_RESOUCE

比如下面一个订单输入的例子,若当订单小于库存数量,则抛出异常,并且捕获该异常,处理异常

DECLARE

inventory_too_low EXCEPTION

---其他声明语句

BEGIN

IF order_rec.qty>inventory_rec.qty THEN

RAISE inventory_too_low

END IF

EXCEPTION

WHEN inventory_too_low THEN

order_rec.staus:='backordered'

END

RAISE_APPLICATION_ERROR内建函数用于抛出一个异常并给异常赋予一个错误号以及错误信息。自定义异常的缺省错误号是+1,缺省信息是User_Defined_Exception。RAISE_APPLICATION_ERROR函数能够在pl/sql程序块的执行部分和异常部分调用,显式抛出带特殊错误号的命名异常。  Raise_application_error(error_number,message[,true,false]))

错误号的范围是-20,000到-20,999。错误信息是文本字符串,最多为2048字节。TRUE和FALSE表示是添加(TRUE)进错误堆(ERROR STACK)还是覆盖(overwrite)错误堆(FALSE)。缺省情况下是FALSE。

如下代码所示:

IF product_not_found THEN

RAISE_APPLICATION_ERROR(-20123,'Invald product code' TRUE)

END IF

4、异常的处理

PL/SQL程序块的异常部分包含了程序处理错误的代码,当异常被抛出时,一个异常陷阱就自动发生,程序控制离开执行部分转入异常部分,一旦程序进入异常部分就不能再回到同一块的执行部分。下面是异常部分的一般语法:

EXCEPTION

WHEN exception_name THEN

Code for handing exception_name

[WHEN another_exception THEN

Code for handing another_exception]

[WHEN others THEN

code for handing any other exception.]

用户必须在独立的WHEN子串中为每个异常设计异常处理代码,WHEN OTHERS子串必须放置在最后面作为缺省处理器处理没有显式处理的异常。当异常发生时,控制转到异常部分,ORACLE查找当前异常相应的WHEN..THEN语句,捕捉异常,THEN之后的代码被执行,如果错误陷阱代码只是退出相应的嵌套块,那么程序将继续执行内部块END后面的语句。如果没有找到相应的异常陷阱,那么将执行WHEN OTHERS。在异常部分WHEN 子串没有数量限制。

EXCEPTION

WHEN inventory_too_low THEN

order_rec.staus:='backordered'

replenish_inventory(inventory_nbr=>

inventory_rec.sku,min_amount=>order_rec.qty-inventory_rec.qty)

WHEN discontinued_item THEN

--code for discontinued_item processing

WHEN zero_divide THEN

--code for zero_divide

WHEN OTHERS THEN

--code for any other exception

END

当异常抛出后,控制无条件转到异常部分,这就意味着控制不能回到异常发生的位置,当异常被处理和解决后,控制返回到上一层执行部分的下一条语句。

BEGIN

DECLARE

bad_credit exception

BEGIN

RAISE bad_credit

--发生异常,控制转向;

EXCEPTION

WHEN bad_credit THEN

dbms_output.put_line('bad_credit')

END

--bad_credit异常处理后,控制转到这里

EXCEPTION

WHEN OTHERS THEN

--控制不会从bad_credit异常转到这里

--因为bad_credit已被处理

END

当异常发生时,在块的内部没有该异常处理器时,控制将转到或传播到上一层块的异常处理部分。

BEGIN

DECLARE ---内部块开始

bad_credit exception

BEGIN

RAISE bad_credit

--发生异常,控制转向;

EXCEPTION

WHEN ZERO_DIVIDE THEN --不能处理bad_credite异常

dbms_output.put_line('divide by zero error')

END --结束内部块

--控制不能到达这里,因为异常没有解决;

--异常部分

EXCEPTION

WHEN OTHERS THEN

--由于bad_credit没有解决,控制将转到这里

END

5、异常的传播

没有处理的异常将沿检测异常调用程序传播到外面,当异常被处理并解决或到达程序最外层传播停止。在声明部分抛出的异常将控制转到上一层的异常部分。

BEGIN

executable statements

BEGIN

today DATE:='SYADATE'--ERRROR

BEGIN --内部块开始

dbms_output.put_line('this line will not execute')

EXCEPTION

WHEN OTHERS THEN

--异常不会在这里处理

END--内部块结束

EXCEPTION

WHEN OTHERS THEN

处理异常

END

(二)网上的解决方法是

set serveroutput on size 100000 (相当于把缓存设置大一点),但是我执行时候报错 ORA-00922: missing or invalid option,之后还是修改了自己的语句,既然是输出过多导致,我就将数据语句放在循环外面,这样只要输出语句小于缓存就可以了。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/10016005.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-04
下一篇 2023-05-04

发表评论

登录后才能评论

评论列表(0条)

保存