none
SRRS2012 & Windows Server 2012 RRS feed

  • 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



    mercredi 21 novembre 2012 09:42

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.

    mercredi 21 novembre 2012 13:08
  • 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.0000

    Merci d'avance!

    mercredi 21 novembre 2012 13:41
  • 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.

    mercredi 21 novembre 2012 14:27
  • 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.

    mercredi 21 novembre 2012 14:45
  • 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
    mercredi 21 novembre 2012 14:54
  • A quoi sert se script finalement, désolé un peut perdu...?
    mercredi 21 novembre 2012 14:55
  • 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.

    mercredi 21 novembre 2012 15:05
  • en cours d'execution...

    Merci pour les explications, je donnerais le resultat des que finis.

    mercredi 21 novembre 2012 15:29
  • voici le resultat :

    qu'en determine tu?

    Wait Type                             Wait Count Total Wait Time (ms) Total Resource Wait Time (ms) Total Signal Wait Time (ms)
    BROKER_EVENTHANDLER       2                3382736982             3382736555                          427

    mercredi 21 novembre 2012 15:49
  • Le problème est en cours ?

    David B.

    mercredi 21 novembre 2012 16:26
  • 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                                 427

    Pour 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

    jeudi 22 novembre 2012 08:39
  • 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.

    jeudi 22 novembre 2012 08:43
  • 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.0000

    Cordialement,

    Nicolas

    jeudi 22 novembre 2012 08:58
  • 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 travail

    Et 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.

    jeudi 22 novembre 2012 09:10
  • name                              minimum maximum          config_value              run_value
    max server memory (MB) 128         2147483647      2147483647     2147483647

    dans 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

    jeudi 22 novembre 2012 09:20
  • Il faut sampler exactement ces compteurs:

    Processus(sqlservr)\Octets Privés
    Processus(sqlservr)\Plage de travail

    et ces deux-ci en plus:
    Fichier d'échange(_Total)\Pourcentage d'utilisation
    SQL Server:Gestionnaire de tampons\Espérance de vie d'une page


    David B.

    jeudi 22 novembre 2012 09:28
  • 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 page

    où trouver l'info???

    jeudi 22 novembre 2012 09:34
  • 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

    jeudi 22 novembre 2012 10:09
    Modérateur
  • je n'ais pas se parametre la dans RSReportServer.conf

    j'ai :   <MemorySafetyMargin>80</MemorySafetyMargin>
             <MemoryThreshold>90</MemoryThreshold>

    pour info apres l'install du sp1 memoire utiliser 23% contre 88% avant...en cours de test encore

    jeudi 22 novembre 2012 10:24
  • 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

    jeudi 22 novembre 2012 11:14
    Modérateur
  • 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 088

    SQL 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!

    vendredi 23 novembre 2012 10:31
  • 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,


    Aurel BERA, Microsoft
    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    vendredi 23 novembre 2012 14:24
    Modérateur
  • Bonjour,

    merci pour votre réponse j'ai vais m'informer la dessus...

    une question :

    où se trouve la limtation de 1go de ram sur sql express? comment est elle configuré?

    Cordialement,

    Nicolas

    vendredi 23 novembre 2012 14:46