Проблемы с MulticastSocket в Windows Server 2008 - PullRequest
10 голосов
/ 08 февраля 2012

У меня есть Java-приложение, которое использует несколько экземпляров MulticastSocket для прослушивания. на несколько UDP многоадресных каналов. Каждый такой сокет обрабатывается отдельным потоком.
Поток читает каждую дейтаграмму, анализирует ее содержимое и записывает в журнал (log4j) идентификатор последовательности пакета (long) и метку времени, в которую была получена датаграмма.

Когда я пытаюсь запустить 2 экземпляра одного и того же приложения на Windows Server 2008 R2, с 2 * 6 ядрами и сравните 2 журнала, созданные двумя приложениями, Я заметил, что довольно часто сроки пакетов не совпадают.

Большинство пакетов принимаются двумя приложениями одновременно (милис), но часто разница в времени приема одного и того же пакета составляет около 1-7 мс по 2 приложения.

Я попытался выделить больше буферов в NIC, а также увеличил буфер чтения сокетов. Кроме того, я попытался минимизировать прогоны GC, и я также использую -verbose: gc и могу видеть что времена GC и проблемные различия во времени не происходят одновременно. Это позволяет мне предположить, что моя проблема не связана с GC.

Не обнаружено проблем с отбрасыванием пакетов, и проблема с пропускной способностью маловероятна.

Идеи / Мнения приветствуются. Спасибо.

Ответы [ 2 ]

6 голосов
/ 08 февраля 2012

По умолчанию частота прерываний таймера Windows составляет 100 Гц (1 такт на 10 мс). Это означает, что ОС не может гарантировать, что потоки Java будут работать с более высокой точностью.

Вот выдержка из известной статьи Джеймса Холмса о времени в Java - это может быть ваш случай:

для пользователей Windows, особенно в двухъядерных или многопроцессорных системах (и это наиболее часто встречается в системах x64 AMD), если вы видите нестабильное поведение синхронизации в Java или других приложениях (игры, мультимедийные презентации) на вашей системы, затем попробуйте добавить ключ / usepmtimer в ваш файл boot.ini.

PS: ни в коем случае я не заслуживаю доверия в области оптимизации производительности Windows, также начиная с Windows 2008 поддерживается HPET, но как это связано с частотой прерывания по таймеру, для меня загадка.

0 голосов
/ 25 февраля 2012

7 мс - очень хороший результат для 6-ядерного компьютера, и дрейф в java будет намного выше, чем в случае запуска сборщика мусора. Не забывайте, что у java runtime есть свои собственные издержки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...