Lenteur des applications accédant à SQL SERVER 2016

Version imprimable

18/04/2019, 13h45
Mont73

Lenteur des applications accédant à SQL SERVER 2016

Bonjour,

Je me permets de poster ce petit message. Je n'ai trouvé de réponse sur la toile (peut-être que j'ai mal cherché ?).

A chaque redémarrage du serveur SQL SERVER, toutes les applications qui pointe dessus sont peu réactive.

J'ai regardé les performances du Server Hébergeant SQL SERVER. Je suis tombé sur une consommation poussé par le service SQL SERVER au niveau du process.
Aucun job ne se lance au démarrage de SQL SERVER.

Je n'arrive pas à voir plus d'information.

Je ne trouve pas la cause de cette monté en charge.

Je viens vous solliciter pour trouver la cause et une solution.
Merci d'avance,
18/04/2019, 14h03
SQLpro

1 pièce(s) jointe(s)

C'est parfaitement normal qu'au redémarrage les applications soient très lente. Il est d'ailleurs fortement déconseillé d'arrêter un serveur SQL que ce soit au niveau de la machine (physique ou virtuelle) comme au niveau du service.

En effet, un SGBDR de type client/serveur comme Oracle, SQL Server ou DB2, place le maximum de données en cache (donc en mémoire) pour éviter des accès disques. Toutes les requêtes, lectures comme écritures, sont donc réalisées en mémoire, avant d'être reportées ultérieurement sur le disque (de manière asynchrone).
En arrêtant votre serveur SQL, vous détruisez toute le mise en cache et recommencez par "bouffer" du disque au lieu d'accéder à la mémoire… Sachant que le disque est, au bas mot, 1000 fois moins rapide que la RAM, les lenteurs seront immédiatement visible par tous les utilisateurs.

En conclusion, un serveur SQL ne doit JAMAIS être arrêté !

Et pour apprendre bien des choses sur SQL Server, lisez notre livre :
Pièce jointe 468071

A +
18/04/2019, 16h38
Michel.Priori

Citation:

Envoyé par Mont73

Je suis tombé sur une consommation poussé par le service SQL SERVER au niveau du process.

et pas des disques ???

Il se passe beaucoup de choses pendant le (re)démarrage de SQL (recovery, reconstruction de Tempdb, allocation mémoire, audit, triggers, ...) mais tout ça est plus ou moins corrélé avec l'activité disque.
Il parait qu'il y a de bons livres ;)

Citation:

Envoyé par Mont73

Aucun job ne se lance au démarrage de SQL SERVER.

ça c'est normal ;)
Les jobs peuvent être planifiés pour démarrer au démarrage de l'agent. Et l'agent c'est pas SQL !
Si le redémarrage du serveur met le moteur à genoux, le fait de retarder le redémarrage de l'agent peut être un moyen de gérer les priorités.
19/04/2019, 06h32
Mont73

Citation:

Envoyé par SQLpro

C'est parfaitement normal qu'au redémarrage les applications soient très lente. Il est d'ailleurs fortement déconseillé d'arrêter un serveur SQL que ce soit au niveau de la machine (physique ou virtuelle) comme au niveau du service.

En effet, un SGBDR de type client/serveur comme Oracle, SQL Server ou DB2, place le maximum de données en cache (donc en mémoire) pour éviter des accès disques. Toutes les requêtes, lectures comme écritures, sont donc réalisées en mémoire, avant d'être reportées ultérieurement sur le disque (de manière asynchrone).
En arrêtant votre serveur SQL, vous détruisez toute le mise en cache et recommencez par "bouffer" du disque au lieu d'accéder à la mémoire… Sachant que le disque est, au bas mot, 1000 fois moins rapide que la RAM, les lenteurs seront immédiatement visible par tous les utilisateurs.

En conclusion, un serveur SQL ne doit JAMAIS être arrêté !

Et pour apprendre bien des choses sur SQL Server, lisez notre livre :
Pièce jointe 468071

A +

Bonjour,
Si je vous suis dans votre réflexion.
Le comportement est normal.

Et donc il ne faut pas mettre l'application sur le même serveur que la base de données.
Car la maintenance de l'application qui demanderait un reboot serveur pénaliserait les performances de la base de données au démarrage.

Merci de votre aide à la compréhension.

P.s. j'ai acheté le livre que vous citez mais j'ai pas encore eu le temps de le lire.
19/04/2019, 19h58
Michel.Priori

Citation:

Envoyé par Mont73

Et donc il ne faut pas mettre l'application sur le même serveur que la base de données.
Car la maintenance de l'application qui demanderait un reboot serveur pénaliserait les performances de la base de données au démarrage.

Comment justifier la position inverse ???

Ça parait évident que d'avoir 2 machines au lieu d'une permettra de bénéficier de plus de puissance (du delta près du réseau)
De plus d'un point de vue sécuritaire, la compromission du serveur applicatif (ça c'est déjà vu ;)) n'atteindra pas directement les données en base (à condition que les accès ne soient pas faits en tant qu'un Sysadmin bien sûr, et que ...plein de choses trop longues à lister ce soir)

Il ne faudra pas imaginez non plus que la séparation va complètement éviter les reboot de maintenance du serveur SQL dédié.

Quand vous parlez de :
* "ralentissement", c'est de quel ordre ?
* "toutes les applications qui pointent dessus", il y en a combien ?

Avez vous testé la consommation CPU et disque lors du redémarrage des applis avec SQL serveur éteint ?

Citation:

Envoyé par Mont73

Bonjour,
Si je vous suis dans votre réflexion.
Le comportement est normal.

oui

Citation:

Et donc il ne faut pas mettre l'application sur le même serveur que la base de données.

jamais et pas que pour cette raison...

Citation:

Car la maintenance de l'application qui demanderait un reboot serveur pénaliserait les performances de la base de données au démarrage.
....

En effet, car un SGBDR a un fonctionnement particulier qui est en opposition totale avec tous les autres applications.
1) c'est lui et non l'OS WIndows qui génère directement la RAM : i met en cache les données, les procédures, les plans d'exécution des requêtes, etc... Il n'y a donc que lui qui sait ou se trouve telle ou telle information; Dans SQL Server il y a près d'une centaine de niveaux de cache.... ! Vous pouvez voir cela à l'aide de la commande :

Code:

DBCC MEMORYSTATUS

2) c'est lui, et non l'OS Windows, qui gère les threads des différents utilisateurs, et pour un même utilisateurs les threads d'une même requête lorsqu'elle est parallélisée. Vous pouvez voir cela à l'aide de la commande :

Code:

SELECT * FROM sys.dm_os_threads

3) pour des raisons d'efficacité, c'est lui et non l'OS Windows, qui effectue les E/S (Entrées/Sorties - aussi appelées IO en anglais pour Input/Output) c'est à dire les lectures et écritures disque et RAM. Vous pouvez voir cela avec la commande :
Code:

1 2 3 4 SELECT DB_NAME(mf.database_id) as DATABASE_NAME, mf.name AS FILE_NAME, mf.physical_name AS FILE_LOCATION, vfs.* FROM sys.master_files AS mf CROSS APPLY sys.dm_io_virtual_file_stats(database_id, file_id) AS vfs
En conclusion, un SGBDR comme SQL Server ou Oracle ou IBM DB2 incorpore un OS et ne repose pas directement sur l'OS Windows pour la plupart des tâches, sauf pour l'accès au réseau.
Pour information, le nom de l'OS intégré à SQL Server est "SOS", c'est à dire Sql server Operating System... et c'est la raison pour laquelle vous trouverez de nombreuses vues systèmes qui contienne l'acronyme OS :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 dm_os_hosts dm_os_memory_brokers dm_os_memory_allocations dm_os_loaded_modules dm_os_memory_objects dm_os_schedulers dm_os_server_diagnostics_log_configurations dm_os_dispatcher_pools dm_os_threads dm_os_file_exists dm_os_waiting_tasks dm_os_sublatches dm_os_buffer_pool_extension_configuration dm_os_wait_stats dm_os_memory_node_access_stats dm_os_spinlock_stats dm_os_dispatchers dm_os_stacks dm_os_ring_buffers dm_os_volume_stats dm_os_memory_clerks dm_os_cluster_properties dm_os_child_instances dm_os_host_info dm_os_memory_broker_clerks dm_os_memory_cache_clock_hands dm_os_sys_memory dm_os_nodes dm_os_memory_cache_entries dm_os_virtual_address_dump dm_os_memory_cache_hash_tables dm_os_worker_local_storage dm_os_buffer_descriptors dm_os_enumerate_filesystem dm_os_memory_cache_counters dm_os_memory_pools dm_os_latch_stats dm_os_sys_info dm_os_performance_counters dm_os_workers dm_os_enumerate_fixed_drives dm_os_tasks dm_os_memory_nodes dm_os_windows_info dm_os_cluster_nodes dm_os_process_memory
Bien entendu l'OS de SQL Server agit en toute indépendance de l'OS Windows et SQL Server ne sait pas du tout ce que font les autres applications sous le contrôle de Windows... tant est si bien que SQL Server peut prendre tous les threads, monopoliser l'accès disque et capturer toute la mémoire au détriment de toutes les autres applications !
C'est pourquoi il faut un serveur dédié et donc aucune autres application d'aucune sorte (exécutable, service....) ne doit s'exécuter dessus !

A +