linux-kernel – Linux(非透明)每进程巨页会计

发布时间：2020-12-13 17:01:05 所属栏目：Linux 来源：网络整理

导读：我最近转换了一些 java应用程序来运行linux手动配置的大页面,如 here所述.我指出“手动配置”,因为它们不是 transparent hugepages,这给了我们一些 performance issues. 所以现在,我已经有大约10个运行在系统上的tomcats,我很想知道每个人使用多少内存. 我可

我最近转换了一些 java应用程序来运行linux手动配置的大页面,如 here所述.我指出“手动配置”,因为它们不是 transparent hugepages,这给了我们一些 performance issues.

所以现在,我已经有大约10个运行在系统上的tomcats,我很想知道每个人使用多少内存.

我可以从Linux Huge Pages Usage Accounting中描述的/ proc / meminfo中获取摘要信息.

但我找不到任何工具来告诉我每个进程的实际大页面使用情况.

我在/ proc / pid / numa_stat中搜索过,发现了一些有趣的信息,这些信息让我对这种情况感兴趣：

function pshugepage () {
    HUGEPAGECOUNT=0
    for num in `grep 'anon_hugepage.*dirty=' /proc/$@/numa_maps | awk '{print $6}' | sed 's/dirty=//'` ; do
        HUGEPAGECOUNT=$((HUGEPAGECOUNT+num))
    done
    echo process $@ using $HUGEPAGECOUNT huge pages
}

或者,在perl中：

sub counthugepages {
    my $pid=$_[0];
    open (NUMAMAPS,"/proc/$pid/numa_maps") || die "can't open numa_maps";
    my $HUGEPAGECOUNT=0;
    while (my $line=<NUMAMAPS>) {
        next unless ($line =~ m{ huge }) ;
        next unless ($line =~ m{dirty=});
        chomp $line;
        $line =~ s{.*dirty=}{};
        $line =~ s{s.*$}{};
        $HUGEPAGECOUNT+=$line;
    }
    close NUMAMAPS;
    # we want megabytes out,but we counted 2-megabyte hugepages
    return ($HUGEPAGECOUNT*2);
}

它给我的数字似乎是合理的,但我对这种方法是正确的还是很有信心.

环境是四CPU戴尔,64GB内存,RHEL6.3,oracle jdk 1.7.x(当前截至20130728)

解决方法

更新： Red Hat now recommends this method用于RHEL5 / 6上的流程巨额会计：

grep -B 11 'KernelPageSize:     2048 kB' /proc/[PID]/smaps 
   | grep "^Size:" 
   | awk 'BEGIN{sum=0}{sum+=$2}END{print sum/1024}'

我在procps-ng开发者的邮件列表上问了这个问题.有人告诉我：

The hugepage support has been introduced in the procps-ng/pmap tool
several months ago (switches -XX,-C,-c,-N,-n should allow you to
configure and display any entries supported by the running kernel).

我在fedora 19上用procps-3.3.8进行了一些实验.我不认为它给了我任何我从我在问题中建议的东西中得不到的信息,但至少它具有权威的光环.

FWIW我最终得到以下结果：

.pmaprc文件包含：

[Fields Display]
Size
Rss
Pss
Referenced
AnonHugePages
KernelPageSize
Mapping

[Mapping]
ShowPath

然后我使用以下命令来提取巨页信息：

pmap -c [process id here] | egrep 'Add|2048'

在grep中,“添加”用于标题行. “2048”将获取内核页面大小为2048的任何内容,即大页面.它也会抓住不相关的东西.

这是一些示例输出：

Address    Size   Rss   Pss Referenced AnonHugePages KernelPageSize Mapping
    ed800000   22528     0     0          0             0           2048 /anon_hugepage (deleted)
    f7e00000   88064     0     0          0             0           2048 /anon_hugepage (deleted)
    fd400000   45056     0     0          0             0           2048 /anon_hugepage (deleted)
7f3753dff000    2052  2048  2048       2048          2048              4 [stack:1674]
7f3759000000    4096     0     0          0             0           2048 /anon_hugepage (deleted)
7f3762d68000    2048     0     0          0             0              4 /usr/lib64/libc-2.17.so
7f376339b000    2048     0     0          0             0              4 /usr/lib64/libpthread-2.17.so

我们只关心kernelPageSize 2048的行.

我想它告诉我,我已经在大页面中分配了159744 Kbytes(22528 88064 45056 4096)的RAM.我告诉java使用128M的堆,它有一些其他的内存池,所以这是一个合理的数字. Rss&引用0没有多大意义,但测试java程序非常简单,所以它也是合理的.

它与我从上面的perl片段获得的数字不一致,因为perl只搜索“脏”页面 – 实际使用过的页面.和/或因为perl是错的,我不知道.

我还在RHEL6机器上尝试了procps 3.3.9,其中一些活动的tomcats使用了大量的页面内存. Rss&引用的列都是0.这可能是内核的错,而不是procps,我不知道.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!