Étiquette : tempdb

  • « On attend, on ne sait pas ce qui se passe » : enquête sur un verrou SQL

    « Cédric, on attend, on ne sait pas ce qui se passe. »

    C’est par cette phrase qu’un client m’a parlé de son logiciel de gestion. Tous les jours, ses utilisateurs validaient une action, puis attendaient. Sans savoir pourquoi.

    L’application tourne sur SQL Server. Je suis donc allé voir dans le moniteur d’activité. Le 31 juillet, il affichait 15 tâches en attente… pour 3 utilisateurs connectés.

    Un problème de verrou. Imaginez trois personnes qui attendent le même dossier : tant que l’une le garde, les autres ne peuvent rien faire. Ce n’était pas le seul problème du serveur, mais c’est celui qui expliquait l’attente à chaque validation.

    D’abord, remettre de l’ordre dans l’atelier

    J’ai commencé par une analyse de performance, pour faire baisser la charge du processeur et le nombre de requêtes : des index ajoutés, des paramètres du serveur revus, la base temporaire réorganisée.

    Ensuite, le matériel

    J’ai fait ajouter de la mémoire, avec une règle simple : assez de mémoire pour que la base tienne entière en mémoire. Et j’ai déplacé les fichiers de la base temporaire (tempdb) sur un disque SSD, ce que Microsoft recommande d’ailleurs : la base temporaire doit être sur un stockage rapide.

    Le lendemain matin, la capture du moniteur affichait 6 tâches en attente.

    Le client a vu la différence sur beaucoup d’actions. Mais l’attente à la validation, elle, persistait. On avait de meilleurs outils, le dossier restait bloqué.

    Changement de casquette

    Un verrou dans un logiciel du commerce, ce n’est plus mon terrain : c’est celui de l’éditeur. Encore fallait-il prouver à son prestataire que le serveur n’était pas en cause. J’avoue, ça a été long. J’ai fini par le convaincre d’installer la base sur l’un de ses propres serveurs et de la tester en conditions réelles, avec plusieurs utilisateurs en même temps.

    Trois heures avec le support de l’éditeur

    Une fois le prestataire convaincu, nous avons eu accès au niveau 3 du support de l’éditeur. Trois heures d’intervention. Je n’ai pas eu tous les détails, mais voici ce que j’ai retenu :

    • en personnalisant la base, le prestataire avait rendu certains champs obligatoires, et ces contraintes bloquaient ;
    • enregistrer des documents dans la base de données est déconseillé (pour des fichiers de plus de 1 Mo en moyenne, Microsoft conseille d’ailleurs de les ranger dans le système de fichiers avec FILESTREAM plutôt que dans les tables) ;
    • et le passage à SQL Server 2019 était recommandé.

    Un mois plus tard

    Zéro tâche en attente sur la capture, et 93 requêtes par seconde traitées. L’attente n’a pas totalement disparu, mais elle ne gêne plus le travail de personne. Et surtout, la facturation se fait sans demander à tout le monde de se déconnecter.

    La leçon que j’en garde : quand le serveur a été remis d’aplomb et que l’attente reste, il faut arrêter d’ajouter de la mémoire et aller chercher l’éditeur.

    Sources