Nodejs通过Thrift操作hbase卡住原因分析及与javascript的垃圾回收机制的关系

在最近使用Nodejs通过Thrift操作hbase的时候写了个脚本,不断发送http请求,从而取得hbase下所需的数据,但是在run的过程中for循环并没有执行完全,在执行一部分后会卡住,就再也进不到hbase下取数据,出现socket hang up的错误,查了很多资料也没解决。当时认为是hbase的并发数问题,其并发数的限制导致了资源负载的极限,后来不断测试找到原因所在,其实与hbase处理并发的能力无关,真正的原因是jsvascript的垃圾回收机制使得资源使用达到瓶颈,下面是代码处理前与处理后的对比:

 1 var thrift = require(‘thrift‘),
 2     HBase = require(‘./gen-nodejs/Hbase.js‘),
 3     HBaseTypes = require(‘./gen-nodejs/Hbase_types.js‘),
 4     connection = thrift.createConnection(‘localhost‘, 9090, {
 5         transport: thrift.TFramedTransport,
 6         protocol: thrift.TBinaryProtocol
 7     });
 8
 9 var client = thrift.createClient(HBase,connection);
10
11 /*router.get(‘/‘, function(req, res)
12 {
13
14   res.render(‘index‘, { title: ‘Welcome‘ });
15
16 });*/
17
18 router.get(‘/search‘, function(req, res)
19 {
20
21     var dateTimeArray = {};
22     var valueArray = {};
23     var searchPlateBegin = null;
24     var searchPlateEnd = null;
25     var searchDetailsBegin = null;
26     var searchDetailsEnd = null;
27     var convertReverseArray = new Array();
28 }
 1 /*router.get(‘/‘, function(req, res)
 2 {
 3
 4   res.render(‘index‘, { title: ‘Welcome‘ });
 5
 6 });*/
 7
 8 router.get(‘/search‘, function(req, res)
 9 {
10
11     var dateTimeArray = {};
12     var valueArray = {};
13     var searchPlateBegin = null;
14     var searchPlateEnd = null;
15     var searchDetailsBegin = null;
16     var searchDetailsEnd = null;
17     var convertReverseArray = new Array();
18
19      var thrift = require(‘thrift‘),
20     HBase = require(‘./gen-nodejs/Hbase.js‘),
21     HBaseTypes = require(‘./gen-nodejs/Hbase_types.js‘),
22     connection = thrift.createConnection(‘localhost‘, 9090, {
23         transport: thrift.TFramedTransport,
24         protocol: thrift.TBinaryProtocol
25     });
26
27 var client = thrift.createClient(HBase,connection);
28 }

两段代码的唯一区别就是thrift连接hbase的几行代码是否放在了路由search下,在运行的脚本之中不断地请求该路由这就是原因所在,由于不断请求,每请求一次都会进行一次thrift连接hbase,那段代码看似很简单,其实背后的运行很复杂,包括hbase中库的添加,结构组织,内存的分配等等,这样循环下去就创建了非常多的thrift对象,由于JavaScript垃圾回收机制的延时性不可能都进行回收,这样方法对象的不断增多就会造成thrift从hbase中请求数据的阻塞,就像我们看到的那样,卡在了那里。

下面来说一下javascript的回收机制:

现在各大浏览器通常用采用的垃圾回收有两种方法:标记清除、引用计数。

1.标记清除:

这是JavaScript最常见的垃圾回收方式,当变量进入执行环境的时候,比如函数中声明一个变量,垃圾回收器将其标记为“进入环境”,当变量离开环境的时候(函数执行结束)将其标记为“离开环境”。至于怎么标记有很多种方式,比如特殊位的反转、维护一个列表等,这些并不重要,重要的是使用什么策略,原则上讲不能够释放进入环境的变量所占的内存,它们随时可能会被调用的到。

垃圾回收器会在运行的时候给存储在内存中的所有变量加上标记,然后去掉环境中的变量以及被环境中变量所引用的变量(闭包),在这些完成之后仍存在标记的就是要删除的变量了,因为环境中的变量已经无法访问到这些变量了,然后垃圾回收器相会这些带有标记的变量机器所占空间。

2.引用计数:

另一种不太常见的垃圾回收策略是引用计数。引用计数的含义是跟踪记录每个值被引用的次数。当声明了一个变量并将一个引用类型赋值给该变量时,则这个值的引用次数就是1。相反,如果包含对这个值引用的变量又取得了另外一个值,则这个值的引用次数就减1。当这个引用次数变成0时,则说明没有办法再访问这个值了,因而就可以将其所占的内存空间给收回来。这样,垃圾收集器下次再运行时,它就会释放那些引用次数为0的值所占的内存。

比如对象A有一个属性指向对象B,而对象B也有有一个属性指向对象A,这样相互引用

function test(){
            var a={};
            var b={};
            a.prop=b;
            b.prop=a;
        }

这样a和b的引用次数都是2,即使在test()执行完成后,两个对象都已经离开环境,在标记清除的策略下是没有问题的,离开环境的就被清除,但是在引用计数策略下不行,因为这两个对象的引用次数仍然是2,不会变成0,所以其占用空间不会被清理,如果这个函数被多次调用,这样就会不断地有空间不会被回收,造成内存泄露。

减少JavaScript中的垃圾回收:

1.数组Array优化:

将[]赋值给一个数组对象,是清空数组的捷径(例如: arr = [];),但是需要注意的是,这种方式又创建了一个新的空对象,并且将原来的数组对象变成了一小片内存垃圾!实际上,将数组长度赋值为0(arr.length = 0)也能达到清空数组的目的,并且同时能实现数组重用,减少内存垃圾的产生。

2.函数function优化:

方法一般都是在初始化的时候创建,并且此后很少在运行时进行动态内存分配,这就使得导致内存垃圾产生的方法,找起来就不是那么容易了。但是从另一角度来说,这更便于我们寻找了,因为只要是动态创建方法的地方,就有可能产生内存垃圾。

setTimeout(
    (function(self) {
      return function () {
              self.tick();
    };
})(this), 16)

每过16毫秒调用一次this.tick(),嗯,乍一看似乎没什么问题,但是仔细一琢磨,每一次调用都返回了一个新的方法对象,这就导致了大量的方法对象垃圾!

可以将作为返回值的方法保存起来,例如:

this.tickFunc = (
    function(self) {
      return function() {
                self.tick();
      };
    }
)(this);

// in the tick() function
setTimeout(this.tickFunc, 16);

相比于每次都新建一个方法对象,这种方式在每一帧当中重用了相同的方法对象。这种方式的优势是显而易见的,而这种思想也可以应用在任何以方法为返回值或者在运行时创建方法的情况当中。

时间: 2024-11-04 12:33:35

Nodejs通过Thrift操作hbase卡住原因分析及与javascript的垃圾回收机制的关系的相关文章

java中存在垃圾回收机制,但是还会有内存泄漏的问题,原因是

答案是肯定的,但不能拿这一句回答面试官的问题.分析:JAVA是支持垃圾回收机制的,在这样的一个背景下,内存泄露又被称为"无意识的对象保持".如果一个对象引用被无意识地保留下来,那么垃圾回收器不仅不会处理这个对象,而且也不处理被这个对象引用的其它对象."内存泄露"就是内存中某些内存不可被回收. 举个例子:如果对一个栈(Stack类)先是进行入栈操作,之后再进行出栈操作,那么弹出来的对象将不会被当做垃圾回收,即使使用栈的客户程序不再引用这些对象,因为栈内部存在着对这些已

hbase之python利用thrift操作hbase数据和shell操作

前沿: 以前都是用mongodb的,但是量大了,mongodb显得不那么靠谱,改成hbase撑起一个量级. HBase是Apache Hadoop的数据库,能够对大型数据提供随机.实时的读写访问.HBase的目标是存储并处理大型的数据.HBase是一个开源的,分布式的,多版本的,面向列的存储模型.它存储的是松散型数据. HBase提供了丰富的访问接口. HBase Shell Java clietn API Jython.Groovy DSL.Scala REST Thrift(Ruby.Pyt

PHP通过Thrift操作Hbase

HBase是一个开源的NoSQL产品,它是实现了Google BigTable论文的一个开源产品,和Hadoop和HDFS一起,可用来存储和处理海量column family的数据.官方网址是:http://hbase.apache.org 一 .HBase访问接口 1.  Native Java API,最常规和高效的访问方式,适合Hadoop MapReduce Job并行批处理HBase表数据2.  HBase Shell,HBase的命令行工具,最简单的接口,适合HBase管理使用3. 

全面分析Java的垃圾回收机制1

引言 Java的堆是一个运行时数据区,类的实例(对象)从中分配空间.Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象,这些对象通过new.newarray.anewarray和multianewarray等指令建立,但是它们不需要程序代码来显式地释放.一般来说,堆的是由垃圾回收 来负责的,尽管JVM规范并不要求特殊的垃圾回收技术,甚至根本就不需要垃圾回收,但是由于内存的有限性,JVM在实现的时候都有一个由垃圾回收所管理的堆.垃圾回收是一种动态存储管理技术,它自动地释放不再被

全面分析Java的垃圾回收机制3

上面这个程序创建了许多Chair对象,而且在垃圾收集器开始运行后的某些时候,程序会停止创建Chair.由于垃圾收集器可能在任何时间运行,所以我们不能准确知道它在何时启动.因此,程序用一个名为gcrun的标记来指出垃圾收集器是否已经开始运行.利用第二个标记f,Chair可告诉main()它应停止对象的生成.这两个标记都是在finalize()内部设置的,它调用于垃圾收集期间.另两个static变量--created以及finalized--分别用于跟踪已创建的对象数量以及垃圾收集器已进行完收尾工作

全面分析Java的垃圾回收机制2

透视Java垃圾回收 1.命令行参数透视垃圾收集器的运行 2.使用System.gc()可以不管JVM使用的是哪一种垃圾回收的算法,都可以请求Java的垃圾回收.在命令行中有一个参数-verbosegc可以查看Java使用的堆内存的情况,它的格式如下: java -verbosegc classfile 可以看个例子: class TestGC  {  public static void main(String[] args)  {  new TestGC();  System.gc(); 

java中垃圾回收机制中的引用计数法和可达性分析法(最详细)

首先,我这是抄写过来的,写得真的很好很好,是我看过关于GC方面讲解最清楚明白的一篇.原文地址是:https://www.zhihu.com/question/21539353 原文地址:https://www.cnblogs.com/igoodful/p/8727241.html

关于JVM内存溢出的原因分析及解决方案探讨

前言:JVM中除了程序计数器,其他的区域都有可能会发生内存溢出. 0.什么是内存溢出 当程序需要申请内存的时候,由于没有足够的内存,此时就会抛出OutOfMemoryError,这就是内存溢出. 1.内存泄漏和内存溢出区别与联系 内存泄漏:系统分配的内存没有被回收. 内存溢出:分配的内存空间超过系统内存. 2.内存泄漏的原因分析   jvm由5大块组成:堆,栈,本地方法栈,程序计数器,方法区.栈它的主要记录方法的执行和对象的引用.堆则存在真正的引用的对象. 内存泄漏是由于使用不当,把一部分内存“

java.lang.OutOfMemoryError GC overhead limit exceeded原因分析及解决方案

最近一个上线运行良好的项目出现用户无法登录或者执行某个操作时,有卡顿现象.查看了日志,出现了大量的java.lang.OutOfMemoryError: GC overhead limit exceeded错误. oracle官方给出了这个错误产生的原因和解决方法: Exception in thread thread_name: java.lang.OutOfMemoryError: GC Overhead limit exceeded Cause: The detail message "G