If MAX WORKER THREADS increased from 255 to 500 what will be the usage or availability of system resources on the server?

Continuing on the MAX WORKER THREADS topic from ThisBlog I have been asked about method of calculating the amount of system resources that will be used when the setting is increased to 500 from 255 (default).

Well, as one of the best practices you must test the implications and usage in hiking such a value that will affect the whole server system, not specific to SQL Server though. Practically I wouldn't see much issues if the SQL Server is a dedicated server in this case, if not you should perform a thorough set of counters (using SYSMON) & query performance during high & low volumes on the server. As per the configuration each worker thread consumes 0.5MB on the server and any increase in MAX WORKER THREADS should have usage of 512KB of virtual memory that will be wasted sometimes. Unless there is a specific indication or recommendation to increase this value the default value of 255 will be able to cater thousands of user connections, as it proved in my case where we had website with a minimum of 5000 user connections at any time.

With regard to the available resources there isn't any strict numbers or guidelines to define, in any case you should be able to monitor using the DBCC statements such as DBCC MEMORYSTATUS & DBCC SQLPERF(UMSSTATS). Just going out of topic using DBCC SQLPERF statement is best way forward to obtain system information at any time, thisArticle from SQLDEV.net is best one to recommend for more information and that quotes:

DBCC SQLPERF is one of the most important undocumented SQL Server performance tuning pearls that allows you to answer the question: "how well is my system performing". DBCC SQLPERF provides different kinds of statistical data which is gathered by the system at runtime. This data can be used to analyze and evaluate your system and pinpoint possible bottlenecks.

So in using this DBCC statement you can determine for sure whether a lack of worker threads is the cause of any of your bottlenecks by simply checking dbcc sqlperf(umsstats) during the slowdowns, and make sure to go through the output of DBCC SQLPERF(UMSSTATS) that helps in determining a CPU bottleneck. Further with some basic diagnostics such as Profiler traces and Perfmon logs collected during the slowdowns would be useful.