序言
在一些数学显存为8g的server上,主要执行一个Java服务,系统显存分配比如以下:Java服务的JVM堆大小设置为6g,一个监控进程占用大概600m,Linux自身使用大概800m。
从表面上,数学显存应当是足够使用的;但实际执行的情况是,会发生大量使用SWAP(说明化学显存不够使用了)linux线程栈大小,比如以右图所见到的。同一时侯,由于SWAP和GC同一时侯发生会导致JVM严重卡顿。所以我们要追问:显存究竟去哪里了?
要剖析这个问题,理解JVM和操作系统之间的显存关系很重要。接出来主要就Linux与JVM之间的显存关系进行一些剖析。
一、Linux与进程显存模型
JVM以一个进程(Process)的身分执行在Linux系统上,了解Linux与进程的显存关系,是理解JVM与Linux显存的关系的基础。
右图给出了硬件、系统、进程三个层面的显存之间的概要关系。
从硬件上看,Linux系统的显存空间由两个部份构成:化学显存和SWAP(坐落c盘)。化学显存是Linux活动时使用的主要显存区域;当化学显存不够使用时,Linux会把一部份临时不用的显存数据放在c盘上的SWAP中去,便于腾出好多其它的可用显存空间;而当需要使用坐落SWAP的数据时,必须先将其换回到显存中。
从Linux系统上看,不仅引导系统的BIN区,整个显存空间主要被分成两个部份:内核显存(Kernelspace)、用户显存(Userspace)。
内核显存是Linux自身使用的显存空间,主要提供给程序调度、内存分配、连接硬件资源等程序逻辑使用。用户显存是提供给各个进程主要空间,Linux给各个进程提供同样的虚拟显存空间;这促使进程之间互相独立,互不干扰。实现的方式是採用虚拟显存技术:给每位进程一定虚拟显存空间,而仅仅有当虚拟显存实际被使用时,才分配化学显存。诸如以右图所见到的,对于32的Linux系统来说,通常将0~3G的虚拟显存空间分配做为用户空间,将3~4G的虚拟显存空间分配为内核空间;64位系统的界定情况是类似的。
从进程的角度来看,进程能直接訪问的用户显存(虚拟显存空间)被界定为5个部份:代码区、数据区、堆区、栈区、未使用区。
2、进程与JVM显存模型
JVM本质就是一个进程,因而其显存模型也有进程的通常特征。
但是,JVM又不是一个普通的进程。其在显存模型上有好多崭新的特征,主要缘由有两:
2.1、用户显存
非常指出JVM进程模型的代码区和数据区指的是JVM自身的,而非Java程序的。普通进程栈区,在JVM通常只用做线程栈。JVM的堆区和普通进程的区别是最大的linux 版本,以下具体具体说明:
最后是未使用区,未使用区是分配新显存空间的预备区域。对于普通进程来说,这个区域被可用于堆和栈空间的申请及释放,每次堆显存分配就会使用这个区域,因而大小变动频繁;对于JVM进程来说。调整堆大小及线程栈时会使用该区域,而堆大小通常较少调整。因而大小相对稳定。操作系统会动态调整这个区域的大小,但是这个区域一般并没有被分配实际的化学显存,仅仅是同意进程在这个区域申请堆或栈空间。2.2、内核显存
应用程序一般不直接和内核显存打交道。内核显存由操作系统进行管理和使用;只是随着Linux对性能的关注及改进,一些新的特点促使应用程序才能使用内核显存。或则是映射到内核空间。JavaNIO正是在这样的背景下诞生的,其充分借助了Linux系统的新特点,提高了Java程序的IO性能:
上图给出了JavaNIO使用的内核显存在linux系统中的分布情况。niobuffer主要包含:nio使用各类channel时所使用的ByteBuffer、Java程序主动使用ByteBuffer.allocateDirector申请分配的Buffer。而在PageCache上面。nio使用的显存主要包含:FileChannel.map形式打开文件占用mapped、FileChannel.transferTo和FileChannel.transferFrom所需要的Cache(图中标识niofile)。
通过JMX才能监控到NIOBuffer和mapped的使用情况,比如以右图所见到的。
只是,FileChannel的实现是通过系统调用使用原生的PageCache,过程对于Java是透明的,难以监控到这部份显存的使用大小
Linux和JavaNIO在内核显存上开辟空间给程序使用,主要是增加不要的复制,以减少IO操作系统调用的开支。例如,将c盘文件的数据发送网卡,使用普通方式和NIO时。数据流动比較右图所见到的:
将数据在内核显存和用户显存之间拷贝是比較消耗资源和时间的事情linux线程栈大小,而从上图我们能否看见。通过NIO的形式增加了2次内核显存和用户显存之间的数据拷贝。这是JavaNIO高性能的重要机制之中的一个(还有一个是异步非堵塞)。
从里面才能看出。内核显存对于Java程序性能也很重要,因而linux系统装win7,在界定系统显存使用时侯。一定要给内核留出一定可用空间。
3、案例剖析3.1、内存分配问题
通过前面的剖析。省略比較小的区域,才能总结JVM占用的显存:
JVM显存≈Java永久代+Java堆(新生代和老年代)+线程栈+JavaNIO
回到文章开头提出的问题。原先的显存分配是:6g(java堆)+600m(监控)+800m(系统)。剩余大概600m显存未分配。
现在剖析这600m显存的分配情况:
(1)Linux保留大概200m。这部份是Linux正常执行的需要,
(2)Java服务的线程数目是160个,JVM默认的线程栈大小是1m。因而使用160m显存,
(3)JavaNIObuffer,通过JMX查到最多占用了200m,
(4)Java服务使用NIO大量读写文件,需要使用PageCache,正如上面剖析,这个临时不好定量计算大小。
前三项加上去早已560m,因而才能判定Linux化学显存不够使用。
悉心的人会发觉,序言中给出两个server,一个SWAP最多占用了2.16g,另外一个SWAP最多占用了871m;而且。虽然我们的显存缺口没有这么大。虽然。这是由于SWAP和GC同一时侯进行导致的。从右图才能看见。SWAP的使用和长时间的GC在同一时刻发生
SWAP和GC同一时侯发生会造成GC时间十分长,JVM严重卡顿,极端的情况下会造成服务崩溃。缘由诸如以下:JVM进行GC时。时需要对对应堆分区的已用显存进行遍历;如果GC的时侯,有堆的一部份内容被交换到SWAP中,遍历到这部份的时侯就需要将其交换回显存,同一时侯由于显存空间不足。就需要把显存中堆的另外一部份换到SWAP中去。于是在遍历堆分区的过程中。(极端情况下)会把整个堆分区轮流往SWAP写一遍。Linux对SWAP的回收是滞后的。我们都会看见大量SWAP占用。
上述问题。才能通过增加堆大小,或则添加化学显存解决。
因而。我们得出一个推论:布署Java服务的Linux系统,在显存分配上。需要避开SWAP的使用。详尽如何分配需要综合考虑不同场景下JVM对Java永久代、Java堆(新生代和老年代)、线程栈、JavaNIO所使用显存的需求。
3.2、内存泄露
还有一个案例是,8g显存的server,Linux使用800m,监控进程使用600m,堆大小设置4g。系统可用显存有2.5g左右,而且也发生了大量的SWAP占用。
剖析这个问题比如以下:
(1)在这个场景中,Java永久代、Java堆(新生代和老年代)、线程栈所用显存基本是固定的,因而。占用显存过多的缘由就定位在JavaNIO上。
(2)根据上面的模型,JavaNIO使用的显存主要分布在Linux内核显存的System区和PageCache区。查看监控的记录,比如以右图,我们就能看见发生SWAP之前。也就是化学显存不够使用的时侯,PageCache随之缩小。因而,才能定位在System区的JavaNIOBuffer发生显存泄露。
(3)由于NIO的DirectByteBuffer需要在GC的后期被回收。因而连续申请DirectByteBuffer的程序,一般需要调用System.gc(),防止长时间不发生FullGC造成引用在old区的DirectByteBuffer显存泄露。
剖析到此,才能判定有两种可能的诱因:第一,Java程序没有在必要的时侯调用System.gc();第二,System.gc()被禁用。
(4)最后是要排查JVM启动參数和Java程序的DirectByteBuffer使用情况。在本例中,查看JVM启动參数。发觉启用了-XX:+DisableExplicitGC造成System.gc()被禁用。
四、总结
本文具体剖析了Linux与JVM的显存关系,比較了通常进程与JVM进程使用显存的优缺点,理解这种特点将对Linux系统显存分配、JVM调优、Java程序优化有帮助。限于篇幅关系只列出两个案例。希望起到抛砖引玉的作用。