La stratégie de limitation de Fabric
La limitation se produit lorsque la capacité d’un locataire consomme plus de ressources de capacité que celles achetées. Une limitation trop importante peut entraîner une dégradation de l’expérience de l’utilisateur final. Un locataire Microsoft Fabric peut créer plusieurs capacités et attribuer des espaces de travail à une capacité spécifique pour la facturation et le dimensionnement.
La limitation est appliquée au niveau de la capacité, ce qui signifie que si une capacité, ou un ensemble d’espaces de travail, peut voir ses performances réduites en raison d’une surcharge, d’autres capacités peuvent continuer à fonctionner normalement. Dans les cas où les fonctionnalités telles que les artefacts OneLake sont produites dans une capacité et consommées par une autre, l’état de limitation de la capacité consommatrice détermine si les appels à l’artefact sont limités.
Équilibre entre performances et fiabilité
Fabric est conçu pour fournir des performances ultrarapides à ses clients en permettant aux opérations d’accéder à plus de ressources d’unités de capacité (CU) que celles allouées à la capacité. Les tâches qui peuvent prendre plusieurs minutes pour se terminer sur d’autres plateformes peuvent être terminées en quelques secondes sur Fabric. Pour éviter de pénaliser les utilisateurs lorsque les charges opérationnelles augmentent, Fabric lisse ou établit une moyenne de l’utilisation des CU d’une opération sur une durée minimale de cinq minutes, voire plus pour les requêtes à forte intensité de CU mais à courte durée d’exécution. Ce comportement vous permet de bénéficier d’une performance rapide et constante sans subir de limitation.
Pour les opérations en arrière-plan qui ont de longs runtimes et consomment de lourdes charges de CU, Fabric lisse leur utilisation de CU sur une période de 24 heures. Le lissage élimine la nécessité pour les scientifiques des données et les administrateurs de base de données de passer du temps à créer des planifications de travail pour répartir la charge CU au cours de la journée afin d’éviter que les comptes ne se figent. Avec un lissage de CU de 24 heures, les tâches planifiées peuvent toutes s’exécuter simultanément sans provoquer de pics à tout moment pendant la journée, et vous pouvez profiter de performances constamment rapides sans perdre de temps à gérer les planifications des tâches.
Les opérations en cours d’exécution ne sont pas limitées
Quand une capacité entre dans un état limité, elle affecte uniquement les opérations demandées après la limitation de la capacité. Toutes les opérations, y compris celles de longue durée et qui ont été soumises avant le début de la limitation, sont autorisées à s’exécuter jusqu’à leur terme. Ce comportement vous garantit que les opérations sont terminées, même en cas d’augmentation de l’utilisation de CU.
Déclencheurs de limitation et étapes de limitation
Après le lissage, certains comptes peuvent encore connaître des pics d’utilisation de CU pendant les pics d’activité. Pour faciliter la gestion de ces pics, les administrateurs peuvent configurer des alertes par e-mail pour être avertis lorsqu’une capacité consomme 100 % de ses ressources CU provisionnées. Ce modèle indique que la capacité peut tirer parti de l’équilibrage de charge et que l’administrateur doit envisager d’augmenter la taille du SKU. Il est important de noter que, pour les SKU F, vous pouvez les augmenter et les diminuer manuellement à tout moment dans les paramètres d’administration. Toutefois, même lorsqu’une capacité fonctionne à son plein potentiel de CU, Fabric n’applique pas de limitation. Ce comportement garantit que les utilisateurs ont constamment des performances rapides sans rencontrer de perturbations.
La première phase de limitation commence lorsqu’une capacité a consommé toutes ses ressources CU disponibles pour les 10 prochaines minutes. Par exemple, si vous avez acheté 10 unités de capacité et que vous avez ensuite consommé 50 unités par minute, vous créerez un report de 40 unités par minute. Après deux minutes et demie, vous auriez accumulé un report de 100 unités, empruntées aux fenêtres futures. À ce stade, où toute la capacité est déjà épuisée pour les 10 prochaines minutes, Fabric lance son premier niveau de limitation et toutes les nouvelles opérations interactives sont retardées de 20 secondes lors de l’envoi. Si le report atteint une heure complète, les requêtes interactives sont rejetées, mais les opérations planifiées en arrière-plan continuent d’être exécutées. Si la capacité accumule une durée totale de 24 heures de report, la capacité entière est figée jusqu’à ce que le report soit réglé.
Consommation lissée future
Remarque
Microsoft s’efforce d’améliorer la flexibilité des clients dans le cadre de l’utilisation du service, tout en équilibrant la nécessité de gérer l’utilisation de la capacité par les clients. Pour cette raison, Microsoft peut modifier ou mettre à jour la stratégie de limitation Fabric.
| Utilisation | Limites de stratégie | Impact de l’expérience de la stratégie de la plateforme |
|---|---|---|
| Utilisation <= 10 minutes | Protection contre le dépassement | Les travaux peuvent consommer 10 minutes d’utilisation future de la capacité sans limitation. |
| Utilisation < 10 minutes <= 60 minutes | Retard des travaux interactifs | Les travaux interactifs demandés par l’utilisateur sont retardés de 20 secondes lors de l’envoi. |
| Utilisation < 60 minutes <= 24 heures | Rejet des travaux interactifs | Les travaux interactifs demandés par l’utilisateur sont rejetés. |
| Utilisation > 24 heures | Rejet des travaux en arrière-plan | Toutes les requêtes sont rejetées. |
Report de la réduction de l’utilisation de la capacité
Chaque fois qu’une capacité a une capacité inactive, le système rembourse les niveaux de report.
Si vous avez 100 minutes de CU et un report de 200 minutes de CU, et que vous n’avez pas d’opérations en cours d’exécution, il faut deux minutes pour compenser votre report. Dans cet exemple, le système n’est pas limité, car il y a deux minutes de report. Les retards de limitation ne commenceront pas avant que 10 minutes de report ne se soient accumulées.
Si vous devez payer votre report plus rapidement, vous pouvez augmenter temporairement la taille de votre SKU pour générer une capacité inactive plus élevée appliquée à votre report.
Le comportement de limitation est spécifique à Fabric
Bien que la plupart des produits Fabric suivent les règles de limitation mentionnées précédemment, il existe certaines exceptions.
Par exemple, les flux d’événements Fabric ont de nombreuses opérations qui peuvent s’exécuter pendant des années une fois qu’ils sont démarrés. La limitation des nouvelles opérations de flux d’événements n’aurait pas de sens. Par conséquent, la quantité de ressources CU allouée pour maintenir le flux ouvert est réduite tant que la capacité n’est pas à nouveau en bon état.
L’expérience Informations en temps réel constitue une autre exception : elle ne serait pas en temps réel si les opérations étaient retardées de 20 secondes. Par conséquent, elle ignore la première phase de limitation avec des retards de 20 secondes à 10 minutes de report et attend jusqu’à la phase de rejet à 60 minutes de report pour commencer la limitation. Ce comportement garantit que les utilisateurs peuvent continuer à bénéficier de performances en temps réel, même pendant les périodes de forte demande.
De même, presque toutes les opérations dans la catégorie Entrepôt sont signalées comme étant en arrière-plan pour tirer parti du lissage de 24 heures de l’activité qui permet d’avoir des modèles d’utilisation plus flexibles. Si vous classez tout l’entrepôt de données comme étant en arrière-plan, les pics d’utilisation de CU ne déclenchent pas trop rapidement de limitation. Certaines requêtes peuvent déclencher une chaîne d’opérations limitées différemment. Cela peut faire en sorte qu’une opération en arrière-plan soit soumise à une limitation en tant qu’opération interactive.
Classifications interactives et en arrière-plan pour la limitation et le lissage
Microsoft Fabric divise les opérations en deux types, interactifs et arrière-plan. Vous trouverez des descriptions de ces éléments et des distinctions entre eux dans les opérations Fabric.
Certains administrateurs peuvent remarquer que les opérations sont parfois classées comme interactives et lissées en arrière-plan, ou vice versa. Cette distinction se produit parce que les systèmes de limitation de Fabric doivent appliquer des règles de limitation avant qu’une requête ne commence à s’exécuter. Le lissage se produit une fois que le travail a commencé à s’exécuter et que la consommation de CU peut être mesurée.
Les systèmes de limitation tentent de classer avec précision les opérations lors de la soumission, mais parfois la classification d’une opération peut changer après l’application de la limitation. Lorsque l’opération commence à s’exécuter, des informations plus détaillées sur la requête sont disponibles. Dans les scénarios ambigus, les systèmes de limitation tendent à classer les opérations en arrière-plan, ce qui est dans l’intérêt de l’utilisateur.
Suivre les dépassements et les opérations rejetées
Vous pouvez déterminer si votre capacité est surchargée en consultant le graphique d’utilisation dans l’application Métriques de capacité Microsoft Fabric. Un pic dépassant la ligne indique une surcharge. Pour examiner plus précisément la surcharge, accédez à la page de Point dans le temps. Vous pouvez ensuite passer en revue vos opérations interactives et en arrière-plan, et voir celles qui ont causé la surcharge de votre capacité. Vous pouvez également déterminer quand les événements de surcharge ont eu lieu.
Étant donné qu’une utilisation supérieure à 100 % ne signifie pas automatiquement une limitation, vous devez utiliser le graphique de limitation lors de l’évaluation des dépassements. À partir de là, vous pouvez ouvrir une table indiquant le nombre de minutes jusqu’au burndown, un graphique avec l’ajout, le burndown et le pourcentage cumulé, et bien plus encore.
Pour afficher un historique visuel de toute surutilisation de capacité, y compris les données de report, de cumul et de burndown de l’utilisation, cliquez sur l’onglet Dépassements. Vous pouvez modifier l’échelle visuelle des dépassements pour afficher 10 minutes, 60 minutes et 24 heures. Le report ne prend en compte que les opérations facturables.
L’exploration de l’application Métriques de capacité Microsoft Fabric permet aux administrateurs de voir les opérations qui ont été rejetées lors d’un événement de limitation. Les informations sur ces opérations sont limitées, car elles n’ont jamais été autorisées à démarrer. L’administrateur peut voir le produit, l’utilisateur, l’ID d’opération et l’heure à laquelle la requête a été envoyée. Lorsqu’une requête est rejetée, les utilisateurs finaux reçoivent un message d’erreur qui leur demande de réessayer plus tard.
Actions à entreprendre pour se remettre d’une situation de surcharge
Lorsque votre capacité est limitée au point d’être figée, les utilisateurs reçoivent une erreur si leur action nécessite des ressources de calcul Fabric. Par exemple, l’erreur peut indiquer Impossible de charger le modèle en raison de limites de capacité atteintes. Dans ce cas, vous pouvez utiliser ces stratégies pour récupérer votre capacité à partir de son état figé.
- Attendez que l’état de surcharge soit terminé avant d’envoyer de nouvelles demandes.
- Mettez à niveau la SKU d’une capacité F.
- Mettez en pause/reprenez une capacité F.
- Effectuez une mise à l’échelle automatique d’une capacité P.
- Déplacez les espaces de travail de priorité inférieure ou de surconsommation hors de la capacité.
Contenu connexe
- Installez l’application Métriques de capacité Microsoft Fabric pour surveiller les capacités Fabric.