Вопросы Теги

Сокеты, найденные lsof, но не netstat

Что такое шлюз по умолчанию для Вашей машины разработки? Шлюз по умолчанию, принимающий Коммутатор уровня 3/, Маршрутизатор должен знать, как достигнуть другого интерфейса сервера.

У Вас должно быть что-то как 

ip route xxx.yyy.159.36 netmask 255.255.255.240 gw xxx.zzz.109.65

Это должно заставить вещи работать. Но в случае, если это не достаточно, затем включите передачу IP на машине xxx.zzz.109.65 использование

sysctl net.ipv4.ip_forward = 1

Также отредактируйте/etc/sysctl.conf и включите IP, передающий там также.

Удостоверьтесь iptables ВПЕРЕД, цепочка таблицы фильтра на xxx.zzz.109.65 позволяет пакетную передачу для Вашей машины разработки.

19
задан 28 June 2010 в 12:59
3 ответа

Это может произойти, если Вы создаете сокет, но никогда не соединяете () или связываете () с ним. Ваш лучший выбор может быть к strace (-и следующие) приложением и затем перекрестно сослаться с выводом lsof для определения, какие сокеты вызывают проблему. В качестве награды метод отладки: если Вы перенесете свои вызовы сокета с отладочной информацией и выпишете им к/dev/null, то это появится в strace, не давая Вам весело большие файлы журнала.

17
ответ дан 2 December 2019 в 20:19
  • 1
    самый полезный ответ, таким образом, это получает щедрость. Thanks! –  Robert Munteanu 4 July 2010 в 23:26

Первой вещью, которую я сделал бы, является incrase если Ваш предел дескриптора файла:

~# vi /etc/sysctl.conf
fs.file-max = 331287

Затем я удостоверился бы, что Ваша система актуальна, это включает все библиотеки и серверы. Его возможное, что Ваш сервер JAVA-приложения устарел (при использовании одного). Также возможность, что Ваш сервер приложений неправильно конфигурируется, необходимо посмотреть конфигурационный файл и понизить Ваш connectionTimeout и/или Ваш maxKeepAliveRequests (Я не уверен, какой сервер приложений Ваше использование или если Вы используете один вообще...).

Я не уверен, что это приложение делает, но если Вы не думаете, что требуются десятки тысяч сокетов затем, это - почти наверняка "утечка дескриптора файла" в Вашем JAVA-приложении. Вам, вероятно, придется отправить отчет об ошибках поставщику. В этом отчете об ошибках необходимо включать информацию о том, как воссоздать проблему.

Вот некоторые способы отладить проблему.

Wireshark (или twireshark для cli) является лучшим инструментом, чтобы видеть, как эти сокеты используются. Wireshark даст Вам передохнуть вниз типа трафика, бросаемого по проводу. Его вероятное, за которым первые несколько соединений будут следовать и затем это поразит предел дескриптора файла. После того как предел дескриптора файла поражен затем, Wireshark не собирается брать на чем-либо (и более опрятный netstat в этом отношении), но это поможет сузить проблему. Там, возможно, случай, куда много исходящего SYN's отправляется, однако никакой SYN/ACKs, получается таким образом, много соединений TCP просто застревает в состоянии SYN_WAIT.

Если у Вас есть доступ к исходному коду, и Вы знаете тип создаваемых сокетов (таких как использование strace или просто поиск кода) затем, можно открыть проект в Eclipse (или другой IDE) и установить точку останова в функции, которая создает эти сокеты. Когда точка останова поражена, затем можно посмотреть на отслеживание стека. Эта утечка дескриптора файла, возможно, простой бесконечный цикл или возможно значение тайм-аута сокета является слишком большой. Другая возможность состоит в том, что приложение Java не делает a socket.close() очищать соединения. В выполнении завершения обычно выполняют finely блок a try/catch (Да сокет должен всегда иметь попытку/выгоду в Java, или это не создаст :). В конце дня его вероятное, что приложение Java не обрабатывает свой IOException's правильно.

1
ответ дан 2 December 2019 в 20:19
  • 1
    спасибо за ответ. Я на самом деле разрабатываю это приложение - контейнерную часть - вместо того, чтобы просто управлять им, и я не мог найти любые проблемы связанными с сокетами, не закрываемыми. Но подсказка wireshark/twireshark хороша, я буду использовать это. –  Robert Munteanu 4 July 2010 в 23:28
  • 2
    @Robert Munteanu при создании этого приложения thenthis, является вопросом для stackoverflow. Однако Вы открываете слишком много сокетов. –  Rook 4 July 2010 в 23:35
  • 3
    : Я разочаровался в обнаружении этого мудрого кодом, и попытался разыскать его как системный администратор. Вот почему я отправил на SF. И да, я знаю так или иначе, что слишком много сокетов открыты. Но существуют нулевые подсказки как, туда, где... –  Robert Munteanu 5 July 2010 в 14:29
  • 4
    @Robert должен установить точки останова после создания сокета и посмотреть на отслеживание стека и память в той точке. Я подозреваю, что Вы попадаете в бесконечный цикл. Способность посмотреть на любую переменную и шаг, хотя Ваш код будет лучшим подходом для сложных проблем как это. –  Rook 6 July 2010 в 01:59
  • 5
    , к сожалению, это происходит на вид случайное на одном из 20 серверов - не всегда том же - только в продуктивных средах, и возможно дважды в неделю. Иначе это было бы довольно просто к пальцу. Я в настоящее время использую Byteman (jboss.org/byteman) для отслеживания создания/связывать/подключения/опасных положений сокета. Надо надеяться, что-то выйдет его. –  Robert Munteanu 6 July 2010 в 11:35

Используя Python, я встретился с той же проблемой на сокетах SSL:

  • Когда я использую socket.close (), сокет остается в состоянии CLOSE_WAIT в течение неопределенного времени
  • то, когда я использую socket.shutdown (), lsof говорит, "не может определить протокол"

Решение состояло в том, чтобы развернуть уровень SSL перед закрытием:

  • origsock = socket.unwrap ()
  • origsock.close ()

Это закрывает сокеты правильно в моем приложении.

2
ответ дан 2 December 2019 в 20:19

Теги

Похожие вопросы