Meilleur auteur de réponses
SRRS2012 & Windows Server 2012

Question
-
Bonjour,
Voici mon infra :Vmware Vsphere Client 5.0
machine virtuel, core2, 8go mémoire, Windows Server 2012 rtm, Sql server2012
Voici mon problème:
J'ai effectué le test sur plusieurs machine et à chaque fois le même problème, dès que l'on met SSRS en place, par la suite nous avons de gros soucis de lenteur sur la machine, plus de 90% de charge utiliser sur la mémoire.
Quand je désactive le service Reports ça va un peu mieux mais toujours des lenteurs...
Alors qu'il n'y à aucun soucis sur la machine avec l'OS Windows Server 2012 sans SQL server 2012
Quelqu'un aurais eu le même soucis? une aide?
Merci d'avance
- Modifié todorovic.nicolas mercredi 21 novembre 2012 09:47
Réponses
-
La limite sur SQL Express n’est pas configurée.
C’est une limitation intérieure.
Plus de détails ici :http://msdn.microsoft.com/en-us/library/cc645993(v=SQL.110).aspx
Cordialement,
- Marqué comme réponse Florin Ciuca mardi 27 novembre 2012 20:32
Toutes les réponses
-
De quand date le dernier redémarrage ?
Résultat de:
WITH Waits AS (SELECT wait_type, wait_time_ms / 1000.0 AS WaitS, (wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS, signal_wait_time_ms / 1000.0 AS SignalS, waiting_tasks_count AS WaitCount, 100.0 * wait_time_ms / SUM (wait_time_ms) OVER() AS Percentage, ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS RowNum FROM sys.dm_os_wait_stats WHERE wait_type NOT IN ( 'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK', 'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH', 'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'BROKER_EVENTHANDLER', 'TRACEWRITE', 'FT_IFTSHC_MUTEX', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', 'BROKER_RECEIVE_WAITFOR', 'ONDEMAND_TASK_QUEUE', 'DBMIRROR_EVENTS_QUEUE', 'DBMIRRORING_CMD', 'BROKER_TRANSMITTER', 'SQLTRACE_WAIT_ENTRIES', 'SLEEP_BPOOL_FLUSH', 'SQLTRACE_LOCK') ) SELECT W1.wait_type AS WaitType, CAST (W1.WaitS AS DECIMAL(14, 2)) AS Wait_S, CAST (W1.ResourceS AS DECIMAL(14, 2)) AS Resource_S, CAST (W1.SignalS AS DECIMAL(14, 2)) AS Signal_S, W1.WaitCount AS WaitCount, CAST (W1.Percentage AS DECIMAL(4, 2)) AS Percentage, CAST ((W1.WaitS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgWait_S, CAST ((W1.ResourceS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgRes_S, CAST ((W1.SignalS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgSig_S FROM Waits AS W1 INNER JOIN Waits AS W2 ON W2.RowNum <= W1.RowNum GROUP BY W1.RowNum, W1.wait_type, W1.WaitS, W1.ResourceS, W1.SignalS, W1.WaitCount, W1.Percentage HAVING SUM (W2.Percentage) - W1.Percentage < 95; -- percentage threshold GO
David B.
-
Bonjour,
Merci pour la réponse, j'ai effectivement rebooté les machines plusieurs fois (dernière fois hier)
j'ai lancé votre requete SQL sur la base reports, voici le resultat :
WaitType ; Wait_S ; Resource_S ; Signal_S ; WaitCount; Percentage ; AvgWait_S ; AvgRes_S ; AvgSig_S
DIRTY_PAGE_POLL 358086.40 358079.87 6.54 3570122 49.94 0.1003 0.1003 0.0000
HADR_FILESTREAM_IOMGR_IOCOMPLETION 358062.07 358053.70 8.38 715526 49.94 0.5004 0.5004 0.0000Merci d'avance!
-
OK donc c'est une 2012 et les deux waits types sont à ignorer. Le reboot de l'instance vide les informations d'utilisation qui sont disponibles à travers les vues de performance, donc en général c'est une mauvaise option que de redémarrer en cas de problème. Difficile de faire un postmortem ensuite. En plus, toutes les pages de données et d'indexes contenues dans le cache ont été vidées, et tous les plans sont à recompiler, donc non seulement ça ne résout probablement pas le problème à l'origine, mais cela provoque des dommages collatéraux. Je ne parle même pas des transactions à rollbacker avant de mettre la base en ligne.
Il faudrait idéalement relancer la requête une fois que le problème apparaît de nouveau et surtout avant de redémarrer. Et également la requête suivante pour voir les blocages instantanés:
SELECT owt.session_id, owt.wait_duration_ms, owt.wait_type, owt.blocking_session_id, owt.resource_description, es.program_name, est.text, est.dbid, eqp.query_plan, es.cpu_time, es.memory_usage FROM sys.dm_os_waiting_tasks owt INNER JOIN sys.dm_exec_sessions es ON owt.session_id = es.session_id INNER JOIN sys.dm_exec_requests er ON es.session_id = er.session_id OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) est OUTER APPLY sys.dm_exec_query_plan (er.plan_handle) eqp WHERE es.is_user_process = 1; GO
David B.
-
Il y a quand même un endroit où les attentes sont persistées en SQL 2012:
(script emprunté à Paul Randal, http://www.sqlskills.com/blogs/paul/category/Extended-Events.aspx)
CREATE TABLE #RawEventData ( Rowid INT IDENTITY PRIMARY KEY, event_data XML); INSERT INTO #RawEventData (event_data) SELECT CAST (event_data AS XML) AS event_data FROM sys.fn_xe_file_target_read_file('E:\DENALI\MSSQL11.DENALI\MSSQL\Log\system_health_*', NULL, NULL, NULL); GO SELECT waits.[Wait Type], COUNT (*) AS [Wait Count], SUM (waits.[Duration]) AS [Total Wait Time (ms)], SUM (waits.[Duration]) - SUM (waits.[Signal Duration]) AS [Total Resource Wait Time (ms)], SUM (waits.[Signal Duration]) AS [Total Signal Wait Time (ms)] FROM (SELECT event_data.value ('(/event/@timestamp)[1]', 'DATETIME') AS [Time], event_data.value ('(/event/data[@name=''wait_type'']/text)[1]', 'VARCHAR(100)') AS [Wait Type], event_data.value ('(/event/data[@name=''opcode'']/text)[1]', 'VARCHAR(100)') AS [Op], event_data.value ('(/event/data[@name=''duration'']/value)[1]', 'BIGINT') AS [Duration], event_data.value ('(/event/data[@name=''signal_duration'']/value)[1]', 'BIGINT') AS [Signal Duration] FROM #RawEventData ) AS waits WHERE waits.[op] = 'End' GROUP BY waits.[Wait Type] ORDER BY [Total Wait Time (ms)] DESC; GO
DROP TABLE #RawEventData;
GO
A la place de E:\DENALI\MSSQL11.DENALI\MSSQL\Log\system_health_*, il faut mettre le chemin vers le répertoire de log de ton instance suivi de system_health_*. La requête peut être assez longue en fonction de la taille des fichiers de trace sur disque.
David B.
-
voici une seconde machine avec même probleme sans redemarage :
j'ai effectuer la deuxieme requete sur la base ReportServer ?? mais aucune réponses, elle est pourtant reussis...?
DIRTY_PAGE_POLL 105657.79 105655.62 2.16 1052853 49.96 0.1004 0.1004 0.0000 HADR_FILESTREAM_IOMGR_IOCOMPLETION 105651.94 105651.53 0.41 211205 49.95 0.5002 0.5002 0.0000 -
-
La requête renvoie quels sont les évènements sur lesquels SQL Server passe le plus de temps à attendre. Le WHERE NOT IN permet de filtrer les évènements qui sont considérés comme 'normaux', mais à chaque release de nouveaux évènements sont ajoutés et le filtre doit être enrichi ... (c'est le cas de DIRTY_PAGE_POLL et HADR_FILSTREAM_IOMGR_IOCOMPLETION en SQL Server 2012).
A chaque redémarrage les informations intéressantes sont perdues, c'est pourquoi le retour de cette requête ne renvoie rien d'intéressant dans ce cas précis.
Le second script bénéficie d'une nouveauté SQL Server 2012 qui va écrire les informations concernant les attentes dans un fichier sur disque (utilisation de sys.fn_xe_file_target_read_file('\Ton\Chemin\vers\MSSQLROOT\MSSQL11.DENALI\MSSQL\Log\system_health_*', NULL, NULL, NULL); ).
En résumé il faut :
- soit attendre que le problème se reproduise, et prendre une capture des attentes avant de décider de redémarrer (ce qui selon moi ne sert à rien).
- soit exécuter la seconde requête qui va chercher les mêmes informations mais sur disque.
David B.
- Proposé comme réponse David Baffaleuf mercredi 21 novembre 2012 16:23
-
-
-
-
oui oui le problème étais bien en cours, pour acquis de conscience j'ai refais le test ce matin avec de grosse lenteur sur la machine...
voici le resultat (est-ce grave docteur?):
Wait Type Wait Count Total Wait Time (ms) Total Resource Wait Time (ms) Total Signal Wait Time (ms)
BROKER_EVENTHANDLER 2 3382736982 3382736555 427Pour info je viens de m'appercevoir que MS à sorti le SP1, ça reglera peut être le soucis
je vous tiens au courant si jamais quelqu'un à eu le même problème...
Merci encore
-
OK donc la solution de rechercher les attentes dans les fichiers ne donne rien à priori. Je doute qu'un SP résolve un problème de perf, sauf dans le cas d'un bug mais c'est assez rare.
Il faudrait exécuter lorsque le problème est en cours:
SELECT owt.session_id, owt.wait_duration_ms, owt.wait_type, owt.blocking_session_id, owt.resource_description, es.program_name, est.text, est.dbid, eqp.query_plan, es.cpu_time, es.memory_usage FROM sys.dm_os_waiting_tasks owt INNER JOIN sys.dm_exec_sessions es ON owt.session_id = es.session_id INNER JOIN sys.dm_exec_requests er ON es.session_id = er.session_id OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) est OUTER APPLY sys.dm_exec_query_plan (er.plan_handle) eqp WHERE es.is_user_process = 1; GO
Et lorsque le problème est terminé et avant de redémarrer:
WITH Waits AS (SELECT wait_type, wait_time_ms / 1000.0 AS WaitS, (wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS, signal_wait_time_ms / 1000.0 AS SignalS, waiting_tasks_count AS WaitCount, 100.0 * wait_time_ms / SUM (wait_time_ms) OVER() AS Percentage, ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS RowNum FROM sys.dm_os_wait_stats WHERE wait_type NOT IN ( 'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK', 'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH', 'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'BROKER_EVENTHANDLER', 'TRACEWRITE', 'FT_IFTSHC_MUTEX', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', 'BROKER_RECEIVE_WAITFOR', 'ONDEMAND_TASK_QUEUE', 'DBMIRROR_EVENTS_QUEUE', 'DBMIRRORING_CMD', 'BROKER_TRANSMITTER', 'SQLTRACE_WAIT_ENTRIES', 'SLEEP_BPOOL_FLUSH', 'SQLTRACE_LOCK') ) SELECT W1.wait_type AS WaitType, CAST (W1.WaitS AS DECIMAL(14, 2)) AS Wait_S, CAST (W1.ResourceS AS DECIMAL(14, 2)) AS Resource_S, CAST (W1.SignalS AS DECIMAL(14, 2)) AS Signal_S, W1.WaitCount AS WaitCount, CAST (W1.Percentage AS DECIMAL(4, 2)) AS Percentage, CAST ((W1.WaitS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgWait_S, CAST ((W1.ResourceS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgRes_S, CAST ((W1.SignalS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgSig_S FROM Waits AS W1 INNER JOIN Waits AS W2 ON W2.RowNum <= W1.RowNum GROUP BY W1.RowNum, W1.wait_type, W1.WaitS, W1.ResourceS, W1.SignalS, W1.WaitCount, W1.Percentage HAVING SUM (W2.Percentage) - W1.Percentage < 95; -- percentage threshold GO
David B.
-
Pour la première requete aucun resultat tout est ok
Pour la seconde voici le resultat :
WaitType Wait_S Resource_S Signal_S WaitCount Percentage AvgWait_S AvgRes_S AvgSig_S
DIRTY_PAGE_POLL 170907.43 170903.15 4.27 1702371 49.97 0.1004 0.1004 0.0000
HADR_FILESTREAM_IOMGR_IOCOMPLETION 170902.25 170900.55 1.69 341601 49.96 0.5003 0.5003 0.0000Cordialement,
Nicolas
-
Si la première ne renvoie rien il n'y a pas de blocage, et la seconde ne renvoie pas d'attentes intéressantes non plus.
Regarder les compteurs perfmon suivants:
Mémoire\Mégaoctets Disponibles
Processus(sqlservr)\Octets Privés
Processus(sqlservr)\Plage de travailEt la valeur de 'max server memory':
exec sp_configure 'show advanced options',1 GO reconfigure GO exec sp_configure 'max server memory' GO
David B.
-
name minimum maximum config_value run_value
max server memory (MB) 128 2147483647 2147483647 2147483647dans le gestionnaire de tache 88% de la mémoire utilisé (7go/8go)
alors que personne ne travail dessus et aucun processus à part sql
processus sqlservr (Mémoire plage de travail privé) : 381 996
-
Il faut sampler exactement ces compteurs:
Processus(sqlservr)\Octets Privés
Processus(sqlservr)\Plage de travailet ces deux-ci en plus:
Fichier d'échange(_Total)\Pourcentage d'utilisation
SQL Server:Gestionnaire de tampons\Espérance de vie d'une pageDavid B.
-
ok :
sqlservr:
validation(Ko) 550 056
plage de travail(Ko) 424 044
Partageable(ko) 41 984
Privé(ko) 382 088
je ne vois pas de quoi tu veux parler pour :
Fichier d'échange(_Total)\Pourcentage d'utilisation
SQL Server:Gestionnaire de tampons\Espérance de vie d'une pageoù trouver l'info???
-
Bonjour,
Concernant Reporting Services as-tu regardé si les paramètres mémoire étaient bien configurés dans RSReportServer.config ? Je pense notamment au paramètre WorkingSetMaximum ... Par défaut Reporting Services peut utiliser toute la mémoire du serveur.
Concernant les compteurs données par David si tu es version anglaise tu dois pouvoir les retrouver sous la forme SQL Server:Buffer Manager\Life Page Expectancy et Paging File(_Total)\Percent Use ... A voir ce que donne ces résultats.
++
MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
-
-
A moins d'un coup de bol je ne pense pas que le SP1 soit à l'origine de la correction de ton problème de mémoire ... à voir
Concernant le fichier de configuration RSReportServer.config, dans la documentation MSDN vous avez ceci : "This setting does not appear in the RSReportServer.config file unless you add it manually."
Donc à vous de l'ajouter et de définir votre seuil
++
MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
-
Bonjour,
effectivement le SP1 n'a rien changer mais bon au moins il est installer
j'ai changer le fichier conf RSReportServer.config (mais pour moi ça me dit pas d'ou il viens...) et ça n'as rien changer...
<WorkingSetMinimum>0</WorkingSetMinimum>
<MemorySafetyMargin>60</MemorySafetyMargin>
<MemoryThreshold>90</MemoryThreshold>
<WorkingSetMaximum>5000000</WorkingSetMaximum>je recapitule memoire de la machine tourne continuellement à + de 80% (8go)
os windows server 2012 --> sql server 2012
Memoire acctuellement utilisé : 84%
sqlservr.exe:
validation(Ko) 550 056
plage de travail(Ko) 424 044
Partageable(ko) 41 984
Privé(ko) 382 088SQL Server:Gestionnaire de tampons\Espérance de vie d'une page dans l'analyseur de perf il me trouve une moyenne de : 1850(en augmantation constante) et une durée de 1:40
pour Fichier d'échange(_Total)\Pourcentage d'utilisation je ne trouve ça nul part ???
à savoir sur une machine similaire avec windows server 2012 et bien moins perfomante 3.5go de memoire par contre --> SQLExpress 2012
aucun soucis alors que les deux font le même job...???
A l'aide!
-
Faites attention, Sql Express 2012 est limitée à utiliser 1GO RAM.
En effet une utilisation de la mémoire n’est pas quelque chose exceptionnel.
Avez-vous considère des autres possibles problèmes (Operations I/O, etc) ?
Prenez quelques minutes pour lire ca :
http://blogs.msdn.com/b/askjay/archive/2011/07/08/troubleshooting-slow-disk-i-o-in-sql-server.aspx
Cordialement,
-
-
La limite sur SQL Express n’est pas configurée.
C’est une limitation intérieure.
Plus de détails ici :http://msdn.microsoft.com/en-us/library/cc645993(v=SQL.110).aspx
Cordialement,
- Marqué comme réponse Florin Ciuca mardi 27 novembre 2012 20:32
-
Bonjour,
Merci pour tenir la communauté informée sur la suite de vos démarches.
Bonne journée,