E / S de disque à haute température lors de la réplication de fusion des BLOB

Avoir une publication de fusion pour répliquer les BLOB (type image), a obtenu des E / S de disque à très haute température pour ma taille de données. La publication est téléchargeable uniquement et ne comporte aucun filtre.

Les E / S de disque élevées sont causées par la synchronisation (quand aucun abonné ne se synchronise, tout va bien), fortement corrélée avec le nombre d'abonnés. Cela se produit même lorsqu'aucune donnée n'est modifiée chez Publisher entre les synchronisations, et cela me dérange.

• Taille du tableau répliqué: 7 Mo (le nombre total de lignes est d'environ 100)
• E / S tempdb: ~ 30 Mo / sec pour l'écriture (fichiers journaux et données)
• Nombre d'abonnés: un peu plus de 100, chacun se synchronisant toutes les 30 minutes (plus ou moins régulièrement).
• Durée de conservation fixée à 14 jours

Utilisation de SQL Server 2008 chez Publisher, SQL Server 2005-2008R2 chez les abonnés. Tous les abonnés utilisent la synchronisation Web.

De plus, la synchronisation chez l'abonné prend beaucoup de temps, avec plusieurs occurrences replmerg.logcomme celles-ci:

DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload     

DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload

Réglage @stream_blob_columnset mise en marche essayés sans effet.

La question est: est-ce une bonne idée d'utiliser la réplication de fusion pour envoyer ces objets blob aux abonnés? Nous avons d'autres publications (bien qu'elles n'aient pas de colonnes BLOB) avec beaucoup de données sans problème tempdb. Est-ce une faille SQL Server ou une mauvaise configuration?

L'éditeur et le distributeur sont sur la même instance, SQL Server 2008 SP4, ne peuvent pas être sûrs des abonnés, certains d'entre eux ne sont peut-être pas à jour. Quoi qu'il en soit, je peux préparer un environnement de test avec quelques abonnés ayant des versions contrôlées, si cela semble aider.

Confirmé, que l'utilisation excessive de tempdb causée par l'exécution de sys.sp_MSenumgenerations90. MSMerge_genhistoryTableau vérifié , trouvé plus de 1,2 millions d'enregistrements où pubidest nul.

Trouvé cette conversation avec le gourou de la réplication:

Exécuté sp_mergemetadataretentioncleanupsans effet.

Trouvé une remarque sur un cas comme celui-ci (trop de lignes MSmerge_genhistory) où la suppression de lignes où pubidest nul et genstatus= 1 a aidé à corriger la réplication.

Lignes supprimées où pubidest nul (ce qui implique que tous les abonnés sont synchronisés, et qui ne le sont pas - seront réinitialisés en "mode manuel") et le disque IO est de retour à la normale!

J'ai le sentiment que cette situation pourrait être causée par le fait que tous mes abonnés sont anonymes via WebSync et que la plupart d'entre eux ont le même nom d'hôte. Je vais essayer de vérifier si la -hostnameclé aide à ne pas multiplier les enregistrements MSmerge_genhistory.

Il existe un blog TechNet qui traite de certains problèmes de réplication de fusion avec des objets blob sur un serveur SQL Server 2008 ou supérieur.

http://blogs.technet.com/b/claudia_silva/archive/2011/10/31/replication-watch-out-for-stream-blob-columns-when-setting-up-replication-on-your-sql- 2008-server.aspx

Notez que l'auteur met en garde contre les paramètres à utiliser lorsqu'il existe des clients SQL Server 2005, tels que vous.

J'ai eu un problème similaire avec un serveur client dont la cause n'a pas pu être résolue. La quantité élevée d'E / S a ralenti le stockage et affecté plusieurs systèmes. Je ne peux pas fournir de solution pour résoudre la cause elle-même, mais il pourrait s'agir d'une option (temporaire) qui résout le problème résultant et vous donne plus de temps pour identifier et résoudre la cause.

Nous avons résolu le problème d'E / S en déplaçant le tempdb vers un ramdisk. Dans notre cas, nous avons dû agir rapidement, car d'autres systèmes sont devenus temporairement insensibles en raison de problèmes de performances. Au lieu de modifier le paramètre du serveur, nous avons copié les fichiers tempdb sur le disque virtuel, créé une sauvegarde des fichiers d'origine et les remplacé par des liens symboliques. Le ramdisk charge une image qui contient les fichiers tempdb. Les services sql ont été retardés pour être sûr que le disque virtuel a démarré et chargé l'image avant le démarrage du service sql. Le temps d'arrêt effectif pour passer du disque au ram a pris moins d'une minute.

Dans notre cas, nous avons considérablement amélioré les performances et résolu le problème de stockage. La solution fonctionne très bien pour notre client et est finalement devenue une solution permanente.

Brent définit pourquoi nous devons augmenter le fichier de données tempDb.vous pouvez vous référer au lien ci-dessous

https://www.brentozar.com/blitz/tempdb-data-files/