Приложение Windows Forms замедляется примерно через 12 часов

Question

Программист в моем офисе написал невероятно большое приложение для Windows Forms. В любом случае, он продолжает испытывать проблемы с замедлением работы приложения примерно через 12 часов. Мы подтвердили, что фактический цикл обработки событий работает медленно, а не код после возникновения событий. Например, даже ввод в текстовое поле будет очень медленным. У него есть несколько потоков сокетов, которые, как мы убедились, работают с нормальной скоростью. Единственное, о чем я могу думать, это то, что у него есть несколько экземпляров System.Timers.Timer во всем приложении. Могут ли они быть проблемой? Программа замедляется обычно после того, как никто не использовал ее в течение 5 или 6 часов.

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

Еще одна вещь, которую стоит упомянуть. Его архитектура состоит из базовой формы, которая включает в себя панель с элементами управления, которые каждая страница имеет вместе с 3 таймерами, и все другие формы наследуются от этой базовой формы. Вероятно, существует около 15 таких форм, и все они загружаются в память при запуске. Мы сделали это, потому что клиент жаловался на переключение между формами, и первый раз занял несколько секунд. Каждая форма имеет потенциально от пятидесяти до ста экземпляров элемента управления, который мы написали для него, чтобы использовать его для выполнения всей его серверной работы. В этом элементе управления есть статический таймер, а также один статический поток - поскольку существует только один экземпляр независимо от того, сколько экземпляров элемента управления находится в памяти, я не могу себе представить, что это проблема. Также таймеры базовой формы являются статическими.

Я не могу поручиться за эффективность его кода, но он действительно хорошо работает в нашем офисе и на месте от 5 до 6 часов.

Есть идеи?

Edit:

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

Обновление:

Хорошо, сегодня я наконец-то познакомился с парнем, чтобы посмотреть на код.

У него было несколько статичных членов его класса, то есть таймеры, некоторые кнопки и пользовательские элементы управления. Затем в конструкторе он использовал оператор new для каждого из этих статических элементов без статического флага isInit bool.

Другими словами, статические элементы инициализировались каждый раз, когда создавалась новая форма, но ссылалась только на последнюю инициализированную форму. Тем не менее, я представляю, что контейнер формы содержит ссылки на старые объекты, поэтому старые объекты никогда не будут удалены. Кроме того, не будет ли это плохим псевдонимом для контейнеров, если объект должен быть удален при изменении ссылки на статический член? В любом случае, плохая утечка или плохой псевдоним могут вызвать проблемы. Я надеюсь, что это единственная проблема. Я заставляю его все это исправить, а потом мы снова проверим.

Чтобы добавить оскорбление к травме, он вызывал GC.KeepAlive (статический таймер), у которого была новая ссылка внутри конструктора. Итак, у него было 21 таймер.

Answer 1

Вы утилизируете?Вы держите объекты в памяти?Держитесь ли вы за какой-то другой неуправляемый ресурс.

Оставьте его работающим, дождитесь его замедления, подключите отладчик, пройдите и посмотрите, какие строки работают медленно в вашей проблемной области.:

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

У меня действительно была похожая проблема, когда мы выполняли некоторое удаленное взаимодействие через сокеты на фонепотоки между несколькими сервисами на разных машинах.К сожалению, я не могу вспомнить точные детали (вздох). Как я помню, мы продолжали запрашивать через заданный интервал времени, но время ответа от службы становилось все медленнее, в конечном итоге время ответа превышало заданный интервал.Это было хорошо для первых 1000 вызовов или около того, .Net сохранил хороший растущий стек обратных вызовов, которые мы ожидали.Однако, в конце концов, этот список достиг некоторого внутреннего предела, и насос сообщений замер, включая всю картину в клиентских графических интерфейсах.Это было решено путем обеспечения того, что мы не будем звонить, пока у нас не будет ответа.Этот тип расы может или не может быть тем, что вы испытываете, но я подумал, что стоит упомянуть.