Перейти к содержимому

Как устранить утечку памяти

  • автор:

Устранение утечек памяти

Если вы разрабатываете приложения на Vue, тогда вам нужно следить за утечками памяти. Эта проблема особенно важна в одностраничных приложениях (SPA), потому что идея использования SPA состоит в отсутствии пользователям необходимости обновлять страницы браузера, поэтому задачей JavaScript приложения также будет и очистка в компонентах от лишнего.

Утечки памяти в приложениях Vue обычно не исходят от самого Vue, скорее они могут происходить при интеграции других библиотек в приложение.

Простой пример

В этом примере показана утечка памяти, вызванная использованием библиотеки Choices.js внутри компонента Vue без очистки ресурсов должным образом. Далее мы покажем как удалять остающееся после Choices.js и избежать утечки памяти.

В примере ниже, мы загружаем в select большое число вариантов выбора, а также используем кнопку для отображения/скрытия с помощью директивы v-if, чтобы добавлять и удалять список из виртуального DOM. Проблема в этом примере заключается в том, что директива v-if удаляет родительский элемент из DOM, но не выполняет дополнительную очистку DOM от частей, созданных Choices.js, что и вызывает утечку памяти.

link rel="stylesheet prefetch" href="https://joshuajohnson.co.uk/Choices/assets/styles/css/choices.min.css?version=3.0.3">
script src="https://joshuajohnson.co.uk/Choices/assets/scripts/dist/choices.min.js?version=3.0.3"> script>

div id="app"> 
button
 v-if="showChoices"
 @click="hide"
 >Скрыть button> 
button
 v-if="!showChoices"
 @click="show"
 >Показать button> 
div v-if="showChoices"> 
select id="choices-single-default"> select> 
div> 
div> 
new Vue({ 
el: "#app", 
data: function ( ) { 
return { 
showChoices: true 
} 
}, 
mounted: function ( ) { 
this.initializeChoices() 
}, 
methods: { 
initializeChoices: function ( ) { 
let list = [] 
// загружаем в наш select множество вариантов, 
// что вызовет большое использование памяти 
for (let i = 0; i < 1000; i++) { 
list.push({ 
label: "Item " + i, 
value: i 
}) 
} 
new Choices("#choices-single-default", { 
searchEnabled: true, 
removeItemButton: true, 
choices: list 
}) 
}, 
show: function ( ) { 
this.showChoices = true 
this.$nextTick(() => { 
this.initializeChoices() 
}) 
}, 
hide: function ( ) { 
this.showChoices = false 
} 
}
})

Чтобы увидеть эту утечку памяти в действии, откройте этот пример на CodePen с помощью Chrome и затем откройте Диспетчер задач Chrome. Чтобы открыть на Mac, выберите в верхнем меню > Окно > Диспетчер задач или на Windows с помощью сочетания клавиш Shift+Esc. Теперь, нажимайте кнопку показать/скрыть около 50 раз. Вы сможете увидеть увеличение использованной памяти в Диспетчере задач Chrome, которая не будет освобождена.

Пример утечки памяти

Исправление утечки памяти

В примере выше, мы можем использовать наш метод hide() для выполнения очистки и устранения утечки памяти перед удалением select из DOM. Для этого мы будем хранить свойство в нашем экземпляре Vue и будем использовать API плагина Choices в методе destroy() для выполнения необходимых операций очистки.

Проверьте использование памяти в обновлённом примере на CodePen.

new Vue({ 
el: "#app", 
data: function ( ) { 
return { 
showChoices: true, 
choicesSelect: null 
} 
}, 
mounted: function ( ) { 
this.initializeChoices() 
}, 
methods: { 
initializeChoices: function ( ) { 
let list = [] 
for (let i = 0; i < 1000; i++) { 
list.push({ 
label: "Item " + i, 
value: i 
}) 
} 
// Сохраняем ссылку на экземпляр плагина 
// в объекте data экземпляра Vue 
this.choicesSelect = new Choices("#choices-single-default", { 
searchEnabled: true, 
removeItemButton: true, 
choices: list 
}) 
}, 
show: function ( ) { 
this.showChoices = true 
this.$nextTick(() => { 
this.initializeChoices() 
}) 
}, 
hide: function ( ) { 
// теперь мы можем использовать ссылку на Choices 
// для выполнения необходимых плагину операций очистки 
// перед удалением элементов из DOM 
this.choicesSelect.destroy() 
this.showChoices = false 
} 
}
})

Подробнее о значимости

Управлением памятью и тестированием производительности часто легко можно пренебречь в спешке выпустить готовый продукт, но, тем не менее, сохранение небольшого количества используемой памяти по-прежнему важно для пользовательского опыта использования в целом.

Определите типы устройств, которые ваши пользователи могут использовать и какой сценарий работы с приложением может быть. Могут ли они использовать ноутбуки или мобильные устройства с небольшим количеством памяти? Будут ли ваши пользователи обычно совершать много переходов между страницами приложения? Если ответы на эти вопросы — «да», тогда хорошие практики управления памятью могут помочь избежать вам наихудшего сценария сбоя браузера пользователя. Даже если ни один ответ на вопрос не будет «да», вы по-прежнему можете ухудшить производительность вашего приложения при длительном использовании, если не будете осторожны.

Пример из жизни

В примере выше, мы использовали директиву v-if чтобы проиллюстрировать утечку памяти, но более распространённый сценарий из жизни возникает при использовании vue-router для маршрутизации по компонентам в одностраничном приложении (SPA).

Также, как и директива v-if , vue-router удаляет элементы из виртуального DOM и заменяет их новыми элементами при навигации пользователя по вашему приложению. Хук жизненного цикла beforeDestroy() — хорошее место для решения подобной проблемы в приложениях на основе vue-router .

Мы могли бы переместить нашу очистку в хук beforeDestroy() следующим образом:

beforeDestroy: function ( ) { 
this.choicesSelect.destroy()
}

Альтернативы

Мы обсудили управление памятью при удалении элементов, но что, если вы намеренно хотите сохранять состояние и сохранить элементы в памяти? В этом случае вы можете использовать встроенный компонент keep-alive.

Когда вы оборачиваете компонент с помощью keep-alive , его состояние будет сохранено, и следовательно, останется в памяти.

button @click="show = false">Скрыть button>
keep-alive> 
  
my-component v-if="show"> my-component> 
keep-alive>

Эта техника может быть полезна для улучшения пользовательского опыта работы с приложением. Например, представьте, что пользователь начинает вводить комментарий в текстовое поле и затем решает перейти на другую страницу. Если пользователь вернётся обратно, то его комментарий останется сохранён в поле.

С тех пор, как начнёте использовать keep-alive, у вас появится доступ к двум дополнительным хукам жизненного цикла: activated и deactivated . Если вы хотите выполнить очистку или изменить данные при удалении компонента с keep-alive, вы можете сделать это в хуке deactivated .

deactivated: function ( ) { 
// удаление любых данных, которые не требуется хранить
}

Подытожим

Vue позволяет легко разрабатывать потрясающие реактивные JavaScript-приложения, но вам всё равно нужно уделять внимание утечкам памяти. Эти утечки обычно происходят при использовании дополнительных сторонних библиотек, которые манипулируют DOM вне Vue. Не забудьте проверить ваше приложение на утечки памяти и предпринять соответствующие шаги для добавления необходимых очисток в компонентах, где это необходимо.

Обнаружили ошибку или хотите добавить что-то своё в документацию? Измените эту страницу на GitHub! Опубликовано на Netlify .

Как исправить утечку памяти?

@ВладимирМартьянов, если бы все было так просто. Когда переменной str присваивается новое значение, я теряю доступ к старому (в этом месте и есть утечка). Если вызвать free(str) до операции присваивания, то я не смогу получить значение перменной str .

30 авг 2016 в 15:34

А вы так не делайте, не перезаписывайте указатель на выделяемую память. И не освобождайте память, пока она вам нужна.

30 авг 2016 в 15:37
@ВладимирМартьянов, тогда каким образом переменная str получит новое значение?
30 авг 2016 в 15:40
@ВладимирМартьянов не проще код в ответ написать?
30 авг 2016 в 15:41

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

char * str = strrem("test_string", "s); //Ошибка синтаксиса, не соберется. str = strrem(str, "_");

Учитывая что strrem() выделяет память через calloc() и strrem() вызывается дважды, у вас должно быть ДВА указателя для хранения выделенной памяти, чтобы потом вызвать free() для обоих.

char* str = strrem(. ); char* ptr1 = str; str = strrem(. ); . //Тут аццкей кодес free(str); //освобождение от первого strrem free(ptr1); //освобождение от второго strrem

Отслеживать
ответ дан 30 авг 2016 в 16:13
Владимир Мартьянов Владимир Мартьянов
9,669 4 4 золотых знака 21 21 серебряный знак 36 36 бронзовых знаков

Так и не понял, что в точности strrem() делает со своими аргументами, но предположим, что на их основе создает некий результат (строку) в динамической памяти, который и возвращает.

При этом Вы не хотите освобождать память (вызывать free() ) первого аргумента внутри strrem() (возможно из-за того, что иногда это константа), не хотите писать «лишние» строчки кода, а всегда хотите иметь возможность использовать такую запись:

str = strrem(str, arg2);

и избежать утечек памяти.

Обобщая идею в ответе @Владимир Мартьянов, все это (в основном экономию строчек) можно реализовать примерно так:

char *str, *prev = 0; . str = strrem("xaxa", "xoxo"); . while (. ) < free(prev), prev = 0; // не забудьте обнулять, чтобы потом не упасть от повторного освобождения той же памяти str = strrem(prev = str, "abc"); . // кстати, тут доступны как старое (в prev), так и новое значения str >. free(str); free(prev); // поскольку мы обнуляем prev после free(prev), то это безопасно

Т.е. в тех местах, где Вы вызываете strrem() с аргументом, память которого далее должна быть освобождена, Вы сразу (в точке вызова) запоминаете этот адрес.

При желании (и имея перед глазами больше разных случаев использования strrem ) все такие вызовы с освобождением желательно оформить в виде макросов (при достаточном их разнообразии скорее всего переменную prev вообще удастся убрать с глаз долой).

Устранение неполадок утечки памяти или исключения нехватки памяти в BizTalk Server процесса

В этой статье описывается, как устранить утечку памяти или исключение нехватки памяти в BizTalk Server процесса microsoft BizTalk Server.

Исходная версия продукта: BizTalk Server 2010, 2009
Исходный номер базы знаний: 918643

Аннотация

Утечки памяти — распространенная проблема. Возможно, потребуется выполнить несколько действий, чтобы найти конкретную причину утечки памяти или исключения нехватки памяти (OOM) в Microsoft BizTalk Server. В этой статье рассматриваются важные моменты, которые следует учитывать при оценке использования памяти и возможных проблем, связанных с памятью. К этим рекомендациям относятся следующие аспекты:

  • Физическая ОЗУ
  • Обработка больших сообщений
  • Использование коммутатора /3 ГБ
  • Использование пользовательских компонентов
  • Какая версия microsoft платформа .NET Framework запущена система
  • Число процессоров

Процесс BizTalk Server может привести к утечке памяти, когда использование памяти в диспетчере задач Microsoft Windows потребляет более 50 процентов физической ОЗУ. Утечка памяти может привести к исключению нехватки памяти, когда использование памяти увеличивается до тех пор, пока процесс не прекратит работу системной памяти или пока процесс не прекратит работу. В этой проблеме учитывайте следующее:

Использование физического ОЗУ и памяти

Так как процесс может использовать около половины физического ОЗУ, используйте использование памяти в качестве рекомендации. Например, если BizTalk Server 4 ГБ ОЗУ, а процесс BizTalk Server использует около 500 МБ ОЗУ, утечка может не возникнуть. Если BizTalk Server использует около 1 ГБ ОЗУ, может возникнуть утечка памяти или высокая память. Потребление памяти может быть вызвано длительной хранимой процедурой или оркестрацией. Убедитесь, что вы знаете, какой объем памяти обычно использует хост BizTalk, чтобы определить, происходит ли утечка памяти или высокая память.

Большие сообщения

При BizTalk Server обработки больших сообщений в системе, похоже, происходит утечка памяти. Однако сообщения могут использовать большой объем памяти.

Кроме того, следует учитывать, что при обработке больших сообщений BizTalk Server может потребоваться высокая загрузка памяти. Может потребоваться обновить оборудование в соответствии с требованиями к производительности BizTalk Server в вашей среде.

Сколько времени требуется для воспроизведения утечки памяти

Утечки памяти могут произойти немедленно или накапливаться с течением времени. Оба сценария являются распространенными.

Использование параметра /3 ГБ на 32-разрядных компьютерах

Как правило, процесс может получить доступ к 2 ГБ виртуального адресного пространства. Коммутатор /3 ГБ — это вариант для систем, для которых требуется более адресная память. Этот параметр может улучшить использование памяти для обработки сообщений. Однако коммутатор /3 ГБ позволяет использовать только 1 ГБ адресируемой памяти для операций в режиме ядра. Кроме того, этот параметр может увеличить риск нехватки памяти пула.

Если переключатель /3 ГБ включен в 32-разрядной версии Windows, процесс может получить доступ к 3 ГБ виртуального адресного пространства, если процесс учитывает большие адреса. Процесс учитывает большой адрес, если исполняемый файл имеет флаг IMAGE_FILE_LARGE_ADDRESS_AWARE в заголовке образа. Так как процесс BizTalk поддерживает большие адреса, BizTalk будет использовать коммутатор /3 ГБ.

Если 32-разрядный экземпляр узла BizTalk работает в 64-разрядной версии Windows (AMD64), процесс BizTalk имеет преимущества из адресного пространства памяти размером 4 ГБ, так как BizTalk учитывает большие адреса. Поэтому оптимальным решением может быть перемещение приложений с высокой памятью на 64-разрядный сервер.

64-разрядный процесс BizTalk в 64-разрядной версии Windows (AMD64) имеет 8 ТБ адресируемой памяти.

Также следует учитывать виртуальные и частные байты, используемые процессом. Экземпляр узла BizTalk (который является приложением платформа .NET Framework) может получить ошибку нехватки памяти, прежде чем значение виртуальных байтов достигнет 2 ГБ. Такая ситуация может возникать, даже если максимальный объем памяти, адресируемый процессом в 32-разрядной версии Windows (без параметра /3 ГБ), составляет 2 ГБ. Объяснение причины такой ситуации см. на следующем веб-сайте Microsoft Developer Network (MSDN):
ASP.NET мониторинга производительности и оповещений администраторов

Параметр /3 ГБ также увеличивает максимальное число частных байтов процесса BizTalk с 800 МБ до 1800 МБ. Дополнительные сведения о производительности платформа .NET Framework с включенным параметром /3 ГБ см. в главе 17 . Настройка производительности приложений .NET.

В следующей таблице перечислены эти сведения и приведены практические ограничения для виртуальных и частных байтов.

Процесс Windows Адресируемая память (с большим процессом с учетом адресов) Практическое ограничение для виртуальных байтов Практическое ограничение для частных байтов
32-разрядная 32-разрядная 2 ГБ 1400 МБ 800 МБ
32-разрядная 32-разрядная версия с /3 ГБ 3 ГБ 2400 МБ 1800 МБ
32-разрядная 64-разрядная 4 ГБ 3400 МБ 2800 МБ
64-разрядная 64-разрядная 8 ТБ Неприменимо Неприменимо

Дополнительные сведения об адресируемой памяти для 32-разрядной и 64-разрядной версий Windows см. в разделе «Ограничения памяти» для выпусков Windows и Windows Server.

В следующей таблице перечислены поддерживаемые PAE и 3 ГБ для разных версий BizTalk Server.

Продукт Pae 3 ГБ
BizTalk Server 2004 г. Да Нет
BizTalk Server 2006 Да Да
BizTalk Server 2006 R2 Да Да
BizTalk Server 2009 Да Да

Если необходимо включить параметр /3 ГБ в соответствии с требованиями к производительности компьютера, на котором выполняется BizTalk Server, может потребоваться добавить серверы в группу BizTalk. Это позволяет масштабировать экземпляры узлов с большим объемом памяти.

Компоненты BizTalk, которые выполняются в процессе СЛУЖБ IIS, также могут использовать преимущества, если включен параметр /3 ГБ .

Коммутатор /3 ГБ не поддерживается на компьютерах под управлением Windows SharePoint Services версии 2.0 или более поздней или SharePoint Portal Server 2003 с пакетом обновления 2 (SP2) или более поздней версии. Коммутатор Windows Server 2003 /3GB не поддерживается в Windows SharePoint Services 2.0 или более поздних версиях или в SharePoint Portal Server 2003 с пакетом обновления 2 или более поздних версий.

Использование пользовательских компонентов

При использовании пользовательских компонентов, таких как конвейеры или компоненты службы, необходимо знать, что эти компоненты делать. Кроме того, следует знать, как эти компоненты могут влиять на использование памяти. Распространенная проблема с памятью возникает при преобразовании документа компонентом. Операция преобразования — это операция с большим объемом памяти. При преобразовании документа BizTalk Server передает поток сообщений в класс Microsoft платформа .NET Framework XslTransform в процессе BizTalk.

Еще одна распространенная проблема возникает при интенсивной обработке строк. Интенсивные операции со строками могут потреблять много памяти. Дополнительные сведения о способах повышения производительности см. в статье «Повышение производительности управляемого кода».

Версия платформа .NET Framework

Microsoft платформа .NET Framework 2.0 и платформа .NET Framework 1.1 имеют другое поведение памяти. Таким образом, между ними могут отображаться различные результаты. Если вы используете платформа .NET Framework, убедитесь, что установлена последняя платформа .NET Framework с пакетом обновления 1 (SP1). Эти пакеты обновления устраните несколько известных проблем с памятью.

Число процессоров

Среда CLR имеет следующие сборщики мусора (GC):

  • Рабочая станция (Mscorwks.dll)
  • Server (Mscorsvr.dll)

Если компьютер, на котором выполняется BizTalk Server является многопроцессерной системой, платформа .NET Framework использует серверную версию подсистемы выполнения. Это значение установлено по умолчанию. Сборщик мусора сервера предназначен для максимальной пропускной способности. Кроме того, сборщик мусора сервера масштабируется для обеспечения высокой производительности. Этот сборщик мусора выделяет память, а затем освобождает память для обеспечения высокой производительности системы. Таким образом, компьютер, на котором выполняется BizTalk Server вместе с некоторыми компонентами платформа .NET Framework, похоже, имеет утечку памяти. Однако в этом сценарии использование большого объема памяти является ожидаемым поведением. Если на компьютере заканчивается системная память или процесс перестает работать из-за нехватки адресируемой памяти, может возникнуть состояние утечки памяти.

Если компьютер, на котором выполняется BizTalk Server является системой с одним процессором, платформа .NET Framework использует версию рабочей станции подсистемы выполнения. Это поведение по умолчанию. Алгоритм распределения сборщика мусора рабочей станции не предназначен для масштабирования или максимальной пропускной способности. Этот сборщик мусора использует параллельные методы сборщика мусора. Эти методы предназначены для приложений со сложными пользовательскими интерфейсами. Такие приложения могут требовать более агрессивной сборки мусора.

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако при неправильном изменении реестра могут возникнуть серьезные проблемы. Поэтому убедитесь, что вы тщательно выполните эти действия. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Для получения дополнительной информации о том, как создать резервную копию и восстановить реестр, см. статью Сведения о резервном копировании и восстановлении реестра Windows.

Иногда может быть целесообразно запустить версию рабочей станции модуля выполнения в многопроцессерной системе. Следующий раздел реестра можно использовать для переключения на версию рабочей станции подсистемы выполнения.

BizTalk 2006 и более поздних версий

Создайте следующий раздел CRL Hosting реестра string с соответствующими значениями:

  • Ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • Имя значения: Flavor
  • Данные значения: wks

BizTalk 2004

Создайте следующий раздел CRL Host реестра string с соответствующими значениями:

  • Ключ: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc\CLR Hosting
  • Имя значения: Flavor
  • Данные значения: wks

Дополнительные сведения см. в разделе «Вопросы производительности Run-Time технологий в платформа .NET Framework.

Ниже приведены распространенные причины и способы их устранения.

Пороговые значения регулирования использования обработки и физической памяти

Пороговые значения регулирования использования памяти процесса и физической памяти можно изменить в BizTalk Server 2006 и более поздних версиях.

  • По умолчанию пороговое значение регулирования использования памяти процесса равно 25. Если это значение превышено и объем памяти процесса BizTalk превышает 300 МБ, может возникнуть условие регулирования. На 32-разрядном сервере можно увеличить значение использования памяти процесса до 50. На 64-разрядном сервере это значение можно увеличить до 100. Это позволяет более эффективно использовать память процессом BizTalk до того, как произойдет регулирование.
  • Пороговое значение регулирования использования физической памяти по умолчанию равно 0. Это пороговое значение измеряет общую системную память. Таким образом, если настроено значение, отличное от 0, может возникнуть условие регулирования, если процесс, отличный от BizTalk, использует большой объем памяти.

Пороговые значения регулирования для деконтратации

Пороговые значения расконсервации памяти по умолчанию могут привести к слишком большой деконтратации при выполнении оркестрационных операций на 64-разрядном узле. Дополнительные сведения об этой проблеме см. в разделе «Свойства десервации по умолчанию».

64-разрядные узлы поддерживаются в BizTalk Server 2006 и более поздних версиях.

На эквивалентном оборудовании в 32-разрядном экземпляре узла наблюдаемое девратация является номинальной, если те же оркестрации выполняются с использованием пороговых значений регулирования деконтратации памяти по умолчанию.

Так как 64-разрядная архитектура предоставляет расширенное адресное пространство памяти (16 ТБ вместо 4 ГБ), 64-разрядным экземплярам узла выделяется больше памяти, чем 32-разрядным экземплярам узла. Это может привести к превышению пороговых значений регулирования памяти по умолчанию.

Чтобы обойти это поведение, измените значения VirtualMemoryThrottlingCriteria и PrivateMemoryThrottlingCriteria в BTSNTSvc64.exe.config файле. Используйте счетчики \Process\Virtual Bytes и \Process\Private Bytes Монитор производительности, чтобы определить максимальный объем памяти, выделяемой экземпляром оркестрации.

  • Задайте значение OptimalUsage для обоих свойств на основе следующих значений:
    • VirtualMemoryThrottlingCriteria: \Process\Virtual Bytes value + 10%
    • PrivateMemoryThrottlingCriteria: \Process\Private Bytes value + 10%

    Например, Если значение счетчика \Process\Virtual Byte Монитор производительности для экземпляра оркестрации равно 5 784 787 695 байт (5517 МБ), установите значение OptimalUsage для VirtualMemoryThrottling. До 6069 МБ (5 784 787 695 * 1,10 = 6 363 266 464,5 байт).

    Задайте значение MaximalUsage для VirtualMemoryThrottlingCriteria в 7889 МБ (6 363 266 464,5 * 1,30 = 8 272 246 403,85 байт).

    Если значение счетчика \Process\Private Bytes Монитор производительности равно 435689400 байтам (415 МБ), задайте для параметра OptimalUsage значение PrivateMemoryThrottlingCriteria в 457 МБ (435689400 * 1,10 = 479258340 байт).

    Задайте значение MaximalUsage для PrivateMemoryThrottlingCriteria в 594 МБ (479258340 * 1,30 = 623035842).

    В этом примере в файле BTSNTSvc64.exe.config для уменьшения регулирования будут указаны следующие значения.

    Монитор производительности счетчика Выделенная память OptimalUsage MaximalUsage
    \Process\Virtual Bytes 5784 787 695 байт (5517 МБ) 6069 7889
    \Process\Private Bytes 435 689 400 байт (415 МБ) 457 594

    Затем эти значения будут представлены в BTSNTSvc64.exe.config файле следующим образом:

    Чтобы определить, какой экземпляр узла выполняет оркестрацию, можно сопоставить процесс идентификатора из счетчиков \BizTalk: Messaging\ID Process и \Process\ID Process Монитор производительности. Затем проверьте среднее значение, отображаемое для соответствующих счетчиков \Process\Virtual Bytes и \Process\Private Bytes Монитор производительности.

    Сведения, которые пользователь должен заметить, даже если skimmingThe high dehydration может BizTalkMsgBoxDb привести к значительному снижению производительности при работе базы данных SQL Server 2008.

    BizTalk Server пакетов обновления и накопительных обновлений

    BizTalk Server пакеты обновления и накопительные обновления включают последние исправления. К ним относятся те, которые влияют на известные System.OutOfMemoryException проблемы.

    HeapDeCommitFreeBlockThreshold

    По умолчанию значение раздела HeapDeCommitFreeBlockThreshold реестра равно 0. Значение 0 означает, что диспетчер кучи отменит фиксацию каждой 4-килобайтной страницы (КБ), которая становится доступной. Операции дефиксации могут привести к фрагментации виртуальной памяти. Размер параметра в HeapDeCommitFreeBlockThreshold диспетчере кучи будет зависеть от типа работы, которую выполняет система. Рекомендуемый начальный 0x00040000 размера.

    Перед изменением HeapDeCommitFreeBlockThreshold значения раздела реестра учитывайте следующие сведения:

    • Это изменение относится только к проблемам фрагментации памяти.
    • Это изменение выполняется на уровне системы. Таким образом, большинство процессов будут использовать больше памяти при запуске.
    • Это изменение следует учитывать только для систем, BizTalk Server их основной задачей.

    Чтобы уменьшить фрагментацию виртуальной памяти, HeapDeCommitFreeBlockThreshold можно увеличить размер параметра в диспетчере кучи, изменив значение следующего раздела реестра в следующем разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager :

    • Имя значения: HeapDeCommitFreeBlockThreshold
    • Тип значения: REG_DWORD
    • Данные значения: 0x00040000 (рекомендуемое начальное значение).)
    • Значение по умолчанию: отсутствует

    Операции преобразования

    Когда BizTalk Server XML-преобразование для довольно больших сообщений в порту получения, XLANG в порте отправки или в XSL-преобразованиях загружается все сообщение в память.

    Для решения этой проблемы воспользуйтесь одним из указанных ниже способов.

    • Уменьшите количество сообщений, которые BizTalk Server одновременно.
    • Уменьшите размер преобразуемого XML-сообщения.

    Объект System.Policy.Security.Evidence часто используется в преобразованиях и может потреблять много памяти. Если карта содержит скрипты functoid , использующие встроенный язык C# (или любой другой встроенный язык), сборка создается в памяти. Объект System.Policy.Security.Evidence использует объект фактической вызываемой сборки. В этой ситуации создается корневой объект, который не удаляется до перезапуска службы BizTalk.

    Большая часть bizTalk functoids по умолчанию реализована в виде встроенного скрипта. Эти элементы могут привести к сбору System.Byte[] объектов в памяти. Чтобы свести к минимуму потребление памяти, рекомендуется поместить любую карту, использующую их, functoids в небольшую сборку. Затем сослаться на эту сборку. Используйте следующую диаграмму, чтобы определить, какой functoids из встроенных сценариев используется, functoids а какой — нет.

    Во втором столбце «Да functoid » означает, что он реализуется как встроенный скрипт и System.Byte[] что объекты будут собираться в памяти. Нет означает, что functoid он не реализован как встроенный скрипт и System.Byte[] не приведет к сбору объектов в памяти.

    Функоиды Встроенный скрипт?
    Все строковые функоиды Да
    Все математические функоиды Да
    Все логические функоиды, кроме IsNil Да
    Логический функтоид IsNil Нет
    Все функоиды даты и времени Да
    Все функоиды преобразования Да
    Все научных функоидов Да
    Все интегральная функоиды Да
    Все функоиды базы данных Нет
    Расширенные функоиды Встроенный скрипт?
    Циклический функоид Нет
    Value-Mapping преобразования в плоскую структуру Нет
    Assert Functoid Нет
    Functoid средства извлечения таблиц Нет
    Функоид циклического цикла таблицы Нет
    Создание скриптов functoid с помощью встроенного кода C # Да
    Создание скриптов functoid с помощью встроенных JScript.NET Да
    Создание скриптов functoid с помощью встроенной версии Visual Basic .NET Да
    Создание скриптов functoid с помощью встроенного XSLT Нет
    Создание скриптов для functoid с помощью встроенного шаблона вызова XSLT Нет
    Создание скриптов для functoid, вызывающего внешнюю сборку Нет
    Nil Value Functoid Нет
    Функоид сопоставления значений Нет
    Функоид массового копирования Нет
    Функтоид итерации Нет
    Функоид индекса Нет
    Функоид счетчика записей Нет

    BizTalk Server 2006 и более поздних версий значительно улучшает управление памятью для больших документов. Для этого BizTalk Server пороговое значение размера сообщения для загрузки документов в память во время операций преобразования. Пороговое значение размера сообщения по умолчанию — 1 МБ. Дополнительные сведения о параметре TransformThreshold см. в BizTalk Server обработки больших сообщений.

    Большие значения атрибутов и значения больших элементов

    Когда BizTalk Server конвейер получения или конвейер отправки в XML-документе, полезные данные обрабатываются в памяти, если документ содержит одну или несколько из следующих сущностей:

    • Большие значения атрибутов
    • Значения больших элементов
    • Теги больших атрибутов или элементов

    Чтобы устранить эту проблему, ограничьте размер этих сущностей. Если этот метод невозможен, убедитесь, что экземпляр BizTalk HOST не обрабатывает несколько документов, таких как они, одновременно.

    Компоненты настраиваемого конвейера

    Вы используете пользовательский компонент конвейера, который загружает весь поток в память. Все компоненты, включенные в BizTalk Server, за исключением преобразований, поддерживают потоковую передачу. Эти компоненты не используют столько памяти во время потоковой передачи. Однако пользовательские компоненты конвейера могут не поддерживать потоковую передачу.

    Потоковая передача в условиях сильной нагрузки

    При работе в условиях интенсивной нагрузки на узлах недостаточно памяти. BizTalk Server отправляет конвейеры и адаптеры, поддерживающие потоковую передачу. При потоковой передаче каждый компонент загружает небольшой фрагмент потока в память. Так как каждое сообщение содержит другие структуры данных вместе с контекстом сообщения, который может быть значительным или небольшим, это поведение влияет на поведение BizTalk Server сильной нагрузкой.

    Это влияет BizTalk Server, так как подсистема загружает предварительно настроенное количество сообщений. Количество сообщений, загружаемых обработчиком, зависит от значений, которые отображаются в полях LowWaterMark и HighWaterMark таблицы Adm_serviceClass . Таблица Adm_serviceClass находится в базе данных управления BizTalk. Эти значения могут управлять количеством сообщений, которые BizTalk Server одновременно обрабатывают или отправляются.

    Значение HighWaterMark — это общее количество сообщений, обрабатываемое обработчиком одновременно. Значение по умолчанию — 200 сообщений на ЦП. Таким образом, на сервере с 8 процессорами хост-сервер отправки попытается обработать 1600 сообщений (200 * 8) одновременно.

    Если предполагается, что каждое сообщение имеет размер 50 КБ, оно равно 80 МБ (1600 * 50=80 000 КБ).

    Чтобы устранить эту проблему, можно изменить значения HighWaterMark и LowWaterMark в базе данных. Значения, которые вы используете, зависят от размера сообщений. В BizTalk Server 2006 и более поздних версий можно изменить параметры регулирования узла по умолчанию.

    Попробуйте упростить проблему

    Если вы обнаружили утечку памяти, попробуйте определить причину, удалив пользовательские компоненты или упростив карту. Кроме того, попробуйте воспроизвести проблему с помощью простой оркестрации или простого решения. Как правило, для адаптеров получения следует создавать отдельные узлы получения. Также следует создать отдельные узлы отправки для адаптеров отправки. При использовании этого метода каждый адаптер может выполняться в отдельном процессе. Таким образом, если BizTalk Server процесс имеет состояние нехватки памяти, вы будете знать, какие компоненты задействованы.

    Действия по устранению неполадок

    Чтобы устранить проблему нехватки памяти, используйте средство диагностики отладки для отслеживания выделения памяти с течением времени. Средство диагностики отладки может создавать и анализировать файл дампа утечки памяти (DMP). При устранении неполадок с утечками памяти необходимо присоединить Leaktrack.dll, прежде чем состояние высокой памяти воспроизведется для отслеживания роста памяти с течением времени. Leaktrack.dll включен в средство диагностики отладки.

    1. Установите средство диагностики отладки. Следующий файл доступен для скачивания из Центра загрузки Майкрософт:
      Скачайте пакет средства диагностики отладки Дополнительные сведения о том, как скачать файлы службы поддержки Майкрософт, см. в статье о том, как получить файлы поддержки Майкрософт из веб-службы. Корпорация Майкрософт сканирует этот файл на наличие вирусов. Корпорация Майкрософт использовала самое последнее программное обеспечение для обнаружения вирусов, которое было доступно на дату публикации файла. Файл хранится на серверах с усиленной безопасностью, которые помогают предотвратить несанкционированные изменения в файле.
    2. Используйте Монитор производительности для сбора данных о производительности системы. Эти данные могут предоставлять важные индикаторы эффективности вашей BizTalk Server среды. Целью является отслеживание производительности процесса с течением времени. Поэтому включите Монитор производительности журнала перед утечкой памяти.

    Как использовать Монитор производительности ведения журнала

    В следующих разделах описывается, как использовать ведение журнала монитора производительности.

    Выбор данных для записи в журнал

    Чтобы выбрать данные для записи в журнал, используйте подходящий для вашей операционной системы метод:

    • Для Windows Server 2008 и Windows Server 2008 R2
    • В средствах администрирования откройте функцию надежности и Монитор производительности.
    • Щелкните правой кнопкой мыши Монитор производительностикнопку «Создать«, а затем выберите «Набор сборщиков данных».
    • В поле «Имя » введите описательное имя и нажмите кнопку » Далее».
    • Запишите корневой каталог и нажмите кнопку » Далее».
    • Нажмите кнопку «Запустить этот набор сборщиков данных» и нажмите кнопку «Готово».
    • Разверните наборы сборщиков данных, разверните узел «Определяемый пользователем» и выберите файл.
    • Щелкните правой кнопкой мыши журнал системного монитора и выберите пункт «Свойства».
    • Нажмите кнопку « Добавить» на вкладке «Счетчики производительности «. Выберите следующие объекты и нажмите кнопку « Добавить» после выбора каждого объекта:
      • Исключения среды CLR .NET
      • Память СРЕДЫ CLR .NET
      • BizTalk: обмен сообщениями
      • BizTalk: TDDS
      • Память
      • Процесс
      • Процессор
      • Оркестрации XLANG/s

      Если SQL Server локальный, добавьте следующие объекты:

      • SQLServer: базы данных
      • SQLServer: общая статистика
      • SQLServer: диспетчер памяти

      Примечание. Значение интервала выборки и время начала отслеживания являются неоховеданным. Эти значения зависят от воспроизведения утечки памяти. Так как файл журнала может быть большим, укажите интервал, в который можно получить сведения, которые должны быть у вас без перегрузки сервера.

      Чтобы остановить сбор данных, щелкните » Остановить » в меню «Действие «.

      • Для Windows Server 2003 или Windows XP
      • Разверните журналы производительности и оповещения.
      • Щелкните правой кнопкой мыши журналы счетчиков и выберите команду «Создать параметры журнала». Появится диалоговое окно «Новые параметры журнала».
      • В поле «Имя » введите описательное имя и нажмите кнопку » ОК».
      • Запишите расположение файла журнала. (Вы также можете щелкнуть вкладку «Файлы журнала» и выбрать команду «Настроить», чтобы изменить расположение файла журнала.)
      • Нажмите кнопку «Добавить счетчики».
      • Выберите «Все счетчики » и «Все экземпляры».
      • В списке объектов Performance выберите следующие объекты. После выбора каждого объекта нажмите кнопку «Добавить».
        • Исключения среды CLR .NET
        • Память СРЕДЫ CLR .NET
        • BizTalk: обмен сообщениями
        • BizTalk: TDDS
        • Память
        • Процесс
        • Процессор
        • Оркестрации XLANG/s

        Если SQL Server локальный, добавьте следующие объекты:

        • SQLServer: базы данных
        • SQLServer: общая статистика
        • SQLServer: диспетчер памяти

        Примечание. Значение интервала выборки данных и время начала отслеживания являются неистеданным. Эти значения зависят от воспроизведения утечки памяти. Так как файл журнала может быть большим, укажите интервал, в который можно получить сведения, которые должны быть у вас без перегрузки сервера.

        Получение файла дампа

        Чтобы получить файл дампа, используйте один из следующих методов:

        Метод 1. Автоматический

        Для записи дампа памяти рекомендуется создать правило утечки памяти и обработки с помощью DebugDiag. Правило утечки памяти и обработки автоматически присоединяет Leaktrack.dll. Используется для отслеживания выделения памяти. Чтобы создать правило «Память и обработка утечки», выполните следующие действия.

        1. Запустите средство диагностики отладки 1.1.
        2. Выберите «Память» и «Дескриптора утечки», а затем нажмите кнопку «Далее».
        3. Выберите Btsntsvc.exe и нажмите кнопку » Далее».
        4. На странице «Настройка правила утечки » выполните следующие действия.
          1. Щелкните, чтобы сразу же щелкнуть кнопку «Начать отслеживание памяти» при активации правила . В противном случае можно указать время прогревов перед LeakTrack.dll в BTSNTSvc.exe процесса.
          2. Нажмите кнопку «Настроить» и выполните следующие действия:
            • Убедитесь , что выбрано правило автоматического сбоя. Если выбрать этот параметр, то при остановке BTSNTSvc.exe будет автоматически создан дамп памяти.
            • Щелкните, чтобы выбрать параметр «Создать пользователя» при достижении флажка виртуальных байтов, и сохраните значение по умолчанию 1024.
            • Щелкните, чтобы выбрать дополнительный флажок и оставить значение по умолчанию 200. При выборе параметра доступа к виртуальным байтам автоматически создается дамп памяти, если виртуальные байты используют 1024 МБ. Если виртуальные байты увеличиваются на 200 МБ, автоматически создается другой дамп памяти.
          3. Нажмите кнопку «Сохранить & закрыть».
          4. Нажмите кнопку Далее.
          5. На странице «Выбор расположения дампа и имени правила » нажмите кнопку » Далее».

          Примечание. Вы также можете изменить путь к файлу дампа в поле « Расположение пользователя» на этой странице.

          Примечание. Теперь состояние правила — Отслеживание. Каждый раз, когда создается дамп памяти, значение будет увеличиваться в столбце Userdump Count на вкладке «Правила «. По умолчанию используется расположение дампа памяти C:\Program Files\DebugDiag\Logs .

          Метод 2. Вручную

          Вы также можете вручную вложить Leaktrack.dll и вручную получить файл дампа памяти. Это позволяет управлять созданием дампа памяти. Для этого выполните следующие действия:

          1. Запустите средство диагностики отладки 1.1.
          2. Выберите вкладку Процессы.
          3. Щелкните правой кнопкой мыши Btsntsvc.exe и выберите пункт «Монитор для утечек».
          4. В диалоговом окне средства диагностики отладки нажмите кнопку «Да» и нажмите кнопку » ОК».

          Создайте правило аварийного завершения для отслеживания того же Btsntsvc.exe в случае остановки процесса перед созданием дампа памяти:

          1. Запустите средство диагностики отладки 1.1.
          2. Выберите «Аварийное завершение» и нажмите кнопку «Далее».
          3. Выберите конкретный процесс и нажмите кнопку » Далее».
          4. Выберите тот же Btsntsvc.exe и нажмите кнопку » Далее».
          5. На странице «Расширенная конфигурация (необязательно) нажмите кнопку » Далее».
          6. В диалоговом окне «Выбор расположения дампа и имени правила (необязательно) нажмите кнопку » Далее».
          7. Нажмите кнопку «Активировать правило» и нажмите кнопку » Готово».

          Когда процесс достигает 60–80 процентов ОЗУ, щелкните правой кнопкой мыши процесс Btsntsvc.exe и выберите команду «Создать полный пользователь». Если процесс BizTalk останавливается перед созданием пользовательского дампа, правило аварийного завершения должно вступает в силу и создать дамп памяти.

          Остановка Монитор производительности журналов

          Если вы записываете дамп памяти и Монитор производительности данные, остановите ведение журнала Монитор производительности примерно через две минуты после создания дампа памяти.

          Анализ файла дампа

          Чтобы определить причину утечки памяти, можно использовать средство диагностики отладки для анализа файла дампа. Для этого выполните следующие действия:

          1. Откройте вкладку «Расширенный анализ «.
          2. Нажмите кнопку «Добавить файлы данных» и найдите DMP-файл.
          3. Выберите сценарий анализа нехватки памяти и нажмите кнопку «Начать анализ».

          По умолчанию файл отчета анализа (MHT-файл) C:\Program Files\DebugDiag\Reports будет создан в папке после завершения анализа. Файл отчета также будет отображаться в браузере. Файл отчета содержит результаты анализа. Кроме того, файл отчета может содержать рекомендации по устранению утечки памяти.

          При использовании пользовательских библиотек DLL можно добавить путь к символам пользовательских PDB-файлов для анализа. Для этого выполните следующие действия:

          1. Откройте средство диагностики отладки.
          2. В меню «Сервис » щелкните » Параметры» и «Параметры».
          3. В поле «Путь поиска символов для отладки » введите путь к символу.

          Если вам нужна помощь с анализом файла дампа, обратитесь в Службу поддержки клиентов Майкрософт. Полный список номеров телефонов службы поддержки клиентов и сведения о затратах на поддержку см. в службе технической поддержки.

          Прежде чем обращаться в службу поддержки клиентов, сжимайте файл дампа, журнал Монитор производительности, файл отчета об анализе и обновленные журналы событий (EVT-файлы). Может потребоваться отправить эти файлы инженеру BizTalk Server поддержки.

          Обратная связь

          Были ли сведения на этой странице полезными?

          Утечки памяти

          Материал на этой странице устарел, поэтому скрыт из оглавления сайта.

          Утечки памяти происходят, когда браузер по какой-то причине не может освободить память от недостижимых объектов.

          Обычно это происходит автоматически (Управление памятью в JavaScript). Кроме того, браузер освобождает память при переходе на другую страницу. Поэтому утечки в реальной жизни проявляют себя в двух ситуациях:

          1. Приложение, в котором посетитель все время на одной странице и работает со сложным JavaScript-интерфейсом. В этом случае утечки могут постепенно съедать доступную память.
          2. Страница регулярно делает что-то, вызывающее утечку памяти. Посетитель (например, менеджер) оставляет компьютер на ночь включённым, чтобы не закрывать браузер с кучей вкладок. Приходит утром – а браузер съел всю память и рухнул и сильно тормозит.

          Утечки бывают из-за ошибок браузера, ошибок в расширениях браузера и, гораздо реже, по причине ошибок в архитектуре JavaScript-кода. Мы разберём несколько наиболее частых и важных примеров.

          Коллекция утечек в IE

          Утечка DOM ↔ JS в IE8-

          IE до версии 8 не умел очищать циклические ссылки, появляющиеся между DOM-объектами и объектами JavaScript. В результате и DOM и JS оставались в памяти навсегда.

          В браузере IE8 была проведена серьёзная работа над ошибками, но утечка в IE8- появляется, если круговая ссылка возникает «через объект».

          Чтобы было понятнее, о чём речь, посмотрите на следующий код. Он вызывает утечку памяти в IE8-:

          function leak() < // Создаём новый DIV, добавляем к BODY var elem = document.createElement('div'); document.body.appendChild(elem); // Записываем в свойство жирный объект elem.__expando = < bigAss: new Array(1000000).join('lalala') >; // Создаём круговую ссылку. Без этой строки утечки не будет. elem.__expando.__elem = elem; // Удалить элемент из DOM. Браузер должен очистить память. elem.parentElement.removeChild(elem); >

          Полный пример (только для IE8-, а также IE9 в режиме совместимости с IE8):

          Похожие публикации:
          1. Raid card что это
          2. Как прочитать все письма в gmail на iphone
          3. Как сделать чтобы новая вкладка открывалась яндексом
          4. Как сделать шаблон cut and stack preps

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *