在我们的一个从属DNS服务器BIND中，版本为bind910-9.10.0P2_3，在/var/log/messages不断被下面的消息所杀：
Jul 30 01:00:10 cinnabar kernel: pid 602 (named), uid 53, was killed: out of swap space
该服务在XenServer 6.2的FreeBSD 10.0 VM上运行，具有512MB的系统内存。
此时pstat -m -s返回：
Device 1M-blocks Used Avail Capacity /dev/ada0p3 512 9 502 2%
我不认为这是一个交换问题，这似乎是内存泄漏，但我不确定。
编辑：访问信息。
这是两个从属DNS服务器之一，它们只存储来自权威服务器的区域，并作为内部用户对外的recursion服务器。 客户端数量在700-1500个并发用户之间。 由于我们有一个/ 21的内部空间和一个/ 23的公共IPv4空间，并且没有来自外界的查询，所以端口53甚至在防火墙上被这些机器阻塞。
如果你在这个服务器上有任何的监控，那么在进程死亡的时候，检查内存使用是否有峰值是很好的。 然后你可以尝试找出与请求数等的关联
也就是说，这可能意味着系统中确实没有剩余内存，但很可能Bind正在请求一个连续的内存区域，碎片化正在阻碍之中，而FreeBSD正在尝试换出一些进程来腾出空间。 它可能不能换出多个页面，不能分配和触发内存不足的杀手。
如果您有磁盘空间，最简单的解决scheme是通过交换文件添加更多交换（不需要分区）。 理想情况下，您应该按照Håkan的build议限制caching大小（绑定默认为无限制 ），但这可能会对性能产生影响。 没有更多的统计数字是很难说的。 即使是国内的路由器现在也有512MB的内存，所以你应该考虑增加（并限制caching）为700-1500同步用户的生产服务器（这可以转换更多的需求/秒，没有更多的信息，很难说）。
您也可以尝试通过MALLOC_PRODUCTION旋钮调整malloc的实现，但是我认为在面对更简单的解决scheme时这太过分了。