Post reply

Using NT Fibers

  • August 23, 2005 at 9:38 am

    #88639

    I seem to remember reading somewhere that you should avoid using NT Fibers.  Does anyone have any recommendations or point me in the direction for additional information so I may make an informed decision regarding any changes to the SQL Servers I have inherited that are using NT Fibers?

     

    Thanks,

    Lynn

  • August 23, 2005 at 12:03 pm

    #584322

    Hello Lynn,

    The option NT-fibers is generally not needed and should be turned off.

    Microsoft has a document on

    How to determine proper SQL Server configuration settings

    http://support.microsoft.com/default.aspx?scid=kb;en-us;319942

    a longer version can be found at

    http://www.sql-server-performance.com/sql_server_configuration_settings.asp

    SQL Server also has an optional mode it can run in, called fiber mode. In this case, SQL Server uses one thread per processor (like thread mode), but the difference is that multiple fibers are run within each thread. Fibers are used to assume the identity of the thread they are executing and are non-preemptive to other SQL Server threads running on the server. Think of a fiber as a "lightweight thread," which, under certain circumstances, takes less overhead than standard UMS threads to manage. Fiber mode is turned on and off using the "lightweight pooling" SQL Server configuration option. The default value is "0", which means that fiber mode is turned off.

    So what does all this mean? Like everything, there are pros and cons to running in one mode over another. Generally speaking, fiber mode  may" be beneficial when all of the following circumstances exist:

    • Eight or CPUs are found on the server (the more the CPUs, the larger the

      benefit).

    • All of the CPUS are running near maximum (95-100%) most of the time.

    • There is a lot of context switching occurring on the server (as reported by the Performance Monitor System Object: Context Switches/sec. Generally speaking, more than 20,000 context switches per second is considered high.

    • The server is making little or no use of distributed queries or extended stored procedures.

    If all the above are true, then turning on "lightweight pooling," option in SQL Server may see a small boost in performance.

    But if the four circumstances are all not true, then turning on "lightweight pooling" could actually degrade performance. For example, if your server makes use of many distributed queries or extended stored procedures, then turning on "lightweight pooling" will definitely cause a problem because they cannot make use of fibers, which means that SQL Server will have to switch back-and-forth from fiber mode to thread mode as needed, which hurts SQL Server's performance.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply