Solaris 11随机挂起:需要帮助找出原因

我在HP DL385 G7上安装了Solaris 11(+最新的SRU)(连接到P2000存储器,有30个磁盘;它们被注册为单独的RAID0驱动器,但是我使用的是ZFS的raidz1),这是我们的文件服务器。 每两天,系统冻结,需要重新启动。 日志和fmdump没有什么特别之处。

我结束了一个cron工作,每隔2分钟就把一些统计数据转储到硬盘上,这表明在崩溃之前有一个负载增加和内存减less:

$ grep load top.120512* top.120512063601:last pid: 21751; load avg: 0.61, 2.30, 2.93; up 4+17:03:45 06:36:02 top.120512063800:last pid: 21765; load avg: 0.27, 1.62, 2.59; up 4+17:05:44 06:38:01 top.120512064000:last pid: 21779; load avg: 0.29, 1.17, 2.30; up 4+17:07:45 06:40:02 top.120512064200:last pid: 21793; load avg: 0.56, 0.97, 2.09; up 4+17:09:44 06:42:01 top.120512064400:last pid: 21807; load avg: 0.20, 0.71, 1.85; up 4+17:11:45 06:44:02 top.120512064600:last pid: 21821; load avg: 0.60, 0.66, 1.68; up 4+17:13:45 06:46:02 top.120512064800:last pid: 21835; load avg: 1.25, 0.87, 1.64; up 4+17:15:44 06:48:01 top.120512065000:last pid: 21851; load avg: 4.77, 2.35, 2.10; up 4+17:17:45 06:50:02 top.120512065200:last pid: 21864; load avg: 5.10, 3.20, 2.45; up 4+17:19:45 06:52:02 top.120512065400:last pid: 21878; load avg: 5.81, 4.16, 2.91; up 4+17:21:44 06:54:01 top.120512065601:last pid: 21892; load avg: 5.26, 4.53, 3.20; up 4+17:23:45 06:56:02 top.120512065800:last pid: 21906; load avg: 5.36, 4.79, 3.46; up 4+17:25:45 06:58:02 // here was the crash top.120512163801:last pid: 701; load avg: 1.18, 0.29, 0.10; up 0+00:01:16 16:38:02 top.120512164000:last pid: 1456; load avg: 0.36, 0.33, 0.14; up 0+00:03:16 16:40:02 top.120512164200:last pid: 1470; load avg: 0.14, 0.26, 0.14; up 0+00:05:16 16:42:02 top.120512164400:last pid: 1499; load avg: 0.39, 0.35, 0.19; up 0+00:07:15 16:44:01 top.120512164600:last pid: 1513; load avg: 0.10, 0.26, 0.17; up 0+00:09:16 16:46:02 

或者grep Memory

 top.120512064600:Memory: 16G phys mem, 2031M free mem, 2048M total swap, 2048M free swap top.120512064800:Memory: 16G phys mem, 2047M free mem, 2048M total swap, 2048M free swap top.120512065000:Memory: 16G phys mem, 1443M free mem, 2048M total swap, 2048M free swap top.120512065200:Memory: 16G phys mem, 1313M free mem, 2048M total swap, 2048M free swap top.120512065400:Memory: 16G phys mem, 892M free mem, 2048M total swap, 2048M free swap top.120512065601:Memory: 16G phys mem, 418M free mem, 2048M total swap, 2048M free swap top.120512065800:Memory: 16G phys mem, 294M free mem, 2048M total swap, 2044M free swap // restart top.120512163801:Memory: 16G phys mem, 14G free mem, 2048M total swap, 2048M free swap 

或者grep trap

 top.120512064800:Kernel: 50542 ctxsw, 13 trap, 113144 intr, 850 syscall, 9 flt top.120512065000:Kernel: 76357 ctxsw, 9 trap, 199203 intr, 399 syscall, 9 flt top.120512065200:Kernel: 72294 ctxsw, 13 trap, 254779 intr, 481 syscall, 9 flt top.120512065400:Kernel: 87671 ctxsw, 11 trap, 256663 intr, 401 syscall, 11 flt top.120512065601:Kernel: 72696 ctxsw, 11 trap, 281765 intr, 402 syscall, 11 flt top.120512065800:Kernel: 77316 ctxsw, 458 trap, 272329 intr, 412 syscall, 450 flt // restarted here top.120512163801:Kernel: 1570 ctxsw, 10 trap, 2380 intr, 1741 syscall, 9 flt 

这个是来自echo "::memstat" | mdb -k echo "::memstat" | mdb -k

 top.120512064800:ZFS File Data 2898132 11320 69% top.120512065000:ZFS File Data 3039466 11872 73% top.120512065200:ZFS File Data 3081508 12037 74% top.120512065400:ZFS File Data 3188175 12453 76% top.120512065601:ZFS File Data 3309405 12927 79% top.120512065800:ZFS File Data 3393392 13255 81% // restart top.120512163801:ZFS File Data 70094 273 2% top.120512164000:ZFS File Data 93547 365 2% top.120512164200:ZFS File Data 197571 771 5% top.120512164400:ZFS File Data 1175965 4593 28% top.120512164600:ZFS File Data 1205865 4710 29% top.120512164800:ZFS File Data 2537072 9910 61% 

ZFS池没有损坏,实际负载低于平均值(与我们的其他文件服务器相比),硬件似乎也没问题。

你认为什么可能是这种行为的原因? 我还需要收集哪些统计数据?

编辑:

 $ zpool status -v pool: rpool state: ONLINE scan: scrub repaired 0 in 0h6m with 0 errors on Wed Apr 25 14:40:49 2012 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c3t0d0s0 ONLINE 0 0 0 c3t1d0s0 ONLINE 0 0 0 errors: No known data errors pool: volume state: ONLINE scan: resilvered 285G in 2h57m with 0 errors on Mon May 7 22:01:38 2012 config: NAME STATE READ WRITE CKSUM volume ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 c0t600C0FF00012FBB1F749674F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7DDDA1154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB1DEA1154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D7CA2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB1EAA1154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7DEBA1154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB1F0A1154F01000000d0 ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 c0t600C0FF00012FC7DFCA1154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB1FDA1154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D08A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB109A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D14A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB115A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D20A2154F01000000d0 ONLINE 0 0 0 raidz1-2 ONLINE 0 0 0 c0t600C0FF00012FBB171A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D2CA2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB12DA2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D38A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB139A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D44A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7DA3CA754F01000000d0 ONLINE 0 0 0 raidz1-3 ONLINE 0 0 0 c0t600C0FF00012FC7D50A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB151A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D5CA2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB15DA2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D68A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FBB169A2154F01000000d0 ONLINE 0 0 0 c0t600C0FF00012FC7D70A2154F01000000d0 ONLINE 0 0 0 spares c0t600C0FF00012FBB1D7A1154F01000000d0 AVAIL c0t600C0FF000131E9277AD154F01000000d0 AVAIL errors: No known data errors $ zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 24.4G 249G 39.5K /rpool rpool/ROOT 14.1G 249G 31K legacy rpool/ROOT/solaris 5.59M 249G 11.5G / rpool/ROOT/solaris-1 14.1G 249G 11.5G / rpool/ROOT/solaris-1/var 2.15G 249G 1.94G /var rpool/ROOT/solaris/var 2.71M 249G 1.29G /var rpool/dump 8.24G 250G 7.98G - rpool/export 63K 249G 32K /export rpool/export/home 31K 249G 31K /export/home rpool/swap 2.06G 249G 2.00G - volume 8.77T 33.6T 6.77T /volume volume/gluster 33.5G 1.97T 33.5G /volume/gluster 

编辑2

下面是各种统计的差异: http : //diffchecker.com/k19ZP458 (左:“正常”系统状态,右:在崩溃前一分钟)

您尚未提供有助于诊断此问题的所有详细信息。

  • 这些崩溃发生多久了? (例如,这是一个新的安装吗?)
  • 您可以显示zpool history的输出还是解释您在存储池中使用压缩还是重复数据删除?
  • 你如何连接到P2000? (光纤,SAS,iSCSI)
  • DL385 G7中安装了哪些HBA卡?
  • 什么是P2000的磁盘布局? (这是一个SAN,所以它不适合ZFS解决scheme)
  • 是否安装了任何 适用于Solaris的HP Management Agents ?
  • 你的系统固件是否是最新的?
  • 国际劳工组织是否configuration? 你检查过它的日志吗? RAM的健康状况如何?
  • 你有在BIOS中configuration的自动服务器恢复看门狗 ? 这会在系统崩溃后触发重启。 这也有助于确定这是硬件还是软件问题。

所以我问这些问题何时开始,因为如果这是一个新的安装,你有一些select。 从您的磁盘布局看,这是一个基于ZFS的庞大存储系统。 在设置中有几个红旗,虽然…

其一,您将SAN中的多个虚拟磁盘暴露给ZFS。 基本上,您在P2000 SAN中定义了30个单独的RAID0arrays,并将这些arrays提交给Solaris。 如果您丢失了磁盘,则需要重新启动才能识别新设备 。

二,操作系统的select可能是一个问题,因为惠普没有在ProLiant系统上authentication或完全支持Solaris 11 。 如果这纯粹是一个存储单元,而且你没有运行任何特定于Solaris的软件, NexentaStor将是一个支持服务器硬件的安全解决scheme。 我在惠普硬件上构build了大部分ZFS存储解决scheme。 即使OpenIndiana也会更容易支持。

但是,如果您需要麻烦真正的崩溃,我们需要知道系统上发生了什么。 可能有导致坠机的日志。 你也可能有核心文件可以使用。 连接到SAN的方法也有点重要,因为我已经看到了Solaris和HP / Broadcom设备的奇怪的NIC问题。 这就是说,我打赌这是networking相关的…