Quartznet: Pic de CPU de 40 % dû à une requête sur QRTZ_LOCKS

Pouvez-vous publier la configuration d'usine de votre planificateur (suppression des informations d'identification, etc.) ?

Sûr.

==== processeurOrdonnanceur ====

<scheduler name="processorScheduler">
<quartz>
  <property key="quartz.scheduler.instanceName" value="ProcessorScheduler" />
  <property key="quartz.scheduler.instanceId" value="AUTO" />
  <property key="quartz.scheduler.idleWaitTime" value="1000" />
  <property key="quartz.scheduler.exporter.type" value="Quartz.Simpl.RemotingSchedulerExporter, Quartz" />
  <property key="quartz.scheduler.exporter.port" value="1111" />
  <property key="quartz.scheduler.exporter.bindName" value="ProcessorScheduler" />
  <property key="quartz.scheduler.exporter.channelType" value="tcp" />
  <property key="quartz.scheduler.exporter.channelName" value="httpQuartz" />
  <property key="quartz.threadPool.type" value="Quartz.Simpl.DefaultThreadPool, Quartz" />
  <property key="quartz.threadPool.threadCount" value="20" />
  <property key="quartz.jobStore.type" value="Quartz.Impl.AdoJobStore.JobStoreTX, Quartz" />
  <property key="quartz.serializer.type" value="binary" />
  <property key="quartz.jobStore.clustered" value="true" />
  <property key="quartz.jobStore.clusterCheckinInterval" value="1000" />
  <property key="quartz.jobStore.misfireThreshold" value="60000" />
  <property key="quartz.jobStore.dataSource" value="default" />
  <property key="quartz.jobStore.driverDelegateType" value="Quartz.Impl.AdoJobStore.SqlServerDelegate, Quartz" />
  <property key="quartz.jobStore.tablePrefix" value="QRTZ_" />
  <property key="quartz.jobStore.useProperties" value="true" />
  <property key="quartz.dataSource.default.connectionString" value="Server=xxx;Database=quartz;user id=xxx;PWD=xxx;" />
  <property key="quartz.dataSource.default.provider" value="SqlServer" />
</quartz>
</scheduler>
<scheduler name="notificationScheduler">
<quartz>
  <property key="quartz.scheduler.instanceName" value="notificationScheduler" />
  <property key="quartz.scheduler.instanceId" value="notificationSchedulerInstance" />
  <property key="quartz.scheduler.proxy" value="true" />
  <property key="quartz.scheduler.proxy.address" value="tcp://xxx:2222/notificationScheduler" />
  <property key="quartz.threadPool.type" value="Quartz.Simpl.DefaultThreadPool, Quartz" />
  <property key="quartz.jobStore.type" value="Quartz.Impl.AdoJobStore.JobStoreTX, Quartz" />
  <property key="quartz.jobStore.misfireThreshold" value="60000" />
  <property key="quartz.jobStore.dataSource" value="default" />
  <property key="quartz.jobStore.driverDelegateType" value="Quartz.Impl.AdoJobStore.SqlServerDelegate, Quartz" />
  <property key="quartz.jobStore.lockHandler.type" value="Quartz.Impl.AdoJobStore.UpdateLockRowSemaphore, Quartz" />
  <property key="quartz.jobStore.tablePrefix" value="QRTZ_" />
  <property key="quartz.jobStore.useProperties" value="true" />
</quartz>
</scheduler>

==== planificateur de notifications ====

<scheduler name="notificationScheduler">
<quartz>
  <property key="quartz.scheduler.instanceName" value="notificationScheduler" />
  <property key="quartz.scheduler.instanceId" value="AUTO" />
  <property key="quartz.scheduler.idleWaitTime" value="1000" />
  <property key="quartz.scheduler.exporter.type" value="Quartz.Simpl.RemotingSchedulerExporter, Quartz" />
  <property key="quartz.scheduler.exporter.port" value="2222" />
  <property key="quartz.scheduler.exporter.bindName" value="notificationScheduler" />
  <property key="quartz.scheduler.exporter.channelType" value="tcp" />
  <property key="quartz.scheduler.exporter.channelName" value="httpQuartz" />
  <property key="quartz.threadPool.type" value="Quartz.Simpl.DefaultThreadPool, Quartz" />
  <property key="quartz.threadPool.threadCount" value="20" />
  <property key="quartz.jobStore.type" value="Quartz.Impl.AdoJobStore.JobStoreTX, Quartz" />
  <property key="quartz.serializer.type" value="binary" />
  <property key="quartz.jobStore.clustered" value="true" />
  <property key="quartz.jobStore.clusterCheckinInterval" value="1000" />
  <property key="quartz.jobStore.misfireThreshold" value="60000" />
  <property key="quartz.jobStore.dataSource" value="default" />
  <property key="quartz.jobStore.driverDelegateType" value="Quartz.Impl.AdoJobStore.SqlServerDelegate, Quartz" />
  <property key="quartz.jobStore.tablePrefix" value="QRTZ_" />
  <property key="quartz.jobStore.useProperties" value="true" />
  <property key="quartz.dataSource.default.connectionString" value="Server=xxx;Database=quartz;user id=xxx;PWD=xxx;" />
  <property key="quartz.dataSource.default.provider" value="SqlServer" />
</quartz>
</scheduler>

J'aurai besoin de temps pour enquêter, mais je suppose que le plus grand changement a été que la requête a été paramétrée, ce qui donne également l'impression d'être exécutée deux fois plus fréquemment si vous avez deux planificateurs distincts (auparavant, il y avait une chaîne SQL différente pour chacun de eux).

C'est exact, j'ai plusieurs planificateurs qui ont tous des configurations similaires à celles ci-dessus.
Merci de l'avoir examiné.

Salut Marko, touchant la base pour toute mise à jour ?

J'espère avoir le temps de travailler avec ce week-end. Je n'ai rien trouvé d'évident provoquant une telle régression des performances, mais je pense qu'il y a quelque chose entre 2.x et 3.x qui peut être amélioré.

Salut Marko, as-tu eu la monnaie de jeter un œil à ce pote ?

Désolé, pas de gros gains pour l'instant. J'en ai discuté avec SQL Server DBA et il n'a trouvé aucune raison évidente en testant, donc cela ne devrait pas être du côté de la base de données car il s'exécute sur la même page de base de données qui devrait être super rapide (petit nombre de lignes, deux colonnes) . Si vous avez le temps de profiler pour identifier quelque chose d'évident qui me manque, ce serait super.

Malheureusement, nous ne pouvons pas établir de profil. Mais, j'ai une autre idée à partager avec vous.
Avant le jour où nous avons publié notre application avec Quartz mis à jour, cette requête était exécutée 250 000 fois par jour. Juste après la sortie de Quartz v3.0.7, les temps d'exécution des requêtes sont passés à 350 000 fois par jour (un saut de 125 000). Notre trafic de données d'application n'a pas changé du tout.

De plus, nous avons remarqué que votre requête fait UPDLOCK, ROWLOCK sur une instruction SELECT, une raison pour laquelle elle doit le faire lorsqu'elle n'est pas mise à jour ? Je pense que si vous changez cela en NOLOCK, ce serait mieux.

SÉLECTIONNER *
DE QRTZ_LOCKS AVEC (UPDLOCK, ROWLOCK)
WHERE SCHED_NAME = @schedulerName
ET LOCK_NAME = @lockName

Quelque chose dans la v3.0.7 fait que cette requête s'exécute plus souvent.

Je viens de parler à nouveau à mon administrateur de base de données et il a creusé un peu plus et découvert dans l'ancienne version que cette requête UPDATE était utilisée pour être exécutée, et depuis la mise à niveau, cette requête a disparu et le nouveau SELECT ci-dessus est apparu.

Notez également que Sched_name sortait sous forme de texte et non de paramètre.

( @lockName nvarchar(14))
METTRE À JOUR QRTZ_LOCKS
DÉFINIR LOCK_NAME = LOCK_NAME
WHERE SCHED_NAME = 'MaintenanceScheduler' AND LOCK_NAME = @lockName

Et l'ancienne instruction SELECT était celle-ci par rapport à la nouvelle.

Avant le 27 janvier
( @lockName nvarchar(14))
SELECT * FROM QRTZ_LOCKS AVEC (UPDLOCK, ROWLOCK)
WHERE SCHED_NAME = 'Planificateur de maintenance'
ET LOCK_NAME = @lockName

J'espère que cela t'aides.

Merci pour la mise à jour et les informations.

De plus, nous avons remarqué que votre requête fait UPDLOCK, ROWLOCK sur une instruction SELECT, une raison pour laquelle elle doit le faire lorsqu'elle n'est pas mise à jour ? Je pense que si vous changez cela en NOLOCK, ce serait mieux.

Cela signifierait qu'il n'y aurait pas de verrous pour se protéger des accès concurrents, donc je n'irais pas là-bas 😉

Notez également que Sched_name sortait sous forme de texte et non de paramètre.

C'est le comportement exact qui était prévu après la fusion de #818. Vous devriez maintenant voir beaucoup plus de requêtes avec ce SQL exact si vous avez plusieurs planificateurs, ils utilisent tous le même plan de requête grâce à l'utilisation du paramètre de requête au lieu de coder en dur le nom du planificateur dans la requête, ce qui entraîne des plans différents.

Relisez votre configuration notificationScheduler :

<property key="quartz.jobStore.lockHandler.type" value="Quartz.Impl.AdoJobStore.UpdateLockRowSemaphore, Quartz" />

Cela l'empêchera d'utiliser l'instruction SQL optimisée destinée à SQL Server. Voir https://github.com/quartznet/quartznet/blob/f612e3f66ab27e221b5632269ef5c25c0fe8bcc5/src/Quartz/Impl/AdoJobStore/JobStoreSupport.cs#L492 -L521 pour la logique.

J'ai supprimé cette propriété et également mis à niveau vers la dernière version, vous permettra de savoir comment il se comporte.

Salut Marko, juste une mise à jour. Le processeur est revenu à un comportement normal après les mises à jour ci-dessus.
Merci pour ton aide l'ami.

Super à entendre, merci d'avoir bouclé la boucle.