对于JVM框架来说,内存管理都逃脱不了GC,但是当一个框架过于复杂,或者优化到达极限的时候,就会考虑JVM的GC机制是否符合当前的运行模式,Tungsten模块就是Spark发现利用JVM本身的内存管理机制。
无法高效的对内容进行管理,主要体现在:

Java对象空间开销大

以UTF-8编码的字符串abcd为例,仅存储字符串信息需要4 bytes,然而使用Java的String存储则需要48 bytes,使用jol打印出String的内部占用(参考Java Object Layout(jol) ),如:

1
2
3
4
5
6
OFFSET  SIZE     TYPE DESCRIPTION                       VALUE 
0 12 (object header) N/A
12 4 char[] String.value N/A
16 4 int String.hash N/A
20 4 int String.hash32 N/A
Instance size: 24 bytes

使用jol打印出abcd占用空间大小,如下:

1
2
3
4
5
java.lang.String@213214d1d footprint: 
COUNT AVG SUM DESCRIPTION
1 24 24 [C
1 24 24 java.lang.String
2 48 (total)

GC带来的时间开销

full gc会stop the world,增加程序耗时,甚至可能出现假死情况,并且这种情况没有日志输出,给问题排查带来一定难。

基于以上考虑,Tungsten项目优化内存的使用,使用off-heap方式管理内存,不再依赖JVM,避免了存储的额外开销及GC的影响,Tungsten主要工作包含以下三个方面:

  • Memory Management and Binary Processing: leveraging application semantics to manage memory explicitly and eliminate the overhead of JVM object model and garbage collection。
  • Cache-aware computation: algorithms and data structures to exploit memory hierarchy。
  • Code generation: using code generation to exploit modern compilers and CPUs。

解释如下:

  • Memory Management and Binary Processing: off-heap管理内存,降低对象的开销和消除JVM GC带来的延时。
  • Cache-aware computation: 优化存储,提升CPU L1/ L2/L3缓存命中率。
  • Code generation: 优化Spark SQL的代码生成部分,提升CPU利用率。

Tungsten设计了一套内存管理机制,而不再是交给JVM托管,Spark的operation直接使用分配的binary data而不是JVM objects。


扫码手机观看或分享: