2017年,行走乌孙古道

在大自然面前,我们总是显得如此渺小。
在城里待久了,总想着出去走一走,大部分人都会选择休闲游,这样可以放松一下心情。而我,稍微奇葩点,选择了徒步。计划这次徒步,记得最早是去年就提出过,当时也没有那种出去的劲,就一直延后了。徒步乌孙古道并不是因为天堂湖的美(其实压根不知道它是那么美),也不是想证明自己去过这里,更不想证明自己体力如何如何……,而是想感受一次当年古人行走这条古道的过程(别怪我装逼哈)。这次我们依然选择重装,所有的物资都由自己背着走,吃的、穿的、住的、防风防雨、淌河的等等。可以说,这是一次非常虐的旅行,从计划开始,查阅各种资料,发现前人行走是如何虐、难、险,但我们无所畏惧,坚持到底,最终走下来。

乌孙古道,北衔准噶尔盆地,南控塔里木绿洲,是贯通天山南北的咽喉,历史上许多游牧民族都要争夺这块宝地。公元前的汉武帝为了与乌孙结好而对抗匈奴;隋唐时期西突厥控制天山统治塔里木盆地;唐代西征突厥及与突骑施的交好等,都是通过乌孙古道来实现的,可以说,能走一次是做么的荣幸?

这次徒步最终由8个人参加,虽然中途有人退出,有人后补,没去的我们帮你们体验,去了的我们坚持到底。人生总是人来人往的,此次非常荣幸可以与你们同行:(自由光线、豆包、大峰、及其、顽童、Lynn、行健、我)。

自由光线是我们的领队,领队一般都是一个比较难做的角色,除了要计划这一次的行程,还要查阅大很多很多资料,考虑很多的细节。更重要的是,还要协调队员与队员之间的“距离”,所以如果你们出去,一定要好好善待你们的领队。行健是我们的财务,负责经费开支,财务记账,联系包车、购买公共物资、气罐等都是由他去完成,他体力很好,而且是非常称职的财务。及其是我的帐友,非常好的一个基友,他表面上跟你开玩笑,但是很多事情都是为别人着想的,非常高兴认识你。大峰是我们的先锋,体力强到分分钟甩我几条街;如果你看到这里,你是不是感到无比自豪????拜托,下次别把我甩那么远,你大爷的,你知不知道过垭口后的两天,追你追到我小腿疼?出山后搞到我小腿痛的走不了路。豆包是之前徒步洛克线的队友,胖胖的身材,体重170斤,水也冲不走。顽童跟Lynn是情侣,这样要祝福他们,早点结婚生子。因为他们居然在天堂湖拍婚纱照,更重要的是他们坚持走下来,过程不容易,就好比以后的婚姻生活,希望你们一直可以像这一次徒步一样,互相帮助,坚持到底。说到我呢,我就吹吹牛逼好了,反正体力比不上那几个,但是拍点风景还是可以的。

由于今年户外界经常出事,政府基本不让进山,这一次也一样。原本计划从拜城县黑英山口进山,反穿温泉线,但是最终被政府阻拦而改变计划,当我出山时,我觉得不让进,是非常有道理的,水太急、太深了,根本就过不去。后来改了线路,正面穿越温泉线,但是政府早早就在路口设立关卡,根本不让你进去。但是我们不甘心,当然我们也不会冒险,我们都有一个度,当超过了,我们肯定下撤,这是我们的基本原则,所以奉告各地的户外徒步爱好着,一定要量力而行。我们是趁工作人员不注意直接冲进去的,当然,检查站右边有一座小山坡,如果实在没办法,也可以从小山坡爬过去,反正我是这样进去的。

Java进程VIRT虚拟内存

1. 现象

最近发现线上机器 java 8 进程的 VIRT 虚拟内存使用达到了 50G+,如下图所示:

1501129525-9952-20160804105700403-632411952

2. 不管用的 -Xmx

首先第一想到的当然使用 java 的 -Xmx 去限制堆的使用。但是无论怎样设置,都没有什么效果。没办法,只好开始苦逼的研究。

3. 什么是 VIRT

现代操作系统里面分配虚拟地址空间操作不同于分配物理内存。在64位操作系统上,可用的最大虚拟地址空间有16EB,即大概180亿GB。那么在一台只有16G的物理内存的机器上,我也能要求获得4TB的地址空间以备将来使用。例如:

    void *mem = mmap(0, 4ul * 1024ul * 1024ul * 1024ul * 1024ul,
                     PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE,
                     -1, 0);
当使用 mmap 并设置 MAP_NORESERVE 标志时,并不会要求实际的物理内存和swap空间存在。所以上述代码可以在top中看到使用了 4096g 的 VIRT 虚拟内存,这当然是不可能的,它只是表示使用了 4096GB 的地址空间而已。

4. 为什么会用这么多地址空间

那 Java 程序为什么会使用这么多的地址空间呢?使用“pmap -x”来查看一下:

00007ff638021000   65404       0       0 -----    [ anon ]
00007ff63c000000     132      36      36 rw---    [ anon ]
00007ff63c021000   65404       0       0 -----    [ anon ]
00007ff640000000     132      28      28 rw---    [ anon ]
00007ff640021000   65404       0       0 -----    [ anon ]
00007ff644000000     132       8       8 rw---    [ anon ]
00007ff644021000   65404       0       0 -----    [ anon ]
00007ff648000000     184     184     184 rw---    [ anon ]
00007ff64802e000   65352       0       0 -----    [ anon ]
00007ff64c000000     132     100     100 rw---    [ anon ]
00007ff64c021000   65404       0       0 -----    [ anon ]
00007ff650000000     132      56      56 rw---    [ anon ]
00007ff650021000   65404       0       0 -----    [ anon ]
00007ff654000000     132      16      16 rw---    [ anon ]
00007ff654021000   65404       0       0 -----    [ anon ]
发现有很多奇怪的64MB的内存映射,查资料发现这是 glibc 在版本 2.10 引入的 arena 新功能导致。CentOS 6/7 的 glibc 大都是 2.12/ 2.17 了,所以都会有这个问题。这个功能对每个线程都分配一个分配一个本地arena来加速多线程的执行。
在 glibc 的 arena.c 中使用的 mmap() 调用就和之前的示例代码类似:
    p2 = (char *)mmap(aligned_heap_area, HEAP_MAX_SIZE, PROT_NONE,
                          MAP_NORESERVE | MAP_ANONYMOUS | MAP_PRIVATE, -1, 0)
之后,只有很小的一部分地址被映射到了物理内存中:
    mprotect(p2, size, PROT_READ | PROT_WRITE)
因此在一个多线程程序中,会有相当多的 64MB 的 arena 被分配。这个可以用环境变量 MALLOC_ARENA_MAX 来控制。在64位系统中的默认值为 128。

5. Java 的特殊性

Java 程序由于自己维护堆的使用,导致调用 glibc 去管理内存的次数较少。更糟的是 Java 8 开始使用 metaspace 原空间取代永久代,而元空间是存放在操作系统本地内存中,那线程一多,每个线程都要使用一点元空间,每个线程都分配一个 arena,每个都64MB,就会导致巨大的虚拟地址被分配。

6. 结束语

总结一下:

  • VIRT高是因为分配了太多地址空间导致。
  • 一般来说不用太在意VIRT太高,因为你有16EB的空间可以使用。
  • 如果你实在需要控制VIRT的使用,设置环境变量MALLOC_ARENA_MAX,例如hadoop推荐值为4,因为YARN使用VIRT值监控资源使用。
 
Copyright © 2008-2021 lanxinbase.com Rights Reserved. | 粤ICP备14086738号-3 |