linux 内存耗尽的分析

在测试NAS性能,用fstest长时间写,分析性能变差的原因,发现server主机内存使用率很高。

1.首先查看内存

# top -M
 top - 14:43:12 up 14 days, 6 min,  1 user,  load average: 8.36, 8.38, 8.41
 Tasks: 419 total,   1 running, 418 sleeping,   0 stopped,   0 zombie
 Cpu(s):  0.0%us,  0.2%sy,  0.0%ni, 99.0%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:    63.050G total,   62.639G used,  420.973M free,   33.973M buffers
 Swap: 4095.996M total,    0.000k used, 4095.996M free,   48.889G cached
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   111 root      20   0     0    0    0 S  2.0  0.0   0:25.52 ksoftirqd/11
  5968 root      20   0 15352 1372  828 R  2.0  0.0   0:00.01 top
 13273 root      20   0     0    0    0 D  2.0  0.0  25:54.02 nfsd
 17765 root       0 -20     0    0    0 S  2.0  0.0   0:11.89 kworker/5:1H
     1 root      20   0 19416 1436 1136 S  0.0  0.0   0:01.88 init
 .....

发现内存基本用完,究竟是什么进程占用?top命令发现排名第一的%MEM才零点几。

2.通过 vmstat -m命令查看内核空间的内存使用。

# vmstat -m
 Cache                       Num  Total   Size  Pages
 xfs_dqtrx                     0      0    384     10
 xfs_dquot                     0      0    504      7
 xfs_buf                   91425 213300    384     10
 fstrm_item                    0      0     24    144
 xfs_mru_cache_elem            0      0     32    112

xfs_ili                  7564110 8351947    224     17
 xfs_inode                7564205 8484180   1024      4
 xfs_efi_item                257    390    400     10
 xfs_efd_item                237    380    400     10
 xfs_buf_item               1795   2414    232     17
 xfs_log_item_desc           830   1456     32    112
 xfs_trans                   377    490    280     14
 xfs_ifork                     0      0     64     59
 xfs_da_state                  0      0    488      8
 xfs_btree_cur               342    437    208     19
 xfs_bmap_free_item           89    288     24    144
 xfs_log_ticket              717    966    184     21
 xfs_ioend                   726    896    120     32
 rbd_segment_name            109    148    104     37
 rbd_obj_request            1054   1452    176     22
 rbd_img_request            1037   1472    120     32
 ceph_osd_request            548    693    872      9
 ceph_msg_data              1041   1540     48     77
 ceph_msg                   1197   1632    232     17
 nfsd_drc                  19323  33456    112     34
 nfsd4_delegations             0      0    368     10
 nfsd4_stateids              855   1024    120     32
 nfsd4_files                 802   1050    128     30
 nfsd4_lockowners              0      0    384     10
 nfsd4_openowners             15     50    392     10
 rpc_inode_cache              27     30    640      6
 rpc_buffers                   8      8   2048      2
 rpc_tasks                     8     15    256     15
 fib6_nodes                   22     59     64     59
 pte_list_desc                 0      0     32    112
 ext4_groupinfo_4k           722    756    136     28
 ext4_inode_cache           3362   3728    968      4
 ext4_xattr                    0      0     88     44
 ext4_free_data                0      0     64     59
 ext4_allocation_context       0      0    136     28
 ext4_prealloc_space          42     74    104     37
 ext4_system_zone              0      0     40     92
 Cache                       Num  Total   Size  Pages
 ext4_io_end                   0      0     64     59
 ext4_extent_status         1615   5704     40     92
 jbd2_transaction_s           30     30    256     15
 jbd2_inode                  254    539     48     77
 ........

发现这两项值很高: xfs_ili xfs_inode 占用了大量的内存。

3.使用slabtop命令查看内核slab 缓冲区信息

#slabtop -s c | head
   Active / Total Objects (% used)    : 31807723 / 35664583 (89.2%)
  Active / Total Slabs (% used)      : 3259180 / 3259251 (100.0%)
  Active / Total Caches (% used)     : 139 / 227 (61.2%)
  Active / Total Size (% used)       : 11242773.43K / 12756788.05K (88.1%)
  Minimum / Average / Maximum Object : 0.02K / 0.36K / 4096.00K
   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
 8480676 7565420  89%    1.00K 2120169        4
8480676K
xfs_inode
 8351794 7565375  90%    0.22K 491282       17
1965128K
xfs_ili

xfs_ili 占用1965128k xfs_inode占用8480676K,但他们究竟是什么东东?猜测是nas/rbd 卷的文件系统缓存信息。xfs_inode看字面意思是xfs文件系统的inode信息。

搜了下xfs_ili,只搜到内核代码片段。

xfs_inode_zone =
1636                 kmem_zone_init_flags(sizeof(xfs_inode_t), "xfs_inode",
1637                         KM_ZONE_HWALIGN | KM_ZONE_RECLAIM | KM_ZONE_SPREAD,
1638                         xfs_fs_inode_init_once);
1639         if (!xfs_inode_zone)
1640                 goto out_destroy_efi_zone;
1641
1642         xfs_ili_zone =
1643                 kmem_zone_init_flags(sizeof(xfs_inode_log_item_t), "xfs_ili",
1644                                         KM_ZONE_SPREAD, NULL);

 28 typedef struct xfs_inode_log_item {
 29         xfs_log_item_t          ili_item;          /* common portion */
 30         struct xfs_inode        *ili_inode;        /* inode ptr */
 31         xfs_lsn_t               ili_flush_lsn;     /* lsn at last flush */
 32         xfs_lsn_t               ili_last_lsn;      /* lsn at last transaction */
 33         unsigned short          ili_lock_flags;    /* lock flags */
 34         unsigned short          ili_logged;        /* flushed logged data */
 35         unsigned int            ili_last_fields;   /* fields when flushed */
 36         unsigned int            ili_fields;        /* fields to be logged */
 37         struct xfs_bmbt_rec     *ili_extents_buf;  /* array of logged
 38                                                       data exts */
 39         struct xfs_bmbt_rec     *ili_aextents_buf; /* array of logged
 40                                                       attr exts */
 41         xfs_inode_log_format_t  ili_format;        /* logged structure */
 42 } xfs_inode_log_item_t;

分析加估计是文件系统的日志缓存。究竟是不是?目前nfs-server有14个卷,每个卷的在格式化xfs的时指定的参数(即日志大小)-l=128m 141281024 约等于1965128。

4.但是xfs_ili xfs_inode两者加起来才10G,还有50G去哪儿了呢?查资料说linux将用过的文件缓存到内存中。

执行下面的命令就释放了内存

#sync      #
刷到磁盘
 #echo 3 > /proc/sys/vm/drop_caches

5.总结:是不是由于内存少导致的性能变差,还在测试。不过以后在优化nfs-server端有一定的指导意义。卷越多,必然占用的内存越多。做机头的内存配置要高。

文章转载自 开源中国社区 [http://www.oschina.net]

时间: 2024-11-18 06:39:52

linux 内存耗尽的分析的相关文章

解决Linux下php-fpm进程过多导致内存耗尽问题

最近,发现个人博客的Linux服务器,数据库服务经常挂掉,导致需要重启,才能正常访问,极其恶心,于是决心开始解决问题,解放我的时间和精力(我可不想经常出问题,然后人工重启,费力费时). 分析问题 发现问题以后,首先使用 free -m 指令查看当前服务器执行状况: 可以看到我的服务器内存是2G的,但是目前可用内存只剩下70M,内存使用率高达92%,很有可能是内存使用率过高导致数据库服务挂断. 继续看详细情况,使用 top 指令: 然后再看指令输出结果中详细列出的进程情况,重点关注第10列内存使用

Linux内核分析(三)----初识linux内存管理子系统

原文:Linux内核分析(三)----初识linux内存管理子系统 Linux内核分析(三) 昨天我们对内核模块进行了简单的分析,今天为了让我们今后的分析没有太多障碍,我们今天先简单的分析一下linux的内存管理子系统,linux的内存管理子系统相当的庞大,所以我们今天只是初识,只要对其进行简单的了解就好了,不会去追究代码,但是在后面我们还会对内存管理子系统进行一次深度的分析. 在分析今天的内容之前,我们先来看出自http://bbs.chinaunix.net/thread-2018659-2

Linux内存中的Cache真的能被回收么?

在Linux系统中,我们经常用free命令来查看系统内存的使用状态.在一个RHEL6的系统上,free命令的显示内容大概是这样一个状态: [root@tencent64 ~]# free total used free shared buffers cachedMem: 132256952 72571772 59685180 0 1762632 53034704-/+ buffers/cache: 17774436 114482516Swap: 2101192 508 2100684  这里的默

Linux 内存中的 Cache 真的能被回收么?

Linux 内存中的 Cache 真的能被回收么? 在 Linux 系统中,我们经常用 free 命令来查看系统内存的使用状态.在一个 RHEL6 的系统上,free 命令的显示内容大概是这样一个状态: [root@tencent64 ~]# free total used free shared buffers cached Mem: 132256952 72571772 59685180 0 1762632 53034704 -/+ buffers/cache: 17774436 11448

绿盟科技互联网安全威胁周报2016.30 需要尽快修补OpenSSH内存耗尽漏洞

绿盟科技发布了本周安全通告,周报编号NSFOCUS-16-29,绿盟科技漏洞库本周新增75条,其中高危41条.本次周报建议大家关注持续关注 OpenSSH内存耗尽漏洞 CVE-2016-8858,目前目前官方已经给出修复方案,强烈建议用户检查自己使用的OpenSSH是否受影响,如果是,尽快修复. 焦点漏洞 OpenSSH内存耗尽漏洞 NSFOCUS ID: 35262 CVE ID: CVE-2016-8858 受影响版本 OpenSSH 6.8-7.3 漏洞点评 OpenSSH是SSH(Sec

Linux内存管理原理【转】

转自:http://www.cnblogs.com/zhaoyl/p/3695517.html 本文以32位机器为准,串讲一些内存管理的知识点.   1. 虚拟地址.物理地址.逻辑地址.线性地址 虚拟地址又叫线性地址.linux没有采用分段机制,所以逻辑地址和虚拟地址(线性地址)(在用户态,内核态逻辑地址专指下文说的线性偏移前的地址)是一个概念.物理地址自不必提.内核的虚拟地址和物理地址,大部分只差一个线性偏移量.用户空间的虚拟地址和物理地址则采用了多级页表进行映射,但仍称之为线性地址. 2.

如何解决PHP里大量数据循环时内存耗尽的问题

最近在开发一个PHP程序时遇到了下面的错误: PHP Fatal error: Allowed memory size of 268 435 456 bytes exhausted  错误信息显示允许的最大内存已经耗尽.遇到这样的错误起初让我很诧异,但转眼一想,也不奇怪,因为我正在开发的这个程序是要用一个foreach循环语句在一个有4万条记录的表里全表搜索具有特定特征的数据,也就是说,一次要把4万条数据取出,然后逐条检查每天数据.可想而知,4万条数据全部加载到内存中,内存不爆才怪. 毕竟编程这

slab内存管理源代码分析

学习计算机原理,最好是实践或看高手写的源代码,在一定程度上就不再会感到原理的抽象.关于slab一些原理资料,可以在这里下载或到网站有更多的信息和资料.Slab内存管理机制已被广泛使用,要找到使用slab管理内存的开源代码也不难,如一些OS内核中的内存管理.既然要分析理解slab,最好还是选择复杂度和代码量都不要太大的,在这里我选取了glib-2.12.9的gslice.c实现的slab机制相关代码作为分析对象.注意Glib库是针对用户级的而非OS内核级别的. gslice.c中实现了三种内存分配

深入理解Linux内存管理机制(一)

深入理解Linux内存管理机制(一)通过本文,您即可以: 1. 存储器硬件结构: 2.分段以及对应的组织方式: 3.分页以及对应的组织方式. 注1:本文以Linux内核2.6.32.59本版为例,其对应的代码可以在http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/linux-2.6.32.59.tar.bz2找到. 注2:本文所有的英文专有名词都是我随便翻译的,请对照英文原文进行理解. 注3:推荐使用Source Insig