I have known Brian for nearly as long as i have been running SQLServerCentral. He has been the guy that I called for security questions. He was a DBA, then became a security and auditing guy, and is now back to being a DBA. This talk is designed to better explain the host OS for SQL Server pros. Some random notes since i am off to lunch.
We have user mode and kernel mode. Where does SQL Server run? Most services run in user mode. Kernel mode is for privileged mode, base OS services, memory access, device drivers,, HAL, etc. Most crashes come from device drivers or video drivers, so be sure these are up to date.
If SQL Server crashes, and it could, you don’t want the OS to crash. You want a graceful recovery or restart. That is why SQL Server runs in user mode.
Most processes start in user mode. If it makes a call to a system function, the kernel traps the request and switches to kernel mode, the call is carried out, and then the OS switches the process back to user mode. This tries to prevent poorly written applications from harming the OS environment.
BSOD. Microsoft doesn’t like this terminology and i am not surprised. When this happens, you have a hard OS crash. However you get a crash dump and information. The code listed, the parameters, and the dump file can be important to finding the root cause of the issue. Microsoft typically uses the mini-dump these days of the kernel to debug the issue.
SQL Server can be run as a command line application, but it typically runs as a server. The services subsystem in Windows manages this. There are various services host that control the services. Your interactions with services, starting, stopping, etc, are with these hosts, not the actual program. The services hosts must communicate with the actual program to have it perform an action.
Most services are also command line apps because they cannot have on screen interactions. MAPI was an example of this causing problems with SQL Server when it would pop a message at times that required an interactive desktop.
Windows 2008 (and later) and Vista (and later) have service isolation to prevent service hopping of service accounts. These OS’s also have a delayed auto start to allow some services to be delayed at startup for places where there are dependencies. Reporting services is an example here, you might want to delay this so that the database engine has a chance to start.
Sql manages its own threads, which are not linked to connections. So each connection is not a thread. Usually more connections than threads. SQL Server manages the threads and while you can boost the maximum number, you ought to do this only after extensive testing or advice from CSS. Or both.
Threads have priority, determining which threads may run before other threads, there are 32 priority levels. 1-15 are normal, and 16-31 are realtime processes, most things ought not run as 16 or above, SQL Server normally runs at 7, but can be boosted to 13. This is generally not recommended for most systems, but it can be an option. Often if SQL Server is waiting on something, it is usually disk or another bottleneck. Changing thread priority will not necessarily help.
Affinity mask determines which processors is SQL Server allowed to run on. Tis might be something you use if you have multiple instances and they compete for CPU time.
Highest priority thread always runs first. The OS an boost priority to prevent thread starvation, but the highest priority runs. Threads run for the duration of its quantum (duration). It can end early because it finishes, it needs to wait in something, or it is pre-empted.
Why are client tools slow on the server? The quantum duration is lower on servers. The server OS is optimized for background tasks, not interactive tasks. Some tasks get higher boosts. Sound application gets a very high boost, so do not run things like Media Player on a server.
Filed under: Blog Tagged: SQL Connections, sql server, syndicated, windows