Partager via


Planification de lots ou de tâches SQL Server

Chaque instance de SQL Server 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 requête ou une tâche est traitée, il est utile de 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 est mis fin à celle-ci.

  • traitement
    Un traitement 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 les utilisateurs.

  • tâche
    Une tâche représente une unité de travail planifiée par SQL Server. Un traitement peut être mappé à 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é à plusieurs fibres.

  • thread de travail
    Un thread de travail est un thread logique dans SQL Server, mappé en interne (1:1) à un thread Windows ou, si le regroupement léger est activé, à 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 traitements 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 traitements 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 de cette option est 0. Cela signifie que l'instance de SQL Server planifie un thread Windows par thread de travail, jusqu'à la valeur affectée dans l'option max worker threads. 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 les fibres en charge. Pour plus d'informations, consultez Utilisation de l'option lightweight pooling. Il n'est pas recommandé d'utiliser la planification en mode fibre pour les opérations courantes. Cela peut réduire les performances en bloquant les avantages habituels du basculement de contexte. Par ailleurs, certains composants de SQL Server ne peuvent pas fonctionner correctement en mode fibre. Pour plus d'informations, consultez lightweight pooling.

Fonctionnement de la planification de traitements 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 traitement 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 traitement. 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 traitement ait été retourné au client. Le thread de travail est ensuite libéré et peut être associé aux tâches du traitement 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 traitement et le retour des résultats au client. Pendant cette période, il se peut qu'à certains moments le traitement 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 traitement 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 traitement, 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 traitements d'une connexion de longue durée peuvent être exécutées par plusieurs threads de travail. Par exemple, les tâches du premier traitement peuvent être exécutées par worker1, tandis que les tâches du deuxième traitement seront exécutées par worker2. Certaines instructions peuvent être traitées en parallèle. Dans ce cas, un traitement peut contenir plusieurs tâches qui sont exécutées simultanément par plusieurs threads de travail.