andw Posted April 24, 2011 Share Posted April 24, 2011 Обнаружилась проблема при использовании IPSerial.dll. Проверено на ОС: Win7 (x64), WinXP SP3 и Win2003 (x86); программа делается на C#2008, собирается под x86. Также проверены примеры на Delphi из поставки NPort Adm Suite. Версия IPSerial.dll - 1.5.1.0. После вызова nsio_init() счетчик дескрипторов процесса (handles, по показаниям диспетчера задач) увеличивается примерно на 12500 (Большинство процессов используют всего лишь 300-400). При последующих вызовах nsio_end() количество дескрипторов уменьшается, но уже не на 12500, а меньше. В результате происходит их накопление... и скорее всего в итоге может привести к сбою системы (пока не успел проверить). При использовании IPSerial.dll версии 1.5.11.0 - число handles вообще не уменьшается после nsio_end(). Пока что единственный вариант решения - периодический перезапуск процесса, работающего с NPort. Но... совсем не хотелось бы так делать. Link to comment
Komantsev Posted April 24, 2011 Share Posted April 24, 2011 Добрый день! Попробуйте установить последнюю бета-версию NPort Administrator 1.14.11. В ней проблема должна быть исправлена. 1. Bugfix: Reduce handle counts when application call nsio_init() from IPSerial library. version.txt Npadm_Setup_Ver1.14.11_Build_10102017.zip Link to comment
andw Posted April 25, 2011 Author Share Posted April 25, 2011 Добрый день! Попробуйте установить последнюю бета-версию NPort Administrator 1.14.11. В ней проблема должна быть исправлена. Поставил, попробовал... только вот проблема исправлена не в ней, а в предыдущей бета версии (1.14.9), но опять же, не до конца. В общем, вот результаты по использованию IPSerial.dll разных версий. Проверял под x86 и x64, результат одинаковый. Версия dll/nsio_init()/nsio_end() (v.1.4.3.0) +12557 -12550 (v.1.5.1.0) +12557 -12550 (v.1.5.7.0) +13 -7 (v.1.5.11.0) +12557 -6 Что касается предельного количества handles - в WinXP x86 начались сбои (непрорисовка меню, невозможность открытия новых окон) при handles count около 3,8 млн. Link to comment
Komantsev Posted April 25, 2011 Share Posted April 25, 2011 Добрый день! только вот проблема исправлена не в ней, а в предыдущей бета версии (1.14.9) Исправления наследуются от версии к версии. Мне сложно отследить по версиям IPSerial. Не могли бы Вы указать, каким версиям NPort Administrator они соответствуют? Link to comment
andw Posted April 25, 2011 Author Share Posted April 25, 2011 Добрый день! Исправления наследуются от версии к версии. Мне сложно отследить по версиям IPSerial. Не могли бы Вы указать, каким версиям NPort Administrator они соответствуют? IPSerial.dll / NPort Adm. v.1.5.0.0 (Ver1.10.1) v.1.5.1.0 (Ver1.12.3, Ver1.14, Ver1.14.7) v.1.5.7.0 (Ver1.14.9) v.1.5.11.0 (Ver1.14.11) Link to comment
andw Posted April 27, 2011 Author Share Posted April 27, 2011 Напишу о результатах тестирования одной из версий IP Serial Lib. Версия IPSerial.dll - 1.5.7.0; ОС - Win2003 x86; программа собрана под .NET 3.5. Устройства к порту RS485 (NPort 5130A) не подключены; между ПК и NPort - 2 свитча в незагруженной сети. Bнициализация (nsio_init()) выполняется один раз при запуске программы и соотв. вызов nsio_end() делается один раз при завершении. Внутри в цикле последовательно вызываются nsio_checkalive, nsio_open, nsio_write, nsio_read, nsio_close. На всякий случай все сделано в одном потоке, т.к. информации о потокобезопасности данной библиотеки нет. Программа работала непрерывно около 12 часов. Число handles менялось в диапазоне 304..366, постоянного увеличения их числа не было. Наблюдалась небольшая утечка памяти... с этим еще буду разбираться. Скорее всего, так и надо использовать эту библиотеку, а не вызывать nsio_init/nsio_end в каждом сеансе связи с устройством. Link to comment
Komantsev Posted April 27, 2011 Share Posted April 27, 2011 Добрый день! Ну вообще, конечно, COM-порт обычно бывает эффективнее единожды открыть и продолжать с ним работать. Но всё зависит от реальной программы, и не всегда получается сделать именно так. Поэтому если есть возможность, лучше не использовать nsio_init/nsio_end очень часто. Но все равно по поводу большого количества Handles я сейчас общаюсь с разработчиками. Надеюсь, эту "особенность" удастся убрать из драйвера. В любом случае, как будут новости, я сообщу. (я думаю, в течение пары дней) Link to comment
Komantsev Posted April 29, 2011 Share Posted April 29, 2011 Добрый день, Посмотрите, пожалуйста, самую последнюю версию NPort Administrator 1.16. Обещают, что в ней нет проблем с количеством handles. Npadm_Setup_Ver1.16_Build_11021514.zip Link to comment
andw Posted April 29, 2011 Author Share Posted April 29, 2011 Добрый день, Посмотрите, пожалуйста, самую последнюю версию NPort Administrator 1.16. Обещают, что в ней нет проблем с количеством handles. По результатам тестирования в течении ~1,5 часов (в цикле с интервалом 15 секунд вызывается nsio_checkalive, nsio_open, nsio_write, nsio_read, nsio_close, без подключенных к RS485 устройств): с количеством handles проблемы сейчас нет (как и в версии 1.5.7.0 библиотеки из NPort Adm. Ver1.14.9) а вот с расходом памяти пока не все понятно... на графике видно, что объем занятой памяти увеличивается примерно на 250 Кб в час. В ближайшее время попробую сделать минимальный тестовый пример на Delphi, чтобы исключить возможные эффекты менеджера памяти среды исполнения .NET. Link to comment
andw Posted April 30, 2011 Author Share Posted April 30, 2011 В ближайшее время попробую сделать минимальный тестовый пример на Delphi, чтобы исключить возможные эффекты менеджера памяти среды исполнения .NET. Кратко о результатах тестирования программы, сделанной в Delphi7: ОС: Win2003 x86, IPSerial.dll последней версии (1.6.0.0), консольное приложение с вызовом внутри цикла nsio_open()...nsio_close(). Каждая такая пара вызовов приводит к увеличению расхода памяти на 1,3 Kb. Link to comment
Komantsev Posted May 6, 2011 Share Posted May 6, 2011 Добрый день, Не могли бы Вы скинуть нам эту простенькую программку с исходниками для облегчения тестирования? Спасибо заранее! Link to comment
andw Posted May 6, 2011 Author Share Posted May 6, 2011 Добрый день, Не могли бы Вы скинуть нам эту простенькую программку с исходниками для облегчения тестирования? Спасибо заранее! В архиве собственно исходник - MemLeakTest.dpr. Остальное: IPSerial.pas - из примеров, IPSerial.dll - версии 1.6.0.0 из NPort Administrator 1.16. Ну и файлы проекта D7. Впрочем, я сейчас всю работу с NPort реализовал напрямую (аналог checkalive() через ICMP-запросы и прием/передача данных через 950-й TCP порт). Проблем с ресурсами/памятью нет, минус такого решения только в том, что взаимодействие с NPort по этой схеме недокументировано (?). Link to comment
Komantsev Posted May 11, 2011 Share Posted May 11, 2011 Добрый день! Что-то программисты не могут сэмулировать "съедание" памяти. Не могли бы Вы выслать также программку, которой строили графики памяти? Link to comment
andw Posted May 11, 2011 Author Share Posted May 11, 2011 Не могли бы Вы выслать также программку, которой строили графики памяти? Выложенные ранее график был построен в обычном Excel'е с использованием сформированного самой программой в ходе работы csv-файла, содержащего основные параметры процесса. Для выложенного тестового примера значения расхода памяти записывались вручную каждый час, по показаниям "Диспетчера задач", потом был рассчитан средних расход памяти на 1 пару вызовов open/close. Также замеры делались с помощью оснастки "Performance" (счетчики производительности) в Win2003. Link to comment
Komantsev Posted May 11, 2011 Share Posted May 11, 2011 Выложенные ранее график был построен в обычном Excel'е с использованием сформированного самой программой в ходе работы csv-файла, содержащего основные параметры процесса. Понятно! А можете тогда скинуть саму процедурку, которая формировала этот csv-файл? Просто чтобы нам на 100% всё сэмулировать. Link to comment
andw Posted May 11, 2011 Author Share Posted May 11, 2011 Понятно! А можете тогда скинуть саму процедурку, которая формировала этот csv-файл? Просто чтобы нам на 100% всё сэмулировать. Я возможно неточно объяснил ситуацию: - сначала была сделана программа на C#, которая в ходе работы записывала собственное состояние в csv файл, графики были построены в Excel по данных из этого файла - потом для исключения разных побочных эффектов (в основном менеджера памяти .NET) был сделан минимальный пример на Delphi, выложенный здесь. В нем оставлен только вывод в консоль, для контроля работоспособности, а уже параметры процесcа заносились в таблицу Excel вручную из окна диспетчера задач. Итоговый вывод (про 1,3Кб) как раз и сделан на основе этих данных. Замеры сведены в приложенную таблицу. Я последовательно исключал вызов разл. методов внутри цикла, в итоге остались только open/close. По известному расходу памяти в час и числу вызовов был определен средний расход памяти на одну пару вызовов. MemLeakTest1.zip Link to comment
Komantsev Posted May 12, 2011 Share Posted May 12, 2011 Добрый день! Ага, всё примерно понятно! Так дадите ту исходную программу на C#? Или она в "непотребном" виде? :-) Link to comment
andw Posted May 12, 2011 Author Share Posted May 12, 2011 Добрый день! Ага, всё примерно понятно! Так дадите ту исходную программу на C#? Или она в "непотребном" виде? :-) К сожалению, это довольно большой проект, из которого надо еще вытаскивать непосредственную работу с NPort. А в целом код такой же, как в примере на Delphi. Использована обертка для вызова (через P/Invoke) функций из IPSerial.dll (сделанная на основе примера на C# из поставки NPort Administrator). В том-то и дело, что используемая среда разработки не влияет на поведение IPSerial.dll. В случае использования Delphi влияние побочных факторов сведено к минимуму. Link to comment
Komantsev Posted May 22, 2011 Share Posted May 22, 2011 Добрый день! Программисты говорят про возрастающую память, что это, возможно, особенности Delphi. На приведенном Вами примере действительно память увеличивается. Во вложении - пример на Visual C, где, как утверждают наши программисты, память не растёт. На картинках - объемы памяти - при старте и после 2000 циклов инициализации. Картинки 1 и 2 - для примера на Delphi. Память увеличивается. Картинки 3 и 2 - для примера на Visual C. Память постоянна. moxa_tester.zip Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now