Planification de lots ou de tâches SQL Server
Chaque instance de SQL Server 2005 est un processus de système d'exploitation distinct. Chaque instance peut être amenée à gérer des milliers de demandes simultanées des utilisateurs. Pour gérer efficacement ces tâches concomitantes, les instances de SQL Server utilisent des threads Microsoft Windows ou, si cette option est configurée, des fibres. Chaque instance de SQL Server exécute toujours plusieurs threads pour les processus système : un ou plusieurs threads pour chaque serveur Net-Library, un thread de réseau pour gérer l'E/S réseau et un thread de signal pour la communication avec le gestionnaire de contrôle des services.
Compréhension de la planification
Chaque instance de SQL Server possède une couche interne qui met en œuvre un environnement similaire à un système d'exploitation. Cette couche interne est utilisée pour planifier et synchroniser les tâches concomitantes sans passer par le noyau Windows. Cette couche interne peut également planifier des fibres ou des threads Windows de manière efficace. Chaque instance de SQL Server gère un pool de threads ou de fibres pour le traitement des requêtes utilisateur. La taille maximale de ce pool est contrôlée par l'option de configuration de serveur max worker threads.
Pour comprendre la manière dont une demande ou une tâche est traitée, il est utile se familiariser avec la terminologie de base suivante :
Connexion
Une connexion est établie lorsque l'utilisateur a réussi à se connecter. L'utilisateur peut ensuite soumettre une ou plusieurs instructions Transact-SQL pour les exécuter. Une connexion est fermée lorsque l'utilisateur se déconnecte volontairement, ou lorsqu'il y est mis fin.
Lot
Un lot SQL est un ensemble d'une ou de plusieurs instructions Transact-SQL envoyées par un client à une instance de SQL Server pour exécution. Il représente une unité de travail envoyée au Moteur de base de données par un utilisateur.
Tâche
Une tâche représente une unité de travail planifiée par SQL Server. Un lot peut se mapper sur une ou plusieurs tâches. Par exemple, une requête parallèle sera exécutée par plusieurs tâches.
Thread Windows
Chaque thread Windows représente un mécanisme d'exécution indépendant.
Fibre
Une fibre est un thread léger qui requiert moins de ressources qu'un thread Windows et qui peut changer de contexte lorsqu'elle est en mode utilisateur. Un thread Windows peut être mappé sur plusieurs fibres.
Thread de travail
Un thread de travail est un thread logique dans SQL Server, mappé en interne (1:1) sur un thread Windows ou, si le lightweight pooling est activé, sur une fibre. Le mappage est maintenu jusqu'à ce que le thread de travail soit désalloué en raison de la pression sur la mémoire ou d'une longue inactivité. L'association d'une tâche à un thread de travail est maintenue pendant la durée de vie de la tâche.
Gestion des connexions utilisateur et des ressources des threads de travail
Bien que l'utilisation de ressources par les threads et les fibres soit allégée, ces dernières en consomment malgré tout. Dans le cas de systèmes comptant des centaines ou des milliers de connexions utilisateur, l'utilisation d'un thread ou d'une fibre par connexion peut consommer suffisamment de ressources pour diminuer l'efficacité de SQL Server. De plus, l'allocation d'un thread ou d'une fibre à chaque connexion utilisateur n'est pas non plus nécessaire car, en réalité, la plupart des connexions consacrent le plus clair de leur temps à attendre la réception de lots de la part des clients. Au lieu de cela, l'instance de SQL Server utilise un pool de threads de travail. Ce pool doit être suffisamment grand pour accueillir le nombre de connexions utilisateur qui exécutent des lots en même temps dans l'instance en question. En conservant la valeur par défaut de l'option max worker threads, soit 0, vous permettez à l'instance de SQL Server de mapper efficacement les connexions utilisateur sur plusieurs threads de travail. Ceci évite la surconsommation des ressources.
Configuration de SQL Server pour les fibres
L'option de configuration de serveur lightweight pooling détermine si une instance de SQL Server utilise des threads Windows ou des fibres. La valeur par défaut pour cette option est 0. Cela indique que l'instance de SQL Server planifie un thread Windows par thread de travail, jusqu'à la valeur définie dans l'option Nombre maximal de threads de travail. Si l'option lightweight pooling a la valeur 1, SQL Server utilise des fibres au lieu de threads Windows. On parle alors de mode fibre. En mode fibre, une instance de SQL Server alloue un thread Windows par planificateur SQL, puis alloue une fibre par thread de travail jusqu'à la valeur définie dans l'option max worker threads. Qu'elle utilise des threads Windows ou des fibres, une instance de SQL Server utilise les mêmes algorithmes pour planifier et synchroniser les tâches. SQL Server Express ne prend pas en charge les fibres. Pour plus d'informations, consultez Utilisation de l'option lightweight pooling.
Fonctionnement de la planification de lots ou de tâches
Lorsqu'une application se connecte au Moteur de base de données, elle reçoit un ID de session (SPID). Toutes les informations qui doivent être maintenues pendant la durée de la connexion sont gérées dans des structures de données internes associées à ce SPID. Lorsqu'une instance de SQL Server reçoit un lot d'un client, elle le fractionne en une ou plusieurs tâches et associe chaque tâche à un thread de travail disponible dans un pool de threads de travail. Ce thread de travail est associé à la tâche pendant toute la durée de celle-ci. Il exécute la demande sur le planificateur SQL associé. Si aucun thread de travail n'est disponible et que la valeur de max worker threads n'a pas été atteinte, l'instance de SQL Server alloue un nouveau thread de travail au nouveau lot. Si aucun thread ni aucune fibre n'est disponible et que la valeur de l'option max worker threads a déjà été atteinte, l'instance de SQL Server bloque la nouvelle tâche jusqu'à ce qu'un thread soit libéré.
Un thread de travail reste associé à une tâche jusqu'à l'exécution de celle-ci, par exemple, jusqu'à ce que le dernier ensemble de résultats généré par le lot ait été retourné au client. Le thread de travail est ensuite libéré et peut être associé aux tâches du lot suivant.
L'intervention du Moteur de base de données au niveau de la connexion se limite à la période comprise entre la réception d'un lot et le retour des résultats au client. Pendant cette période, il se peut qu'à certains moments le lot ne requière aucun traitement actif. Par exemple, il peut arriver que le Moteur de base de données doive attendre qu'une opération de lecture soit effectuée pour l'extraction des données nécessaires à la requête en cours, ou qu'un autre lot désactive un verrou. L'association tâche/thread de travail est maintenue même lorsque la tâche est bloquée sur une certaine ressource.
Lorsque le Moteur de base de données commence à traiter une tâche associée à un lot, il planifie l'exécution du travail par le thread de travail associé à cette tâche. Une fois que le thread de travail a terminé, l'instance de SQL Server l'affecte à la tâche suivante prête à travailler. Le SPID reste le même pendant toute la durée de la connexion. Les tâches des différents lots d'une connexion de longue durée peuvent être exécutées par plusieurs threads de travail. Par exemple, les tâches du premier lot peuvent être exécutées par worker1, tandis que les tâches du deuxième lot seront exécutées par worker2. Certaines instructions peuvent être traitées en parallèle. Dans ce cas, un lot peut contenir plusieurs tâches qui sont exécutées simultanément par plusieurs threads de travail.
Voir aussi
Concepts
Allocation de threads à une UC
Utilisation de l'option lightweight pooling
Exécution de threads et de fibres
Autres ressources
Architecture de threads et de tâches