Since 2.1.2 hw.em.num_queues="4" settings -> Fatal Trap

  • Hello,

    since the upgrade from 2.1 to 2.1.2 we got a problem with our boot/loader.conf.local settings
    so far we used these settings:

    described here:

    but since 2.1.2, setting this line hw.em.num_queues="x" results in Fatal Traps (see attachment) and system wont boot anymore.
    Any idea why this happens? and how to fix it?


  • Your nmbclusters line is way too high unless you've got two dozen NICs and multiple CPUs with high core counts.

    If you remove the queue line does the system boot?  If so, just remove it.  You shouldn't be changing that setting unless you need to.

  • Yep the system boots without any problem without the queue settings.
    we are using a xeon e3-1245v2 and 2 x dual Gbit Intel NIC's

  • @turtle:


    Is that a typo? Looks suspiciously like this was intended to be 65536 (=2^16), without the extra 5 in there…

  • Even 65536 is likely too high.


    The NMBCLUSTERS kernel configuration option dictates the amount of network Mbufs available to the system. A heavily-trafficked server with a low number of Mbufs will hinder performance. Each cluster represents approximately 2 K of memory, so a value of 1024 represents 2 megabytes of kernel memory reserved for network buffers. A simple calculation can be done to figure out how many are needed. A web server which maxes out at 1000 simultaneous connections where each connection uses a 6 K receive and 16 K send buffer, requires approximately 32 MB worth of network buffers to cover the web server. A good rule of thumb is to multiply by 2, so 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. Values between 4096 and 32768 are recommended for machines with greater amounts of memory. Never specify an arbitrarily high value for this parameter as it could lead to a boot time crash. To observe network cluster usage, use -m with netstat(1).

    If each cluster represents approximately 2K of memory, 65536 = 134,217,728 bytes or 128MB or ram, just for mbufs.  In reality, a bit more than this (65536 * (2048 + 256), so around 144MB) is used.

Log in to reply