Analisando problemas de performance – Um estudo de caso (Parte 1,5 de 4)



Parte 1,5: Contadores de performance


 


Estamos de volta, agora com um artigo surpresa! Antes de publicar a análise do cenário descrito no primeiro artigo da série, preferi disponibilizar os valores recomendados para alguns contadores de performance. Esses valores foram publicados em um recente memorando interno e classificados como “customer ready”, portanto façam bom proveito...


 


 


NOTE: These are just general recommendations and not exact recommendations as every server/scenario is different. You must collect a baseline of data to compare values.


 


Counters within Performance Monitor


 


(1) Memory - "Available Mbytes"


Available MBytes is the amount of physical memory available to processes running on the computer, in Megabytes. Preferred value is >= 50 MB (depending upon what type of system it is).


 


(2) Memory - "Free System Page Table Entries" 


Free System Page Table Entries is the number of page table entries not currently in use by the system. If < 7000, consider removing /3GB or using /userva as per KB 316739 (http://support.microsoft.com/kb/316739)



(3) Memory - "Pages/Sec" 


Pages/sec is the rate at which pages are read from or written to disk to resolve hard page faults. This counter is a primary indicator of the kinds of faults that cause system-wide delays. Investigate if over 100 pages per second on a system with a slow disk, usually even 500 pages per second on a system with a fast disk subsystem may not be an issue.


Note:


·         Values of >20 pages that appear in many other sources of documentation are out of date.


·         A high value for the Memory - "Pages/sec" counter does not necessarily indicate memory pressure or a System Monitor reporting error. To gain an accurate reading of your system, you must also monitor other counters (Pages Input/Sec, %Usage, %Usage Peak). See KB 889654 (http://support.microsoft.com/kb/889654)


 


(4) Processor - "%Processor Time"


% Processor Time is the percentage of elapsed time that the processor spends to execute a non-Idle thread. Preferred value < 80% sustained.


 


(5) PhysicalDisk - "Avg. Disk Sec/Read"


Avg. Disk sec/Read is the average time, in seconds, of a read of data from the disk.


 


Excellent <  8 Msec   
Good  <  12 Msec   
Fair  <  20 Msec   
Poor  >  20 Msec


 


(6) PhysicalDisk - "Avg. Disk sec/Write"


Avg. Disk sec/Write is the average time, in seconds, of a write of data to the disk.


 


Non cached Writes
-----------------
Excellent <  8 Msec  
Good  <  12 Msec   
Fair  <  20 Msec   
Poor  >  20 Msec   


 


Cached Writes Only
-------------------
Excellent <  1 Msec   
Good  <  2 Msec   
Fair  <  4 Msec  
Poor  >  4 Msec


 


(7) SQL Server:Buffer Manager - "Buffer Cache hit ratio"


This counter indicates how often SQL Server goes to the buffer, not the hard disk, to get data. The higher this ratio, the less often SQL Server has to go to the hard disk to fetch data, and performance overall is boosted. Unlike many of the other counters available for monitoring SQL Server, this counter averages the Buffer Cache Hit Ratio from the time the last instance of SQL Server was restarted. In other words, this counter is not a real-time measurement, but an average of all the days since SQL Server was last restarted.


 


In OLTP applications, this ratio should exceed 90-95%. If it doesn't, then you need to add more RAM to your server to increase performance. In OLAP applications, the ratio could be much less because of the nature of how OLAP works. In any case, more RAM should increase the performance of SQL Server OLAP activity.


 


 (8) SQL Server:Buffer Manager - "Page Life Expectancy"


This performance monitor counter tells you, on average, how long data pages are staying in the buffer. If this value gets below 300 seconds, this is a potential indication that your SQL Server could use more memory in order to boost performance.


 


(9) SQL Server:Buffer Manager - "Page reads/sec"


This counter indicates the number of physical database page reads issued. 80 – 90 per second is normal, anything that is above indicates indexing or memory constraint.


 


(10) SQL Server:Buffer Manager - "Page writes/sec"


This counter indicates the number of physical database page writes issued. 80 – 90 per second is normal, anything more we need to check the lazy writer/sec and checkpoint counters, if these counters are also relatively high then, it’s memory constraint.


 


(11) SQLServer:SQL Statistics - "SQL Compilations/sec" 


The number of times per second that SQL Server compilations have occurred. This value needs to be as low as possible. If you see a high value such as over 100, then it’s an indication that there are lots of adhoc queries that are running, might cause CPU usage, solution is to re-write these adhoc queries as stored procedure or use sp_executeSQL.



(12) SQLServer:Memory Manager - "Total Server Memory(KB)" 


The Total Server Memory is the current amount of memory that SQL Server is using. If this counter is still growing the server has not yet reached its steady-state, and it is still trying to populate the cache and get pages loaded into memory. Performance will likely be somewhat slower during this time since more disk I/O is required at this stage.  This behavior is normal.  Eventually Total Server Memory should approximate Target Server Memory.


 


 


Acredito que não preciso nem frisar a importância do texto destacado em vermelho, mas lá vamos nós novamente: POR FAVOR, não entenda os valores sugeridos como verdade absoluta, seja criterioso e faça sua análise através da comparação de diversos ambientes e baselines. Sempre baseie suas teses em mais de um contador, correlacionando-os.


 


E aí, algum palpite para o problema do nosso cliente? Até agora ninguém se arriscou...


Enquanto isso a empresa está perdendo dinheiro e cabeças poderão rolar...


 


Credo, que humor negro! J


 


[]s


Luciano Caixeta Moreira


luciano.moreira@microsoft.com


 


=============================================================


This posting is provided "AS IS" with no warranties, and confers no rights


=============================================================

20070711 - Analisando problemas de performance - Um estudo de caso (Parte 1.5 de 4).zip

Comments (3)

  1. Olá Luciano,

    Show de bola este artigo…. está aí uma coisa que normalmente se tem dificuldade em obter. Na maioria das vezes se falam dos contadores mas não informam um "valor base".

    abraços

    Nilton Pinheiro

  2. Ricardo Sanchez says:

    Concordo com o Nilton, não adianta nada decorar o que cada contador faz se não se sabe qual é o valor base pra ele.

    Ae o que vai contar mesmo é a experiência do analista, eu me baseio geralmente, olhando uma máquina semelhante que está funcionando bem, com a problemática, na maioria das vezes da certo mas outras… 🙁

    Ótimo artigo

    Abraço

  3. Agnaldo Silva says:

    -Você não especificou qual a Versão do SQL Server.

    -Supondo que seja 2005 standard.

    -Aplicar SP2, caso não esteja atualizado.

    -Você também não especificou se os Locks ocorrem nas tabelas temporarias.

    -Você também não especificou se os volumes estão em canais separados, e se a controladora possue Cache.

    -Sem analizar muito, eu trocaria o RAID 5 do G para RAID 10 e do I para RAID 1.

    – Caso os volumes G e I estejam montados no mesmo canal, sugiro uma controladora com dois canais e que sejam montados em canais separados.

    – Isolar o Tempdb em um volume separado, poderia ser o I.

    – Reconfigurar Max Degree of Paralellism para 1.

    – Reconfigurar Max worker thereads para 0.

    – Reconfigurar Filfactor para 80 para as tabelas que são atualizadas constantemente, e 90 ou 95 para tabelas de historicos se houver.

    -Isolar as tabelas que tenham grande concorrencia de acessos(leitura/gravação) em um arquivo de dados separado.

    -Monitorar as atividades do Banco de dados com Profile e analizar o resultado com Database Tuning Advisor, criar os Indices sugeridos.

    -Caso os Locks sejam nas tabelas temporarias, aumentar o numero  de arquivos no tempdb, 1 por processador, não levar em conta o HT, ativar o flag 1118, isso só depois de atualizar com SP2.

    -Alocar para o tempdb e para o banco de dados de produção um valor de espaço que evite a allocação automática.

    -Aumentar a Memória Fisica para 8GB.

    -Reconfigurar AWE enabled para 1.

    -Configurar /3G no boot.ini.

    -Criar Job que atualize as estatisticas de indices pelo menos 1 vez por dia.

Skip to main content