{"id":1411,"date":"2017-08-10T15:01:03","date_gmt":"2017-08-10T18:01:03","guid":{"rendered":"http:\/\/gianfratti.com\/?p=1411"},"modified":"2017-08-10T15:11:14","modified_gmt":"2017-08-10T18:11:14","slug":"asp-net-troubleshooting-agendando-a-coleta-de-um-dump-do-iis-por-alto-consumo-de-memoria","status":"publish","type":"post","link":"https:\/\/gianfratti.com\/index.php\/asp-net-troubleshooting-agendando-a-coleta-de-um-dump-do-iis-por-alto-consumo-de-memoria\/","title":{"rendered":"ASP.NET Troubleshooting: Agendando a coleta de um dump do IIS por alto consumo de mem\u00f3ria"},"content":{"rendered":"

Cen\u00e1rio<\/h1>\n

Um aplicativo ASP.NET hospedado no IIS est\u00e1 apresentando esporadicamente um alto consumo de mem\u00f3ria que n\u00e3o era esperado. Uma das formas de investigar o motivo deste alto consumo \u00e9 analisando um dump do processo w3wp.exe (para saber mais sobre an\u00e1lise de dump, consulte meu outro artigo \u2013 link<\/a>).<\/p>\n

O problema neste cen\u00e1rio \u00e9 que o \u201cesporadicamente\u201d dificulta que algu\u00e9m da TI obtenha manualmente um dump do processo w3wp.exe no momento em que o alto consumo se apresenta.<\/p>\n

Solu\u00e7\u00e3o<\/h1>\n

O aplicativo DebugDiag facilita o trabalho da TI na obten\u00e7\u00e3o de um dump de forma autom\u00e1tica, podendo por exemplo, monitorar o w3wp.exe para que na ocorr\u00eancia de um consumo de mem\u00f3ria acima do normal seja gerado um dump automaticamente.<\/p>\n

Abaixo mostro passo a passo como realizar este procedimento \u201cagendando\u201d a obten\u00e7\u00e3o de um dump quando o consumo de mem\u00f3ria atingir determinado patamar.<\/p>\n

Passo a passo<\/h1>\n

1) Fa\u00e7a o download e instale o Debug Diagnostic Tool da Microsoft \u2013 http:\/\/www.microsoft.com\/en-us\/download\/details.aspx?id=40336<\/a><\/p>\n

2) Executa o aplicativo DebugDiag e adicione uma nova regra (rule)<\/p>\n

\"\"<\/a><\/p>\n

3) Escolha a op\u00e7\u00e3o \u201cNative (non-.NET) Memory and Handle Leak\u201d<\/p>\n

\"\"<\/a><\/p>\n

4) Escolha o processo w3wp.exe (IIS) e clique em Avan\u00e7ar<\/p>\n

\"\"<\/a><\/p>\n

Observa\u00e7\u00e3o: caso voc\u00ea tenha mais de uma pool no IIS voc\u00ea ter\u00e1 mais de um processo w3wp.exe no servidor, para saber o ID do processo que quer tirar o dump \u00e9 poss\u00edvel faz\u00ea-lo de forma f\u00e1cil atrav\u00e9s do comando \u201cC:\\Windows\\System32\\inetsrv>appcmd list wp\u201d. Este comando ir\u00e1 listar o ID do processo e o nome da pool a qual ele est\u00e1 associado.<\/em><\/p>\n

5) Clique em \u201cConfigure\u201d para especificar o monitoramento por alto consumo de mem\u00f3ria<\/p>\n

\"\"<\/a><\/p>\n

6) Antes de configurar o par\u00e2metro de mem\u00f3ria \u00e9 interessante saber os limites de consumo de mem\u00f3ria conforme o ambiente. Neste caso, a tabela abaixo lista estes limites conforme o ambiente 32bits ou 64bits.<\/p>\n

\n\n\n\n\n\n\n\n
Process<\/th>\nWindows<\/th>\nAddressable memory (with a large address-aware process)<\/th>\nPractical limit for virtual bytes<\/th>\nPractical limit for private bytes<\/th>\n<\/tr>\n
32-bit<\/td>\n32-bit<\/td>\n2 GB<\/td>\n1400 MB<\/td>\n800 MB<\/td>\n<\/tr>\n
32-bit<\/td>\n32-bit with \/3GB<\/td>\n3 GB<\/td>\n2400 MB<\/td>\n1800 MB<\/td>\n<\/tr>\n
32-bit<\/td>\n64-bit<\/td>\n4 GB<\/td>\n3400 MB<\/td>\n2800 MB<\/td>\n<\/tr>\n
64-bit<\/td>\n64-bit<\/td>\n8 TB<\/td>\nNot applicable<\/td>\nNot applicable<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Fonte: http:\/\/www.iis.net\/learn\/troubleshoot\/performance-issues\/troubleshooting-native-memory-leak-in-an-iis-7x-application-pool<\/a><\/p>\n

Agora sabendo dos limites de mem\u00f3ria do seu ambiente, \u00e9 necess\u00e1rio configurar a regra conforme o consumo de mem\u00f3ria. Os passos a seguir descrevem esta configura\u00e7\u00e3o.<\/p>\n

7) Selecione \u201cGenerate a userdump when virtual bytes reach\u201d e defina um valor que fa\u00e7a sentido para o seu cen\u00e1rio \u201canormal\u201d de consumo de mem\u00f3ria. Por exemplo, na imagem abaixo defino que o dump seja gerado quando o processo atingir um consumo de 4GB de bytes virtuais, considerando que meu ambiente \u00e9 totalmente 64-bits (processo e Windows).<\/p>\n

\"\"<\/a><\/p>\n

8) Ap\u00f3s configurado, clique em \u201cSave & Close\u201d e ent\u00e3o em Avan\u00e7ar.<\/p>\n

9) Altere os dados sugeridos caso queira e ent\u00e3o clique em Avan\u00e7ar<\/p>\n

\"\"<\/a><\/p>\n

10) Deixe a op\u00e7\u00e3o \u201cActivate the rule now\u201d selecionada e clique em Concluir.<\/p>\n

\"\"<\/a><\/p>\n

11) A partir deste momento o DebugDiag ficar\u00e1 monitorando (tracking) o processo w3wp.exe.
\nAssim que o consumo de mem\u00f3ria especificado for atingido ele ir\u00e1 obter um \u201cdump\u201d do processo e armazenar na pasta configurada (Userdump Path).<\/p>\n

\"\"<\/a><\/p>\n

12) Pronto! Agora \u00e9 esperar que o alto consumo de mem\u00f3ria apare\u00e7a e o dump seja gerado. A coluna Userdump Count ir\u00e1 mostrar a quantidade de arquivos Dump gerados.<\/p>\n

Observa\u00e7\u00f5es importantes<\/h1>\n

1) A regra criada no DebugDiag s\u00f3 vale para o ID do processo criado no momento da regra, ou seja, ocorrendo a reciclagem do IIS o DebugDiag n\u00e3o conseguir\u00e1 monitorar o novo processo criado. Sendo assim, \u00e9 necess\u00e1rio recriar a regra no DebugDiag. Uma alternativa \u00e9 desativar a reciclagem at\u00e9 que se obtenha o dump.<\/p>\n

2) Ao iniciar o monitoramento do processo, o DebugDiag injeta a LeapTrack.dll no processo w3wp.exe para que seja rastreado a aloca\u00e7\u00e3o e libera\u00e7\u00e3o de mem\u00f3ria, o que pode afetar a performance do aplicativo.<\/p>\n

Conclus\u00e3o<\/h1>\n

O dump \u00e9 um importante recurso de investiga\u00e7\u00e3o de problemas em ambiente de produ\u00e7\u00e3o e h\u00e1 diversas ferramentas e t\u00e9cnicas para obt\u00ea-lo. A que mostrei aqui \u00e9 uma destas formas, permitindo que um dump seja obtido no momento certo sem interven\u00e7\u00e3o humana naquele momento. Querendo complementar ou mesmo tendo d\u00favidas n\u00e3o deixe de comentar.<\/p>\n

At\u00e9 mais!<\/p>\n

Rafael Leonhardt
\n@MumHaBR<\/p>\n

Refer\u00eancias<\/h1>\n

1) Debug Diagnostic 1.2 \u2013 Creating a Memory Leak rule (unmanaged code)
\nhttp:\/\/blogs.msdn.com\/b\/friis\/archive\/2012\/01\/04\/debug-diagnostic-1-2-creating-a-memory-leak-rule-unmanaged-code.aspx<\/a><\/p>\n

2) Troubleshooting native memory leak in an IIS 7.x Application Pool
\nhttp:\/\/www.iis.net\/learn\/troubleshoot\/performance-issues\/troubleshooting-native-memory-leak-in-an-iis-7x-application-pool<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Cen\u00e1rio Um aplicativo ASP.NET hospedado no IIS est\u00e1 apresentando esporadicamente um alto consumo de mem\u00f3ria que n\u00e3o era esperado. Uma das formas de investigar o motivo deste alto consumo \u00e9 analisando um dump do processo w3wp.exe (para saber mais sobre an\u00e1lise de dump, consulte meu outro artigo \u2013 link). O problema neste cen\u00e1rio \u00e9 que …<\/span> Read More →<\/span><\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[202,200],"tags":[],"class_list":["post-1411","post","type-post","status-publish","format-standard","hentry","category-iis","category-troubleshooting"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/1411","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/comments?post=1411"}],"version-history":[{"count":3,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/1411\/revisions"}],"predecessor-version":[{"id":1422,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/1411\/revisions\/1422"}],"wp:attachment":[{"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/media?parent=1411"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/categories?post=1411"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/tags?post=1411"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}