askeet

После изучения проблемы выявлено следующее при записи через ODBC Manager данных в базу данных имеются большие до 30 Мегабайт скачки в памяти, которые в последствии очищаются медленней планируемого обращения к базе данных. Итого 30 Мегабайт довольно быстро превращается в 400. Но после прекращения обращения к базе данных вся память постепенно очищается.
Функция записи в базу данных имеет следующий вид , к которой есть частое обращение

public static int ExecuteNonQuery(string query)
        {
            int ret = 0;
          //  return ret;  если раскоментировать  употребление памяти не увеличивается
            lock (Lock)
            {
                try
                {
                    using (OdbcConnection Connection = new OdbcConnection(ConnectionString))
                    {
                        Connection.Open();
                        if (Connection.State == System.Data.ConnectionState.Open)
                        {
                            using (var command = new OdbcCommand(query, Connection))
                            {
                                ret = command.ExecuteNonQuery();
                            }
                        }
                        Connection.Close();
                        //OdbcConnection.ReleaseObjectPool();
                    }
                    OdbcConnection.ReleaseObjectPool();
                }
                catch (Exception e)
                {
                    Console.WriteLine("ExecuteNonQuery=" + e.Message);
                }
            }
            return ret;
        }

При этом запись в базу осуществляется асинхронно

public static void AddRecordsInArhiveAsync(ushort Code, bool NewData, DateTime Now, bool Finish = false)
        {
                Thread _trdAddRecords = new Thread(      
                    delegate()      
                    {
                        lock (LockThis)                        
                            AddRecordsInArhive(Code, NewData, Now, Finish); // Внутри вызывается функция ExecuteNonQuery(string query)              
                    }
                );

                _trdAddRecords.Priority = ThreadPriority.Normal;
                _trdAddRecords.Start();
        }

Тогда была предпринята попытка перезаписи функции с асинхронного вызова AddRecordsInArhiveAsync на синхронный.

public static void AddRecordsInArhiveSync(ushort Code, bool NewData, DateTime Now, bool Finish = false)
        {
            lock (LockThis)
                AddRecordsInArhive(Code, NewData, Now, Finish);
        }

После этого сборщик мусора стал работать корректно.

Вопрос, что не так в функции AddRecordsInArhiveAsync ?

Счетчик GS Handles постоянно меняется и растет 500 - 600 , 522 - 700 , 600 - 839 , 993 - 1100.
На форме при обновлении DataTableGrid используется Dictionary < string,string > через DataSource.

Назначение: Windows 7, Windows Server 2008 R2, Windows Vista
Дело в том что в качестве целевой системы используется сборка на базе Windows XP SP3. Поэтому данное решение здесь неприменимо.

Спасибо за ответы. Была идея насчет реализации общего мониторинга по памяти в приложении, судя по всему его реализация здесь будет оптимальна. Осталось только техническая сторона частота опроса и прочее, в случае выделения большого блока памяти превышающего предел памяти.
На счет проверки почему GС не понял. Но утечка именно при начальном доступе(вызов функций) в длл. Может можно её полностью времено выгружать из памяти?
Например, для доступа используется класс.

public class DLL{
 ....
        [DllImport(VIDEODLL, EntryPoint = "#6", CallingConvention = CallingConvention.Cdecl)]
        public static extern byte dllTestConnection(string address); // проверка соединения с сервером.
....
}