由SQL 2005 Express的Limitation引申出的一些知识点
SQL 2005 Express有一个限制, 那就是只能使用1G的内存.
那么这个限制对用户连接数有什么影响呢? 对性能多大可衡量的影响呢? worker thead的数目能提高性能么?
学友找了一些资料, 英文原文会引用起来, 结论用中文表述.
==================
资料一:
http://en.wikipedia.org/wiki/SQL_Server_Express
Microsoft SQL Server Express have a number of technical restrictions including: 1 GB of RAM (runs on any size RAM system, but uses only 1 GB)
结论一: SQL 2005 Express 有1GB的内存硬性限制.
===================
资料二:
http://blogs.msdn.com/khen1234/archive/2005/11/07/489778.aspx
Besides the 256 MB that is set aside for MemToLeave by default, an additional 127.5 MB is set aside for worker thread stacks (255 workers * .5MB stack space per thread). This ~384 MB is reserved, then freed at startup in order to set it aside for later use. This causes it to be ignored by the buffer pool, SQL Server’s primary memory cache and the source for most memory allocation within the server. If you increase max worker threads, you drive up the amount of virtual memory that must be set aside for thread stacks. And when you do that, you deprive the bpool of memory it could otherwise use for things you might need – caching data and index pages, for example. If those extra workers aren’t actually needed (and they almost always aren’t), you’re effectively constraining the bpool for no good reason. So, not only is increasing max worker threads not helping performance, it’s actually hindering it – and doing so in a subtle way that may not be easy to detect.
结论二: 在默认max worker thread数目为255的情况下, SQL固定要吃掉的内存有384兆, 其中256兆是MemToLeave, 128兆是用来存储worker thread的栈空间. 盲目提高max worker thread数目是不明智的, 因为这会损伤SQL实际需要的内存. 在SQL express的时候, 这个限制就更明显了, 1024 – 384 = 640 兆, 即sql用户缓存数据, 索引分页等内存只剩640兆可用. 再增加worker thread, 就会让sql 可用的内存更少.
===================
资料三:
http://support.microsoft.com/kb/319942
By default, the max worker threads setting is 255 in SQL Server 2000. Therefore, up to 255 worker threads can be created. Use the default setting of 255 in most cases. This does not mean that you can only establish 255 user connections. A system can have thousands of user connections (which are essentially multiplexed down to 255 worker threads) and in general, users do not generally perceive any delays. In such a case, only 255 queries can run concurrently, but this is multiplexed down to the number of available CPUs, so the concurrent nature is only perceived, regardless of the number of configured worker threads.
http://blogs.msdn.com/khen1234/archive/2005/11/07/489778.aspx
As work comes in from a user, it is added to the scheduler's work request queue, then de-queued and carried out by a worker. UMS is designed such that it's typical for just one worker to be active on each scheduler at a time. This means that it's common for one worker to carry out the work of many users simultaneously. How does this happen? Believe it or not, even on high volume servers, it's unusual for multiple users to submit work at exactly the same time, particularly when those users are spread across multiple processors. As long as it's possible for one worker to carry out the work of multiple users efficiently, this is preferable because it helps prevent multiple workers (again, typically threads) from competing with one another for the same CPU. This competition can lead to thread context switches, the very thing UMS was designed to minimize.
结论三: 用户连接数与worker thread的数目无关. worker thread的数目意味着同时处理的query会增多, 但是这与可用的cpu的数目相关, 与work thread的数目没有关系. 如果用户连接请求太多, 他们会被UMS scheduler object放入队列, 依次由可用的worker thread来处理. 较少的worker thread可以避免过多的线程向下文的切换, 从而可以提高性能.
参考资料:
max worker threads Option
http://technet.microsoft.com/en-us/library/ms187024%28SQL.90%29.aspx
Max worker threads
http://blogs.msdn.com/khen1234/archive/2005/11/07/489778.aspx
How to determine proper SQL Server configuration settings
http://support.microsoft.com/kb/319942
SQL Server Express