Устранение неисправностей Медленность в приложениях для торговли запасами [дубликат]

    

У этого вопроса уже есть ответ:

    

Привет, энтузиасты сети!

У меня возникли проблемы с поиском решения в реальном времени. Вот шаги, которые я сделал до сих пор:

По-видимому, это единственное приложение Real-Time в компании, над которой я работаю, испытывает замедленность, и каждый действительно любит обвинять сетевого парня (меня) всякий раз, когда возникает такая проблема.

Выполнено Traceroute из приложения в DB, ​​клиент в приложение, DB в приложение, traceroute составляет от 4 мс до 9 мс.

Мониторинг использования ЦП, использования памяти, потери пакетов и использования ссылок в Solarwinds

Максимальная статистика на некоторых сетевых устройствах:
Использование процессора: 30%
Использование памяти 73%
Потеря пакетов 0%
Использование ссылок: 60%

Это не кажется полезным, кроме базовых целей, так как это выглядит нормально, но они все еще испытывают медлительность.

Я также выполнял Sniffing с использованием Wireshark. Сначала я только понюхал одно устройство за раз, и это не дало мне подробностей, поэтому я понюхал сразу два устройства: ближайший к серверу приложений торговли и ближайший к серверу базы данных коммутатор. Я сравнивал их графики ввода-вывода, и я обнаружил, что задержка передачи пакетов из приложения в БД одинакова на обоих коммутаторах, но латентность DB для приложения отличается от обоих коммутаторов. Коммутатор, ближайший к db, показывает 10 мс или меньше латентности, в то время как ближайший к торговому серверу коммутатор показывает 100 - 254 мс задержки! .

Одна из проблем, с которыми я сталкиваюсь в wirehark, заключается в том, что все наши коммутаторы (кроме тех, которые подключаются к ПК клиента) выполняют балансировку нагрузки, поэтому трудно предсказать, какой именно пакет. Кроме того, протокол SQL и FiX не полностью поддерживается Wireshark, но это трудно проверить. В настоящее время я просто смотрю на времена дельты. Тем не менее, я не знаю, как проверить, является ли высокая дельта-время из-за времени ответа приложения или передачи задержки в сети. Ребята из сервера не знают, как проверить ART -_- '

Итак, я сейчас изучаю очень высокую задержку. Моя проблема заключается в том, что между App, DB и ПК клиента множество сетевых устройств, около 30 устройств, включая два двух брандмауэра. Я планирую обнюхивать, по крайней мере, все устройства между App и DB, исключая брандмауэры, и это займет у меня 6 ноутбуков, работающих одновременно.

Прежде чем выполнить это, у меня есть несколько вопросов:

  1. Правильно ли я выполняю процесс устранения неполадок?

  2. Есть ли другие вещи, которые я мог бы посмотреть /проверить?

  3. Увеличивает ли количество сетевых переходов время ожидания? Если да, это зависит от коммутаторов, маршрутизаторов и брандмауэров? ​​

  4. Поставщик торгового приложения рекомендует внедрить QoS для этого торгового приложения. Это действительно необходимо?

Заранее благодарю за вашу помощь и извините за длинный блок текста. :)

2 голоса | спросил Rufi 8 PM00000010000004531 2014, 13:56:45

1 ответ


1

Трудно сказать наверняка без дополнительной информации, но тот факт, что хост, близкий к db, в порядке, но еще один шаг медленный, говорит о перегрузке сети. Кроме того, 60% использования ссылок является высоким, учитывая, что он обычно усредняется в течение 5 минут. Вы могли бы очень легко насыщать некоторые ссылки в течение коротких периодов времени. Но в ответ на ваши вопросы:

  1. Я не думаю, что дополнительное обнюхивание скажет вам что-нибудь еще. Вы уже видите задержку. Проверьте свои записи, чтобы узнать, есть ли у вас повторные передачи. Также проверяйте наличие капель по каждой отдельной ссылке. О, и поскольку у вас сложная сеть, вы должны потратить время на выяснение путей данных. Это необходимо для устранения неполадок.

  2. Если у вас есть устройства Cisco, вы можете изменить время усреднения порта до 30 секунд, что может улучшить понимание использования ссылок. Вы также можете посмотреть отдельные порты для упавших пакетов. Если у вас есть, Netflow также может оказаться полезным.

  3. Предполагая, что у вас есть коммерческие коммутаторы, дополнительная латентность, вызванная ими, будет незначительной.

  4. Если у вас действительно есть перегрузка сети, то да, QoS поможет, установив приоритет для этого трафика по всем видео кота, которые все смотрят.

ответил Ron Trunk 8 PM000000100000003231 2014, 22:03:32

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132