估计故障转储大小

当尝试配置太小的转储设备时，会报告空间需求的估计值。
在下面的示例中，尝试将 20MB 的 zvol 配置为专用转储设备。
dumpadm 命令报告估计的转储大小，假设压缩率为 2x，将为 438501376 字节 (418MB)。
如果将 dumpadm 配置为转储所有内存页面，而不仅仅是内核页面，则大小估计只是已安装内存量的一半。

# dumpadm
      Dump content: kernel pages
       Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash
  Savecore enabled: yes
   Save compressed: on

# zfs create -V 20m rpool/smalldump

# dumpadm -d /dev/zvol/dsk/rpool/smalldump 
dumpadm: dump device /dev/zvol/dsk/rpool/smalldump is too small to hold a system dump
dump size 438501376 bytes, device size 20971520 bytes

通过“savecore -L”创建实时故障转储，我们看到在这种情况下实现了更高的压缩率，实际故障转储大小为 74MB。
如此高的压缩比并不总是可能的，因此应该根据较低的比率来分配空间，例如2 倍。

# ls -lh /var/crash/vmdump.0
-rw-r--r--   1 root     root         74M Jan 17 09:28 /var/crash/vmdump.0

相同的方法适用于 UFS 转储设备，尽管这需要分配一个小磁盘片作为专用转储设备。
以下 mdb 命令复制了 dumpadm 使用的计算以获得其估计值，因此可用于快速获得近似值.

在没有 150400-26 (SPARC)/150401-26 (x86) 和 Solaris 11.0 的 Solaris 10 上：

# echo "physinstalled::print -d |>f; obp_pages::print -d |>g; availrmem::print -d |>h; anon_segkp_pages_locked::print -d |>i; k_anoninfo::print -d ani_mem_resv |>j; pages_locked::print -d |>k; pages_claimed::print -d |>l; pages_useclaim::print -d | >n ; _pagesize::print -d |>p ; ((<f-<g-<h-<i-<j-<k-<l-<n)*<p)%2=E" | /usr/bin/mdb -k
                443269120

在没有 SRU 19 的 Solaris 11.1 上：

# echo "physinstalled::print -d |>f; obp_pages::print -d |>g; availrmem::print -d |>h; anon_segkp_pages_locked::print -d |>i; k_anoninfo::print -d ani_mem_resv |>j; pages_locked::print -d |>k; _pagesize::print -d |>p ; ((<f-<g-<h-<i-<j-<k)*<p)%2=E" | /usr/bin/mdb -k
                1089818624

在带有 150400-26 (SPARC)/150401-26 (x86) 或者更高版本的 Solaris 10 以及带有 SRU 19 或者更高版本的 Solaris 11.1 上：

# echo "kpages_locked::print -d |>l; _pagesize::print -d |>p; (<l*<p)%2=E" | /usr/bin/mdb -k
                3918499840

从 Solaris 11u2 开始，我们为 dumpadm 增加了新的“-e”标志，它会打印转储空间需求的估计值，例如

# dumpadm -e
Estimated space required for dump: 335.52 M

Solaris 为捕获故障转储所需的磁盘空间量取决于许多因素。
默认情况下，Solaris 将只捕获内核的内存页。
但是也可以捕获用户页面，这在大多数情况下会导致更大的故障转储文件。
此行为通过 dumpadm “转储内容”设置通过“-c”命令行参数进行控制。
内核的内存消耗会因系统而异，因此无法给出故障转储大小的一般准则。

以下是影响故障转储大小的一些一般因素：

1. 安装了大量 内存 的系统通常会看到内核消耗更多的内存，因为需要更多的内核内存来管理更大的整体内存空间以及我们可能期望在此类系统上看到的更多进程和线程.

2. 导致内核内存泄漏的错误也可能导致故障转储需要更大的空间。
   最坏的情况是耗尽所有可用 内存 的泄漏。

3. 从 Solaris 10 update 9 (9/10) 开始，崩溃转储在写入转储设备时会被压缩，从而大大降低了空间需求。
   如果可能，使用 bzip2 压缩，否则使用 lzjb。
   故障转储压缩可以通过 dumpadm 启用和禁用。
   它默认启用。