Высокое использование ЦП - признаки, перемещающиеся с сервера на сервер после возврата

MiniShowCase может удовлетворить Вашим потребностям, это довольно просто и просто, чтобы заставить его работать, но, имеет много php файлов.

2
задан 8 March 2017 в 19:59
4 ответа

Выравнивание нагрузки является абсолютно циклическим алгоритмом, или это делает неподвижность на основе IP или cookie? У Вас мог быть некоторый пользовательский трафик, который придерживается одного сервера и перемещается в перезапуск - особенно, если другой Ваших серверов называет приложение на кластере. Так перепроверьте его против фактических хитов к серверу.

У Вас может также быть состояние состязания в приложении, что определенные операции получают его в цикле. Для этого Вы могли взять дамп потока (уничтожьте-3 pid), и вытащите их из своего журнала stdout и выполните что-то как Самурай на них для наблюдения что.

Я также включил бы вход сборки "мусора" и видел бы, коррелируют ли времена GC с воспринятым временем задержки.

1
ответ дан 3 December 2019 в 13:32
  • 1
    Если я вхожу в консоль WebLogic и проверяю количество транзакций, они - все о том же. Никакой сервер не имеет необычно высокое количество транзакций. Насколько я знаю, нет никакой неподвижности на основе IP или cookie. Это было бы установкой, которой я мог определить местоположение в консоли WebLogic? I' m заинтригованный Вашей идеей состояния состязания, все же. У меня есть дампы потока для всех четырех серверов (от того, когда server02 имел проблему), и загрузил их в Самурая. Я определенно вижу более заблокированные потоки в server02. Как каждый изучает, как интерпретировать эти дампы? Это - просто полученный навык? –   2 March 2010 в 21:11
  • 2
    Неподвижность была бы, вероятно, установлена или в Weblogic или в подсистеме балансировки нагрузки если you' ре с помощью один. Независимо от того, что это - that' s выполнение Вашего циклического алгоритма был бы то, где you' d неподвижность набора. И да, чтение файлов трассировки является в основном полученным навыком. Если Вы видите более заблокированные потоки, ищете, где они, и затем если они все, кажется, находятся в том же коде, пойдите, говорят с разработчиком. 80% проблем как это находятся в коде приложения не в инфраструктуре. Теперь, существует шанс they' ll ожидать на чем-то как дб объединяют соединение, в этом случае, это - Вы... –  Ernest Mueller 10 March 2010 в 02:16
  • 3
    О, также, часто загрузки ЦП, которые остаются в " даже numbers" как 50% то, потому что приложение выходит из-под контроля на одном ЦП. Если у Вас есть 2 системы ЦП, 50%-й шаблон ЦП может означать " 100% на одном CPU " Проверьте на статистику ЦП. Я воображаю you' ll видят тот Java proc' s работающий в 100% и другой, делающий это little' шаблон оболочки черепахи Вы имеете. Это определенно влияет на пользовательское время отклика для приложения. –  Ernest Mueller 10 March 2010 в 02:20

Я не эксперт по кластеру или BEA, но в аналитических проблемах производительности нет только ЦП. Каковы данные о памяти, диске и сети? Инструменты для получения данных о являются вершиной (CPU и память, со многими деталями и также для каждого процесса), vmstat (память, CPU, диск), SAR (sysstat пакет на Linux, со всеми возможными данными и историческими записями). Затем какова операционная система таких машин и в который версия?

0
ответ дан 3 December 2019 в 13:32
  • 1
    Я понимаю это it' s не только ЦП, но и that' s одна вещь, которая действительно выскакивает как проблема. Использование памяти и статистика сети весь взгляд, нормальный через плату. –   2 March 2010 в 21:15
  • 2
    Извините, но затем я don' t understan, какова Ваша проблема. Загрузка ЦП 50 или 60% как максимум по сути в моем знании isn' t проблема. Если Ваши пользователи экспериментируют задержки затем, более глубокий анализ всех обстоятельств и показателей производительности могло бы быть полезно определить причины. –  twistedbrain 3 March 2010 в 14:20
  • 3
    Разъясниться: you' ре говоря это it' s нормальный для одного сервера в кластере четырех серверов (все с равным количеством транзакций), чтобы иметь ЦП, достигающий 50-60%, в то время как другие три сервера почти никогда не превышают 10%? I' m не опытный при профилировании ЦП, но я думаю, что мое опасение является обоснованным. –   3 March 2010 в 17:49
  • 4
    Спасибо за clarifing, я didn' t понял сценарий потому что для меня это wasn' t ясный, что это был кластер разделения нагрузки и b.e. не только кластер HA. Так или иначе, также если в таком случае that' s couldn' t быть нормальным я don' t видят, почему пользователи должны испытать проблемы, если узел имеет ЦП в 50%, потому что it' s не очень высокая загрузка. Можно ли коррелировать наверняка таких пользователей страдания с тем конкретным узлом, и Вы знаете, почему он более загружается? В противном случае, возможно, могло быть полезным для анализа другого performance' s элементы того узла для понимания причин. –  twistedbrain 4 March 2010 в 00:21

Я установил бы датчик Java и представил бы веб-приложение для дальнейшего исследования, где точно то 50%-е движение ЦП.

0
ответ дан 3 December 2019 в 13:32

Инициируйте дамп потока или два на каждом из серверов. Вы, вероятно, найдете, что один из серверов имеет выполнение потока, которое не работает на других серверах. Также проверьте использование памяти через консоль. Я видел, что WebLogic входит в цикл сборки "мусора", когда нет достаточной памяти.

0
ответ дан 3 December 2019 в 13:32

Теги

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