Paramètres d'administration - Requêtes

À partir de la version 22.16 de Looker, les administrateurs Looker peuvent activer la fonctionnalité expérimentale expérimentale Administrateur de requêtes amélioré pour améliorer la page Requêtes. La fonctionnalité "Fonctionnalités expérimentales" permet d'améliorer les performances sur la page Requêtes et répertorie 500 requêtes paginées, au lieu de 50.

La page Requêtes de la section Base de données du menu Admin répertorie les informations des 50 dernières requêtes que Looker a envoyées à votre base de données. Pour en savoir plus sur les requêtes plus anciennes, consultez la section Utilisation de Looker.

Informations de base sur les requêtes

Colonne Définition
Temps Heure de début de la requête, affichée dans le fuseau horaire de votre application.
État État de la requête, qui peut inclure les éléments suivants :
  • Cache : Looker a renvoyé les résultats de son cache au lieu d'exécuter une requête en double sur la base de données.
  • Terminé: la requête a bien été exécutée.
  • Erreur : la requête n'a pas abouti, car une erreur s'est produite. Pour en consulter les détails, cliquez sur le bouton "Détails".
  • Cancelled (Annulée) : la requête a été annulée par Looker ou l'utilisateur.
  • Pending PDT: la requête doit attendre la création d'une table dérivée persistante avant de pouvoir l'exécuter.
  • PDT: une table dérivée persistante est en cours de création.
  • Queued (En file d'attente) : la requête est en attente d'exécution, car trop de requêtes sont déjà en cours (les requêtes peuvent être limitées par Looker dans la configuration de votre connexion ou dans votre base de données).
  • Running (En cours d'exécution) : la requête est en cours d'exécution.
  • Inconnu: Looker n'a pas pu déterminer ce qui s'est passé avec cette requête.
Connexion Connexion Looker sous laquelle la requête a été exécutée.
Utilisateur Utilisateur qui a exécuté cette requête, si cela peut être déterminé. Certaines requêtes ne sont pas exécutées par un utilisateur spécifique, par exemple lorsque Looker crée une table dérivée persistante ou lorsqu'un utilisateur inconnu accède à un look public.
Source Source de la requête dans Looker, telle que la page "Explorer" ou l'exécuteur SQL. Si possible, un lien vers l'élément enregistré ou l'ID de la requête, ainsi que le nom du modèle et la fonction Explorer, s'affichent également. Certaines requêtes ne comportent pas d'informations supplémentaires, telles que celles exécutées dans l'exécuteur SQL.
Runtime Temps nécessaire à l'exécution de la requête. Cela inclut la construction de la requête, le temps qu'elle passe dans la file d'attente, le transit vers et depuis la base de données, et l'exécution de la base de données.

Si la requête est en cours d'exécution, la durée d'exécution de la requête est indiquée. Pour les requêtes exécutées précédemment, l'environnement d'exécution fournit également une estimation du temps nécessaire pour terminer l'exécution de la requête. L'estimation est basée sur la durée de la dernière exécution de la requête et indique une valeur d'environ 2 s.
Bouton "Détails" Pour en savoir plus, consultez la sous-section Bouton "Détails" de cette page.

Bouton "Détails"

Cliquez sur le bouton Détails à droite d'une requête pour afficher des informations supplémentaires. La fenêtre pop-up Query Details (Détails de la requête) comprend les éléments suivants:

  • Une section Info contenant des détails sur la requête (voir le tableau suivant).
  • Section SQL qui affiche le code SQL brut qui a été exécuté sur la base de données. Les commentaires contextuels n'apparaîtront pas dans les détails de la requête. Pour éviter que les commentaires n'affectent la mise en cache des requêtes, Looker ajoute les commentaires contextuels aux commandes SQL sortantes juste avant l'envoi du code SQL à la base de données.
  • Un lien Ouvrir dans l'exécuteur SQL qui ouvrira la requête dans l'exécuteur SQL.

La section Infos contient les informations suivantes:

Section Définition
ID de l'historique ID de l'historique de la requête, le cas échéant.
État État de la requête, comme décrit ci-dessus.
Connexion Connexion Looker sous laquelle la requête a été exécutée.
Utilisateur Utilisateur qui a exécuté cette requête, si cela peut être déterminé. Certaines requêtes ne sont pas exécutées par un utilisateur spécifique, par exemple lorsque Looker crée une table dérivée persistante ou lorsqu'un utilisateur inconnu accède à un look public.
Source Source de la requête dans Looker, telle que la page Explorer ou l'exécuteur SQL. Si possible, des informations supplémentaires s'affichent, par exemple un lien vers le style enregistré, l'ID de la requête, le nom du modèle, le nom de la fonction Explorer, les champs sélectionnés, etc.
Start Time Heure de début de la requête, affichée dans le fuseau horaire de votre application.
Heure de fin Heure de fin de la requête, affichée dans le fuseau horaire de votre application.
Runtime Durée d'exécution de la requête.

Arrêt de requêtes

Looker arrête automatiquement une requête en cours d'exécution lorsque vous fermez l'onglet de navigateur dans lequel elle est exécutée. Les administrateurs Looker peuvent également arrêter une requête en cours d'exécution depuis la page Requêtes. Les utilisateurs disposant de l'autorisation see_queries peuvent afficher la page Requêtes, mais seuls les administrateurs Looker peuvent arrêter une requête en cours d'exécution. Toute requête en cours d'exécution affiche un bouton Arrêter à droite de la requête. Cliquez sur Arrêter pour arrêter la requête.

Pour que Looker supprime les requêtes, le dialecte de votre base de données doit prendre en charge l'arrêt des requêtes. La liste suivante indique les dialectes qui acceptent l'arrêt des requêtes dans la dernière version de Looker:

Délais d'expiration des requêtes et mise en file d'attente

Looker supprime les requêtes en attente depuis trop longtemps. Cette opération est appelée délai avant expiration. Plusieurs délais avant expiration peuvent s'appliquer à votre requête:

  • Expiration du pool de connexions : pour éviter la surcharge de votre base de données avec des requêtes simultanées, Looker contient les requêtes simultanées excédentaires dans la file d'attente des requêtes Looker et supprime les requêtes qui restent dans la file d'attente trop longtemps. Par défaut, 75 requêtes simultanées maximum sont autorisées par connexion et les requêtes en file d'attente expirent au bout de 0 seconde. Pour modifier ces valeurs par défaut, configurez les paramètres max connections (nombre maximal de connexions) et de connection poolDeadline (délai d'expiration du pool de connexions) sur la page Connections Settings (Paramètres de connexion) d'une connexion.

  • Limite de requêtes par utilisateur et délai avant expiration: pour empêcher tout utilisateur de remplir la file d'attente de requêtes Looker, chaque utilisateur dispose d'un nombre maximal de requêtes simultanées autorisées et d'un délai d'attente correspondant. Par défaut, chaque utilisateur peut exécuter jusqu'à 15 requêtes simultanées, et le délai d'attente pour les requêtes en attente en raison de cette limite est de 600 secondes. Si votre instance Looker est hébergée par le client, vous pouvez modifier ces valeurs par défaut en configurant les options de démarrage --per-user-query-limit et --per-user-query-timeout.

  • Limite et délai avant expiration de la requête du programmeur: pour éviter la surcharge du processus du programmeur Looker, une instance Looker peut exécuter un maximum de 10 requêtes simultanées programmées, et le délai avant expiration des requêtes dans la file d'attente du programmeur est de 1 200 secondes. Si votre instance Looker est hébergée par le client, vous pouvez modifier ces valeurs par défaut en configurant les options de démarrage --scheduler-query-limit et --scheduler-query-timeout.

    Si votre instance Looker est clusterée, chaque nœud du cluster utilise sa propre file d'attente de programmeurs. Ainsi, l'ajout de nœuds à votre cluster augmente le nombre total de requêtes programmées simultanées sans alourdir le processus du programmeur Looker.

  • Limite de requête et délai avant expiration du moteur de rendu: pour éviter la surcharge du processus de rendu Looker, une instance Looker peut afficher au maximum deux téléchargements simultanés d'images, tels que les formats PDF et PNG. Si votre instance Looker est hébergée par le client, vous pouvez modifier cette valeur par défaut en configurant l'option de démarrage --concurrent-render-jobs.

    Si votre instance Looker est clusterée, chaque nœud du cluster utilise sa propre file d'attente de moteur de rendu. Ainsi, l'ajout de nœuds à votre cluster augmente le nombre total de tâches de rendu simultanées autorisées sans alourdir le processus du moteur de rendu Looker.

  • Délai avant expiration du webhook: Looker tentera d'envoyer les données à un webhook pendant une durée maximale de 30 minutes. Si Looker ne parvient pas à communiquer avec la destination du webhook dans les 30 minutes, la requête expire. Ce délai avant expiration n'est pas configurable.

  • Délai avant expiration du proxy : les instances hébergées par Looker utilisent un proxy qui supprime toute requête exécutée depuis 60 minutes. Ce délai avant expiration n'est pas configurable.

    Les instances hébergées par le client utilisent souvent des proxys avec un délai d'expiration par défaut de 60 secondes. Nous vous recommandons de l'étendre à 60 minutes. Pour en savoir plus, consultez le post de la communauté Looker Exécuter Looker derrière un serveur proxy ou un équilibreur de charge.

  • Délai avant expiration de la base de données: la plupart des bases de données disposent de règles de mise en file d'attente et de délai d'expiration qui sont indépendantes des files d'attente et des délais d'expiration de Looker. Par exemple, une requête a peut-être quitté la file d'attente Looker, mais elle peut toujours être mise en file d'attente sur votre base de données. Consultez la documentation de votre base de données pour en savoir plus sur la personnalisation des délais avant expiration des requêtes de base de données.