Толстый клиент Java замедляется при соединении с localhost, быстро с удаленным

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

• это - действительно обратная петля, это - проблема? Вы попытались соединиться с сетевым IP-адресом сервера, а не 127.0.0.1? (это использует петлевой интерфейс в моей системе, но это должно исключить нечетные проблемы DNS),
• системная нагрузка высоко в это время (io, проблемы могут заставить системную нагрузку быть выше, чем все отдельные процессы вместе, казалось бы, были бы)?
• Проверьте информацию netstat на каждый процесс, если Recv-Q клиента высок, клиентский процесс не читает из своего сокета регулярно.
• Попытайтесь смотреть tcpdump -i lo, это могло бы помочь выяснить, существует ли очевидный шаблон к передаваемым пакетам.
• "vmstat 1" показывает решительно другое поведение для удаленного доступа по сравнению с локальными версиями доступа (т.е. действительно ли содержание является набором данных в RAM и в сервере дб и в клиенте Java, вынуждающем Вас подкачивать)?
• Попытайтесь увеличить MTU на устройстве закольцовывания, значениях по умолчанию шахты к 16 436. Это не поможет многому, если Вы сделаете много небольших крошечных пакетов. Небольшие крошечные пакеты, кажется, имеют собственные проблемы. Я не программист Java, таким образом, я не знаю, как можно было бы сделать это, но установка TCP_NODELAY попытки (setsockopt системный вызов) на соединении. Этот кажется, что это имеет грузовой культ после, но предположительно если коммуникация является односторонней, клиент будет отвечать TCP ACKs более регулярно и сохранять течение данных.
• Другая вещь попытаться настроить: echo 1 > /proc/sys/net/ipv4/tcp_low_latency
• При проигрывании с setsockopt посмотрите то, что происходит, если Вы увеличиваете отправку и получение буферов в клиенте?
• Вы не используете своего рода древние 2,2 ядра, Вы? Была, по-видимому, своего рода огромная петлевая исправленная ошибка, въезжают задним ходом 2.3.x согласно 2.4 TODO
• Возможно, существует ошибка в клиенте (или в Java), Вы выполнили тот же самый клиент в отдельной системе Linux с той же средой выполнения Java?

Это будет звучать странным, но это работало только что на меня.
Проверьте/etc/hosts файл, чтобы иметь Ваше имя хоста в соответствии с localhost или, добавить тот, указывающий 127.0.0.1 или тот, который слушает.

Для устранения X11vnc и NX как возможные причины задержки я записал бы консольному режиму тестовую программу Java не-GUI, которая выполняет поиски базы данных или тестовые транзакции и время когда приложение, работающее на ПК и на сервере (например, использующее SSH/Putty для вызова его).

Съемка общим планом: я также проверил бы обратное разрешение DNS в случае, если драйверы JDBC используют это (например, для входа), если DNS правильно не настроен, программное обеспечение может очевидно зависнуть, ожидая тайм-аутов разрешения DNS. Как местоположение DBMS настроено в приложении Java?

Вы попытались соединиться с 127.0.0.1 вместо localhost? Это делает несколько вещей. Предотвращение сумасшедших проблем DNS является одним из них, но также и многие клиенты видят "localhost" и затем решают не использовать сеть вообще и использовать некоторый локальный сокет вместо этого. Это мог быть этот автоматический технологический переключатель, который уничтожает Ваше приложение. Несколько программ делают этого майора как mysql. Используя localhost петлевой адрес IP вынуждает их на самом деле использовать сетевой сокет.

Мой любимый инструмент для проблем как они strace. Вы можете просто strace клиент и видеть его пауза после выполнения чего-то (блокирующийся вызов как подключение, или читайте). Если существует некоторый цикл событий, который затеняет паузу, можно попытаться фильтровать те syscalls, или можно включить опции синхронизации к strace и сохранить весь вывод в файле. Другой прием должен ожидать просто, пока он не "заканчивает" то, что держало его и хит ^C, таким образом, можно посмотреть на то, что, оказалось, повредило его из его оцепенения.