Есть два способа атаковать это. Во-первых, посмотреть на управляемые объекты и их время жизни. Вы можете использовать Remote Performance Monitor (RPM) для просмотра снимков кучи ГХ и сравнения их.
Вы можете использовать CLR Profiler , чтобы проверить дерево вызовов и увидеть, откуда поступают эти объекты.
Эти два инструмента обычно позволяют находить проблемы с управляемым кодом.
Теперь важно отметить, что вы говорите, что GC не сообщает о каком-либо росте, что говорит мне, что куча GC в порядке, и эти инструменты вряд ли найдут много в этом конкретном случае. Тем не менее, я выложил инструменты, потому что они могут помочь вам (или кому-то еще, читающему это) в будущем.
В вашем случае это звучит так, как будто у вас есть собственная утечка. Вы не сказали, какой тип памяти протекает - физический или виртуальный, - но почти наверняка что-то делает исходное распределение, которое не освобождается. SQL Compact - это мое предположение, основанное на том, что вы сказали о своей архитектуре, поскольку движок реализован в собственном коде с управляемым слоем, расположенным поверх него.
Я также собираюсь предположить, что основная причина заключается в том, что у вас есть несколько небольших управляемых объектов (возможно, SqlCeTransaction или SqlCeCommand), которые по отдельности имеют небольшую управляемую площадь, но выполняют некоторое собственное распределение для вас, и эти объекты выживают. ,
Управляемые инструменты должны позволять вам находить большое или растущее число этих предметов и определять корень, который мешает GC убить их. Было бы хорошо, если бы вы вызывали Dispose для всех используемых вами объектов SqlCe.
Если все это не удается найти, вы можете погрузиться в некоторые из нативных инструментов , но они вообще плохо работают с управляемым кодом и вряд ли дадут вам много информации.