Задержки сети в AIX для Java приложений

Главная Форумы POWER Systems AIX/Hardware Задержки сети в AIX для Java приложений

Просмотр 33 веток ответов
  • Автор
    Сообщения
    • #19580
      Tim Tim
      Участник

      Добрый день!
      На машине с AIX запущенно web приложение на WebLogic. Через некоторое время после начала работы (порядка 30 секунд) при обращении к этому приложению происходят задержки порядка 3 секунд. Задержки не равномерны – т.е. для некоторых запрос есть, для некоторых нет. Запросы по содержанию идентичны.
      Тестировали с помощью jMeter, который делал get запросы в приложение. Задержки происходят только при запуске jMeter на другом компьютере – при запуске на том же компьютере, где расположен WebLogic, всё работает без задержек.
      Задержки есть так же и в Tomcat (тоже java приложение) и при доступе к статическому ресурсу (проверяли на картинке).
      Для Oracle запущенного на той же машине, задержек нет. Ну или они не такие большие – не более 400мс.
      Java тюнинговали – heap и GC настраивали. В целом стало быстрее работать (заметно при тестировании локально – до настройки avg 20мс, после – 10мс), но большие задержки так же остались.
      Так же запускали jMeter с машины, которая находится в той же стойке что и машина с проблемным WebLogic – задержки такие же.
      Есть ли у кого нибудь идеи, в чём может быть проблема? Или хотя бы, как её можно локализовать?

    • #19581
      Alex
      Участник

      Задержки происходят только при запуске jMeter на другом компьютере – при запуске на том же компьютере, где расположен WebLogic, всё работает без задержек.

      Так может всё проще и дело в банальном name resolving при соединении? Проверить просто, внесите ip-шник(и) машины, с которой тестировали, в /etc/hosts и повторите тест. Это при условии, что порядок в /etc/netsvc.conf дефолтный: local,bind

    • #19583
      Tim Tim
      Участник

      Спасибо за ответ!
      Насколько я понял, проблема с name resolving была бы возможно если обращаться к машине по имени. Я правильно понял? Сейчас же обращение к машине происходить по ip.

    • #19585
      Tim Tim
      Участник

      А ещё не могли бы Вы подсказать, с помощью каких утилит можно анализировать сеть и прохождение трафика по сети? Грубо говоря, мне нужно узнать, как трафик проходит от WebLogic до jMeter. Со всеми задержками.

    • #19586
      Alex
      Участник

      Насколько я понял, проблема с name resolving была бы возможно если обращаться к машине по имени

      Нет, конечно. То, что предполагаю я, старо как мир. При коннекте к серверу, оный пытается разрешить ip клиента в имя. При отсутствиинеправильных настройках это может привести к задержке. Уж очень напоминает ваш случай.

      с помощью каких утилит можно анализировать сеть

      Начать стоит с tcpdump, тем более, что он родной для unix-систем.

    • #19587
      Tim Tim
      Участник

      Спасибо за быстрый ответ!

      При коннекте к серверу, оный пытается разрешить ip клиента в имя. При отсутствиинеправильных настройках это может привести к задержке.

      Хм… Я думал, что при коннекте по ip name resolving не происходит… Ок. А тогда если так, то что тогда писать в hosts?! Какое имя задавать серверу?! Я же к нему по ip соединяюсь и имя мне не важно. Так что имя может быть любое?
      А то раньше я hosts только для одного использовал – что бы не писать каждый раз ip, а обращаться по имени. А тут для меня не понятная ситуация. Но сейчас буду доки читать. 🙂

      Начать стоит с tcpdump, тем более, что он родной для unix-систем.

      Спасибо! Его уже пробовали, правда пока неудачно – вывод делали, по умолчанию, в текстовый файл, а его анализировать не удобно. В понедельник попробуем в параметров -w запустить (tcpdump -i -s 65535 -w ) , что бы Wireshark’ом открыть.
      А Вы не подскажите, чем удобно можно анализировать вывод tcpdump? Я пока только Wireshark знаю. У него даже есть некоторые анализаторы.
      А вот ещё на сайте IBM советуют (http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/network_perf.htm) netstat. Его тоже попробую.

    • #19588
      Alex
      Участник

      Хм… Я думал, что при коннекте по ip name resolving не происходит…

      Зависит от software на вашем серверном конце.

      Ок. А тогда если так, то что тогда писать в hosts?!

      Да напишите что угодно, это же просто проверка самой вероятной гипотезы. Писать надо в /etc/hosts на сервере, а не на клиенте.

    • #19589
      Tim Tim
      Участник

      Да напишите что угодно, это же просто проверка самой вероятной гипотезы. Писать надо в /etc/hosts на сервере, а не на клиенте.

      Спасибо! На следующей неделе попробую.

    • #19605
      Tim Tim
      Участник

      Только что посмотрел /ets/hosts на сервере – ip сервера прописан.
      Записи вида
      # public
      10.xxx.xxx.xxx db1n3 db1n3.domen
      # vip
      10.yyy.yyy.yyy db1n3-vip
      # intercon
      192.168.243.3 db1n3-priv

      Попробую теперь tcpdump.

    • #19606
      Alex
      Участник

      Только что посмотрел /ets/hosts на сервере – ip сервера прописан.

      На сервере в /etc/hosts должен быть прописан ip-шник _клиента_, с которого вы тестируете скорость доступа.

    • #19610
      Tim Tim
      Участник

      На сервере в /etc/hosts должен быть прописан ip-шник _клиента_, с которого вы тестируете скорость доступа.

      Сделал вчера, не повлияло не задержки. Файл /etc/netsvc.conf не заполнен (исключая стандартные комментарии от IMB), т.е., насколько я понял, порядок такое local, bind.
      Буду сегодня логи собирать.

    • #19615
      Dmitry
      Участник

      Если есть в наличии файл /etc/resolv.conf то порядок опроса “bind,local”

    • #19617
      Tim Tim
      Участник

      Да, точно, есть.
      Но уже нашёл, что порядок неправильный – как раз сейчас заново проверяю, с вручную установленным порядком.
      Но спасибо, что сказали, а то я так и не понял, в чём причина.

    • #19619
      Dmitry
      Участник

      Можете еще расследовать так:
      [code]# RES_OPTIONS=debug host http://www.ru[/code%5D

    • #19625
      Tim Tim
      Участник

      Не помогло.
      Сделал следующее – изменил /etc/hosts – добавил узел с которого тестирую, остановил сервер приложений и в скрипты запуска добавил:
      NSORDER=local,bind
      export NSORDER
      Запустил сервер – задержки в 3 секунды так же остались. Напомню, это задержки для случайных запросов – т.е. одно запроса всё хорошо, для следующего такого же – задержка от секунды до 3-х.

      Так же попробовал другой сервер приложений запустить, но уже перед этим вручную выставил
      export NSORDER=local
      В консоли проверил – если резолвить хосты не из hosts, то не резолвятся (т.е. NSORDER=local сработало, я так понимаю). Но при тестировании удалённо задержки существуют. При локальном тестировании всё так же хорошо.

      На всякий случай добавил в hosts на тестовой машине те же адреса (клиента, с которого запускается тест, и сервера, на котором запущен web server). Не помогло.

      Подскажите, пожалуйста, команда [code]export NSORDER=local[/code] применяется к тому приложению, которое я запущу из консоли, после выполнения этой команды? Насколько я знаю, настройки окружения копируются, т.ч. должно применяться. Но хотелось бы уточнить.

      Кстати, а не может это быть связанно с настройками сетевого адаптера?
      И ещё вопрос: При выполнении tracert с клиента (Windows машина) на сервер, в ответе присутствует промежуточный хост. При выполнении traceroute с сервера на клиент, в ответе выводится сразу ip клиента с резолвенным именем. Так вот, а почему выводы traceroute и tracert не совпадают? Где этот промежуточный хост, который есть в выводе команды tracert и которого нет в traceroute?

    • #19627
      Dmitry
      Участник

      Подскажите, пожалуйста, команда
      export NSORDER=local
      применяется к тому приложению, которое я запущу из консоли, после выполнения этой команды? Насколько я знаю, настройки окружения копируются, т.ч. должно применяться. Но хотелось бы уточнить

      Обычно да, проверить можно
      [code]ps auxewww[/code]

    • #19628
      Tim Tim
      Участник

      Спасибо, за быстрый ответ!
      Проверил – действительно установлено NSORDER=local.

    • #19635
      Alex
      Участник

      Кстати, а не может это быть связанно с настройками сетевого адаптера?

      Вторая распространённая причина. Но, скорее, не с настройками адаптера, а с настройками сети на сервере.

      Покажите netstat -rn с сервера и клиента и ifconfig -a (AIX)/ipconfig /all(windows). Есть подозрение, что у вас часть обратных пакетов с сервера улетает не туда.

    • #19636
      Tim Tim
      Участник

      AIX (сервер)
      $ netstat -rn
      Routing tables
      Destination Gateway Flags Refs Use If Exp Groups

      Route Tree for Protocol Family 2 (Internet):
      default 10.12.17.1 UG 13 209255336 en0 – –
      10.12.17.0 10.12.17.115 UHSb 0 0 en0 – – =>
      10.12.17/24 10.12.17.115 U 8 113042635 en0 – –
      10.12.17.115 127.0.0.1 UGHS 304 459337351 lo0 – –
      10.12.17.125 127.0.0.1 UGHS 2 67607 lo0 – –
      10.12.17.144 127.0.0.1 UGHS 1 40342 lo0 – –
      10.12.17.255 10.12.17.115 UHSb 2 18528 en0 – –
      127/8 127.0.0.1 U 101 42967179 lo0 – –
      169.254/16 169.254.46.177 U 17 265066394 en1 – –
      169.254.46.177 127.0.0.1 UGHS 122 2625917 lo0 – –
      169.254.255.255 169.254.46.177 UHSb 0 0 en1 – –
      192.168.243.0 192.168.243.3 UHSb 0 0 en1 – – =>
      192.168.243/28 192.168.243.3 U 7 47506799 en1 – –
      192.168.243.3 127.0.0.1 UGHS 0 461029 lo0 – –
      192.168.243.15 192.168.243.3 UHSb 2 92 en1 – –

      Route Tree for Protocol Family 24 (Internet v6):
      ::1%1 ::1%1 UH 46 10926346 lo0 – –

      $ ifconfig -a
      en0: flags=1e084863,18c0
      inet 10.12.17.115 netmask 0xffffff00 broadcast 10.12.17.255
      inet 10.12.17.125 netmask 0xffffff00 broadcast 10.12.17.255
      inet 10.12.17.144 netmask 0xffffff00 broadcast 10.12.17.255
      tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
      en1: flags=1e084863,18c0
      inet 192.168.243.3 netmask 0xfffffff0 broadcast 192.168.243.15
      inet 169.254.46.177 netmask 0xffff0000 broadcast 169.254.255.255
      tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
      en2: flags=1e084862,18c0
      tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
      en3: flags=1e084862,18c0
      tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
      lo0: flags=e08084b,c0
      inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
      inet6 ::1%1/0
      tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

      Windows (клиент)
      C:UsersUser5>netstat -rn
      ===========================================================================
      Interface List
      11…00 15 5d c0 45 02 ……Microsoft Virtual Machine Bus Network Adapter
      1………………………Software Loopback Interface 1
      12…00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
      ===========================================================================

      IPv4 Route Table
      ===========================================================================
      Active Routes:
      Network Destination Netmask Gateway Interface Metric
      0.0.0.0 0.0.0.0 192.168.192.230 192.168.192.106 261
      127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
      127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
      127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
      192.168.192.0 255.255.255.0 On-link 192.168.192.106 261
      192.168.192.106 255.255.255.255 On-link 192.168.192.106 261
      192.168.192.255 255.255.255.255 On-link 192.168.192.106 261
      224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
      224.0.0.0 240.0.0.0 On-link 192.168.192.106 261
      255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
      255.255.255.255 255.255.255.255 On-link 192.168.192.106 261
      ===========================================================================
      Persistent Routes:
      Network Address Netmask Gateway Address Metric
      0.0.0.0 0.0.0.0 192.168.192.230 Default
      ===========================================================================

      IPv6 Route Table
      ===========================================================================
      Active Routes:
      If Metric Network Destination Gateway
      1 306 ::1/128 On-link
      1 306 ff00::/8 On-link
      ===========================================================================
      Persistent Routes:
      None

      C:UsersUser5>ipconfig /all

      Windows IP Configuration

      Host Name . . . . . . . . . . . . : AAAA-S3
      Primary Dns Suffix . . . . . . . :
      Node Type . . . . . . . . . . . . : Hybrid
      IP Routing Enabled. . . . . . . . : No
      WINS Proxy Enabled. . . . . . . . : No

      Ethernet adapter Local Area Connection:

      Connection-specific DNS Suffix . :
      Description . . . . . . . . . . . : Microsoft Virtual Machine Bus Network Ada
      pter
      Physical Address. . . . . . . . . : 00-15-5D-C0-45-02
      DHCP Enabled. . . . . . . . . . . : No
      Autoconfiguration Enabled . . . . : Yes
      IPv4 Address. . . . . . . . . . . : 192.168.192.106(Preferred)
      Subnet Mask . . . . . . . . . . . : 255.255.255.0
      Default Gateway . . . . . . . . . : 192.168.192.230
      DNS Servers . . . . . . . . . . . : 192.168.192.2
      NetBIOS over Tcpip. . . . . . . . : Enabled

      Tunnel adapter isatap.{46445C00-F240-41D2-98F2-F8D61951D595}:

      Media State . . . . . . . . . . . : Media disconnected
      Connection-specific DNS Suffix . :
      Description . . . . . . . . . . . : Microsoft ISATAP Adapter
      Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
      DHCP Enabled. . . . . . . . . . . : No
      Autoconfiguration Enabled . . . . : Yes

    • #19637
      Tim Tim
      Участник

      Ещё запустил Tomcat (это сервер приложений для Java) на клиенте (Windows) и тестировал с сервера (AIX). Такие же задержки. При локальном тесте задержек нет.

    • #19638
      Alex
      Участник

      При тестировании ip клиента у вас 192.168.192.106 (и он же прописан в /etc/hosts на сервере) – правильно? А ip-адрес сервера какой используется (подозреваю, что один из alias-ов)? Приложите таже результаты tracert/traceroute, которые вас смутили.

    • #19639
      Tim Tim
      Участник

      При тестах всегда ip указываю, не имя. ip сервера 10.12.17.115

      C:UsersUser5>tracert 10.12.17.115

      Tracing route to db1n3.emias.msk.oms [10.12.17.115]
      over a maximum of 30 hops:

      1 <1 ms <1 ms <1 ms 192.168.192.230
      2 <1 ms <1 ms <1 ms SERVER.DOMAIN1.AAA.BBB[10.12.17.115]

      $ traceroute 192.168.192.106
      trying to get source for 192.168.192.106
      source should be 10.12.17.115
      traceroute to 192.168.192.106 (192.168.192.106) from 10.12.17.115 (10.12.17.115), 30 hops max
      outgoing MTU = 1500
      1 CLIENT.DOMAIN2.AAA.BBB (192.168.192.106) 1 ms * 1 ms

      Смутило следующее, при tracert в Win пакеты идут через 192.168.192.230, а при traceroute в AIX сразу в 192.168.192.106.

    • #19640
      Tim Tim
      Участник

      При тестировании ip клиента у вас 192.168.192.106 (и он же прописан в /etc/hosts на сервере) – правильно?

      Да, ip клиента прописал в hosts на сервере и он равен 192.168.192.106. По сути дублировал имя, которое выдавал DNS сервер в hosts – вместе с полным именем, включая домен. Потом проверил, что hosts используется – через переменную окружения указала использовать только loca и сделал traceroute ip клиента – резолв в имя произошёл. При traceroute на другой ip преобразование в имя не произошло (при настройках по умолчанию корректно резолвился в имя).

    • #19641
      andrewk
      Участник

      а у Вас Windows-клиент случайно не под VMware’ю крутится?

    • #19642
      Tim Tim
      Участник

      Да, под ним.

    • #19643
      andrewk
      Участник

      попросите админа vmware и венды выключить large send offload. как ни странно, эта функция правильно реализована только в AIX. На всех x86 системах, она сделана через ж..у, из-за чего возникают проблемы, по описанию похожие на Ваши.

      Large Send Offload and Network Performance

    • #19644
      Tim Tim
      Участник

      попросите админа vmware и венды выключить large send offload. как ни странно, эта функция правильно реализована только в AIX. На всех x86 системах, она сделана через ж..у, из-за чего возникают проблемы, по описанию похожие на Ваши.

      Спасибо! На днях попробую это сделать.

      Попробовал протестировать Oracle на том же сервере – при таком-же объёме данных задержек нет. Странно…
      Вот думаю, может это проблема самой Java машины? Тут кто-нибудь сталкивался с настройкой J9 в AIX?
      И ещё, в связи с этим, для корректного теста мне нужен web сервер для AIX не на Java. Не могли бы Вы мне подсказать такую программу? Google указал только на http://www-03.ibm.com/software/products/en/http-servers

    • #19645
      andrewk
      Участник

      Google указал все правильно – возьмите IBM HTTP Server и можете тестировать на нем статику.

      Задержки в работе JVM могут быть связаны с постоянной работой Garbage Collector’а – когда, например, он слишком часто пытается собрать “мусор” – либо из-за маленького размера heap’а, либо просто неправильной настройки. Для JVM существуют прекрасные тулзы, позволяющие анализировать работу виртуальной машины в онлайне с графиками и прочими рюшечками, но их названий я за давностью лет уже не помню

    • #19646
      Tim Tim
      Участник

      Задержки в работе JVM могут быть связаны с постоянной работой Garbage Collector’а – когда, например, он слишком часто пытается собрать “мусор” – либо из-за маленького размера heap’а, либо просто неправильной настройки. Для JVM существуют прекрасные тулзы, позволяющие анализировать работу виртуальной машины в онлайне с графиками и прочими рюшечками, но их названий я за давностью лет уже не помню

      Да вот как раз что странно, что heap и gc мы уже исключили (собственно, проблема с heap и gc это первое, что пришло на ум) – анализировали JVM по разному (мониторили heap, работу gc, анализировали лог gc с помощью тулзы от IBM, предназначенной для этого) плюс задержек нет при локальном доступе, а они бы были непременно, т.к. при локальном доступе так же всё работает – те же запросы идут на webserver.

    • #19652
      Alex
      Участник

      andrewk: так при локальном тестировании там проблем нет. Я бы не ставил на проблемы с настройкой java etc

      TimReset: а в одной сети (10.12.17/24) с сервером нет возможности потестировать? В идеале вообще вне vmware, поскольку она дополнительный элемент хаоса вносит.

      Судя по таблицам маршрутизации – на конечных хостах всё, вроде, верно. Но вот насчёт промежуточных точек информации нет, а симптоматика проблема характерна для проблем с роутингом. Как у вас из vmware доступ наружу организован?

    • #19654
      Tim Tim
      Участник

      а в одной сети (10.12.17/24) с сервером нет возможности потестировать? В идеале вообще вне vmware, поскольку она дополнительный элемент хаоса вносит.

      До меня тестировали – такую же машину с AIX, с такой же hardware конфигурацией и ip 10.12.17.11x, тесты запускали с этого сервера (10.12.17.115) – задержки были. Но на следующей недели перепроверю тесты.
      На счёт роутинга в vmware я на следующей недели уточню.
      Пока вот что меня смущает в роутинге – если бы было точно так, то были бы проблемы с Oracle. А пока тесты говорят об обратном – с Oracle всё хорошо, задержек нет при тех же объёмах данных. На следующей неделе протестирую нативный http сервер (apache или HTTP Server от IBM), что бы тесты были полностью аналогичны, а различались только серверы – native и java base.

    • #19655
      Dmitry
      Участник

      Может воспользоваться truss?
      [code]truss -aefD[/code]
      Рыть придется долго, но может дать зацепки.

    • #19657
      Alex
      Участник

      Да рано ещё truss, проще с tcpdump-а на сервере начать, с вычленением проблемной сессии.

    • #20077
      Tim Tim
      Участник

      Добрый день!
      Сорри за долгое отсутствие – сняли с этой задачи. Но теперь опять занимаюсь сабжем.
      Вот что нового обнаружилось – задержки есть только при частых коннектах – уже установленные соединения работают корректно. Обнаружилось при просмотре соединений к серверу СУБД и WEB – при соединении к СУБД клиент поднимал фиксированный пул соединений и дальше их использовал, а при http запросах соединения происходили каждый раз разные и в большом количестве.
      Грешим на arp. В таблице arp клиента не было сервера. После добавления (arp -s , клиент на Windows) задержки не исчезли.
      tcpdump пока не пробовали – слишком сложно, но, судя по всему, придётся делать.

Просмотр 33 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.