Outils de surveillance des performances pour la couche base de données
La plupart des moteurs de base de données d'entreprise qui peuvent être déployés avec ThingWorx fournissent de bons outils de surveillance et de détection des problèmes. Collaborez avec votre équipe DBA pour surveiller et analyser votre base de données, en complément de la surveillance côté application.
Vous trouverez ci-après quelques requêtes de détection de problèmes recommandées pour les bases de données PostgreSQL et Microsoft SQL. Ces bases de données d'entreprise sont celles qui sont les plus utilisées pour les données de modèle ThingWorx.
Postgres
Surveillez les mesures suivantes pour identifier les goulots d'étranglement des ressources sur le serveur PostgreSQL :
• Espace disque disponible
• Utilisation de l'UC
• Utilisation des E/S
Vous devez identifier et optimiser les requêtes de longue durée. Ces requêtes peuvent bloquer d'autres requêtes et augmenter les temps d'attente avant qu'une ressource ne soit à nouveau disponible. L'exécution des threads peut s'en trouver rallongée dans l'attente d'un verrou de base de données sur ThingWorx. Un verrou de base de données permet à une instruction individuelle de verrouiller l'état actuel de la ligne ou de la table. Un trop grand nombre de verrous affecte les performances de l'application.
Vous pouvez utiliser PSM pour détecter les requêtes de longue durée et les requêtes fréquemment exécutées.
MSSQL
Pour les bases de données Microsoft SQL, il est recommandé de collecter les statistiques de la base de données tous les soirs dans les environnements de production. De plus, il est important de vérifier les index pour déceler toute fragmentation élevée et les reconstruire si nécessaire, en particulier si la base de données ne s'exécute pas sur SSD. Les journaux des événements étendus MSSQL doivent être examinés régulièrement afin de détecter tout blocage ou toute attente de longue durée sur la base de données ThingWorx. Lors des périodes de ralentissement des performances, la requête suivante permet d'identifier les transactions en attente d'une ressource :
SELECT t.*,r.*, SUBSTRING(t.text, statement_start_offset/2 + 1,
(CASE WHEN statement_end_offset = -1
THEN LEN(CONVERT(nvarchar(max), t.text)) * 2
ELSE statement_end_offset
END - statement_start_offset) / 2)
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
Si une instruction apparaît suspendue ou s'exécute sur une durée plus longue que nécessaire, vérifiez les colonnes wait_type et wait_resource pour identifier la raison du temps d'attente.
Pour voir si l'instruction attend un verrou, identifiez l'ID de session et exécutez :
select * from sys.dm_tran_locks where session_id = 158