2017-01-31 1 views
4

Цель этого приложения - обрабатывать 800 одновременных клиентов по TCP, каждый из которых отправляет каждые 3,5 тыс. Xml каждую секунду. Каждый из этих запросов должен быть проанализирован (см. Фрагмент кода). Это происходит на разных потоках.Проблемы с производительностью нити для Java на Raspberry Pi

Ограничение этого проекта заключается в том, что он должен работать на небольшом малиновом Pi3 (1,2 ГГц четырехъядерном ядре, 1 ГБ оперативной памяти). И я сталкиваюсь с проблемами использования, когда увеличиваю нагрузку выше 150 одновременных клиентов (80% использования процессора).

Когда я запускаю эту программу, моя машина для разработки, похоже, работает очень хорошо. (0-1% использования, менее 150). Я понимаю, что моя машина разработки более мощная, чем RPI, и поэтому работает лучше. Но разница кажется слишком большой.

В моей текущей настройке я использую Java nio для обработки/чтения всех входящих соединений. Затем я использую несколько потоков для чтения данных.

Current Setup

Это простой код, который в настоящее время работает на обработке потока. Также попытался прочесть простой байт [] массив 1 байт за раз. И даже чтение потока StaX. Каждая вариация чтения, которую я пробовал, «тип чтения» дает наихудшую производительность.

BufferedInputStream input = new BufferedInputStream(new ByteArrayInputStream(buffer.array(), 0, bytecount)); 
int current; 
/* In this snippet input.read() is the cause of performance issues 
Reading directly from byte[] gives similar poor performance. 
*/ 
while ((current = input.read()) != -1) { 
    continue; 
} 

По моему профилировщику вызова Input.read() использует огромное количество вычислительной мощности на Pi и составляет 97% от общего времени центрального процессора. другие 3% - основной поток, который обрабатывает соединения.

На моей машине для разработки это почти перевернуто, и основной поток составляет большую часть использования процессора, 93%. И 7% идет на потоки обработки.

Что может вызвать эту большую разницу? почему этот вызов read() на pi так дорого по сравнению с моей другой машиной, может ли это иметь какое-то отношение к памяти?

Примечания:

  • Pi бежит raspbian линукс - OpenJDK 1.8.0_40-внутренний
  • Dev работает машина выиграть 10 - Java (TM) SE Runtime Environment (сборка 1.8.0_121-b13)
  • Пробовал работать с флагом -Xms -Xmx на обеих машинах, тот же результат.
+3

Пи ** имеет абсолютно худший IO **. На вашем ПК есть массивный вращающийся диск или, возможно, даже SSD - это на порядок ** быстрее, чем дрянная SD-карта. И это даже не начинается с архитектуры процессора, количества ядер, гиперпотоков и т. Д. –

+0

Я предполагаю, что вы используете это через Ethernet? В этой статье представлена ​​интересная информация https: //www.jeffgeerling.com/blogs/jeff-geerling/get-gigabit-networking отмечают, что он говорит: «Однако для многих случаев использования в реальном времени другие подсистемы Pi (CPU и диск ввода/вывода, особенно, поскольку I/O находится на одном, общая шина USB 2.0) ограничит доступную пропускную способность ». Я также прочитал, что вам нужно убедиться, что вы получаете достаточную мощность, так как слишком мало снижает производительность (максимальная потребляемая мощность должна составлять около 1,100 мАч, но это может варьироваться в зависимости от модели) –

+1

Приложение не делает (явного) ввода-вывода на диск, Pi может обрабатывать сокеты IO просто отлично (без обработки), в основном потоке сокеты считываются и сохраняются в байтовых буферах. тогда поток обработки должен быть прочитан из ОЗУ, если я прав. – Georggroenendaal

ответ

0

Оказывается, что проблема была комбинация обоих JVM и 32бит ОС на Raspberry Pi 3. При запуске 32-битной raspbian с OpenJDK мое заявление было очень плохую производительность (особенно на «читать» звонки). Переход на JVM Oracle дал мне «лучшую» ожидаемую производительность.

Однако при переключении на 64-битную ОС (OpensSuse в моем случае) производительность была хорошей и с OpenJDK, и с JVM Oracle.

(Кредиты @jww в комментариях, предложившего, чтобы переключиться на 64 разрядной ОС)

Смежные вопросы