Клиент подключенный по TCP/IP начинает тормозить

[Sergey83]

Имеется АРМ Windows 7 (Сервер) и АРМ Windows Server 2012 (Клиент). На обоих АРМах установлена SCADA iFix5.8. Через некоторое время начинает тормозить Клиент. Отображение на клинете через базу сервера (TCP/IP, толстый клиент так называемый). Утечек памяти нет ни каких это я про Historian, поставлен патч SP2. Просто отображение начинает тормозить. По Ethernet ни каких обрывов связи, сеть гигабитная. Антивирус не чего не блочит, на локальный трафик полное разрешение.

[petr2off]

Один из возможных траблов - автотюнинг TCP пакетов. Отключить нафиг...

[Sergey83]

Заметил следующие. При удалении в grf переменных типа Object, grf быстрее начинают открываться...

По поводу автотюнинга - ОТКЛЮЧИЛ его. Особо не помогла проблеме.

[petr2off]

А коммутаторы какие стоят ? Управляемые или нет ?

[Jackson]

Антивирус не чего не блочит, на локальный трафик полное разрешение

Зачем он нужен на рабочем АРМе? Кто знает в какой момент он вдруг решит просканировать весь АРМ и сползать за обновлениями, и что при этом сделает с системой. Например, на рабочем компе у меня при начале обновлений антивируса напрочь вырубается teamviewer, хотя связи на первый взгляд никакой.
Выбросить к чёрту, как и всё остальное лишнее (остановить и отключить такие службы как фоновая дефрагментация, фоновая передача данных по TCP и т.д.). Своп тоже отключить, или хотя бы фиксированным сделать.

[petr2off]

Выбросить к чёрту, как и всё остальное лишнее (остановить и отключить такие службы как фоновая дефрагментация, фоновая передача данных по TCP и т.д.).

Это конечно правильное направление, я бы добавил к нему анализ загруженности процессора, с тем - что бы убить службы жрущие много ресурсов. Но с Windows есть еще и архитектурные нюансы, связанные с тем - что это все таки не система реального времени. Даже версии "embedded". В свое время меня удивило наличие нескольких платформ у IPC DAS. Тут и однозадачная MiniOS (фактически DOS) и Linux и WIndows XP (теперь на замену ему Windows CE). Но когда читал мануалы, отметил следующее - они советуют использовать Windows платформы для не критических приложений с большим циклом, со много элементной СКАДА на верхнем уровне. А вот если идет речь о реализации алгоритма управления, регулирования, технологической защиты - то для локального проекта здравствуй MiniOS, для сложного (например с участием нескольких контроллеров) - Linux.
Собственно говоря, я это прочувствовал на одном проекте. Реально мощный контроллер Торнадо, фактически загруженный на 8 - 12%, периодически подзависал при обмене по Windows TCP. Платформа Windows 7 Embedded. Проблема решилась на 90% когда я убил автотюннинг TCP пакетов и поставил "умный" коммутатор, где фактически всю сетку прописал - т.е. статическую маршрутизацию сделал. И то, остались еще проблемы связанные с частотниками, управляемыми по 485. Если он не да бог ломается (редко но бывает), то начинаются проблемы (там шлюз стоит 485 - TCP).
Т.е. есть 2 уровня проблемы. 1-я, как TEB справедливо заметил, связана с процессорным ресурсом - смотри загрузку и выкидывай все лишнее, это полезно сделать, даже если с загрузкой все ОК, потому как некоторые сервисы активны не постоянно.
И 2-я связанная с сетевым обменом. Но здесь однозначного решения нет. Нужно смотреть и анализировать конкретную архитектуру.

[hell_boy]

Было такое, долго мучались. Правда, с версией 3.5 и Win2k. В итоге выяснилось, что подвисание клиентов вызвано:
1. Применением дешевых коммутаторов. Системный интегратор решил сэкономить и поставил коммутаторы одной известной китайской фирмы. Только эта фирма до этого не выпускало оборудование гигабитных скоростей. Что делало встроенное ПО при возрастании трафика, одному богу известно. 5 клиентов на 2 сервера. Заметили, что тормоза пропадают, когда работает связка 1 сервер - 1 клиент.
2. Применением сетевых карт с 2-мя портами Ethernet. Тоже косяк системного интегратора, тем более, карты были из того же китайского магазина, что и коммутаторы.
3. Наличием в сети посторонних устройств. Один клиент был на оптоволокне, по этому же волокну перегонялись данные от его локального ПЛК протокол EtherNet/IP.
4. Кстати, тормозят не все Objects, а только некоторые. Например, Crystal Reports, ADO (ActiveX Data Objects).

[Jackson]

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

Именно это в конечном счёте я и имел в виду.
Да, Виндовс - это не ОСРВ, однако АРМы на её базе нормально работают даже в режиме осциллографа, если клиентское ПО нормальное и лишние процессы не мешают.

Отправлено спустя 1 минуту 52 секунды:

1. Применением дешевых коммутаторов. Системный интегратор решил сэкономить и поставил коммутаторы одной известной китайской фирмы. Только эта фирма до этого не выпускало оборудование гигабитных скоростей. Что делало встроенное ПО при возрастании трафика, одному богу известно. 5 клиентов на 2 сервера. Заметили, что тормоза пропадают, когда работает связка 1 сервер - 1 клиент.

Эта проблема решается оптимизацией запросов-ответов по интерфейсам.

3. Наличием в сети посторонних устройств. Один клиент был на оптоволокне, по этому же волокну перегонялись данные от его локального ПЛК протокол EtherNet/IP.

А как эта проблема устраняется - ведь очевидно.

[Sergey83]

Нашел в чем проблема. Вообщем SCADA стоит на Windows Server 2012, на фиксе стоят обновления для Historian 5.5 SIM 42 (обновления которое борется с утечкой памяти процессом Hisroriana). Удалил этот пакет обновлений iFix стала летать. Но вылезает проблема с утечками памяти

[hell_boy]

Сегодня вышел SIM 43. Вроде решает проблему утечки памяти

[+] Скачать

ftp://ftp.indusoft.ru/GEIP_Products/Pro ... ian55_SIM/