Одна из возможностей состоит в том, что два узла WAS не идентичны, хотя вы и предполагали.Базовая информация о производительности платформы является отправной точкой для диагностики любой проблемы с производительностью.
Я бы начал диагностировать эту проблему, сравнив информацию о мониторинге производительности для двух узлов WAS, используя такие инструменты, как NMON, если вы работаете в Linux.
http://nmon.sourceforge.net/pmwiki.php
Такая команда вызовет данные nmonдля записи в файл каждые 10 секунд для 1800 выборок
nmon -f -F <filename.nmon> -s 10 -c 1800 -t
, а затем с помощью инструмента, подобного визуализатору NMON, вы можете сравнить данные для двух узлов в графической форме
https://nmonvisualizer.github.io/nmonvisualizer/
Подобные инструменты доступны для других платформ, например perfmon для Windows.
В этом случае я бы изначально искал разницу в процессоре, используемом между двумя узлами WAS.Если ЦП находится в узле, который занимает больше времени для вставки записей, возможно, этот узел настроен с меньшим количеством ядер (ВМ), или, возможно, куча Java в этом узле меньше, поэтому он тратит много времени на сборку мусора, или, может быть,этот узел был настроен с использованием SSL, а другой - нет, и т. д. и т. д.
Если в узле загружен ЦП и требуется больше времени для вставки записей, то должно быть какое-то внешнее узкое место, ограничивающее работувыполняется узлом - возможно, сетевой порт на узле неправильно настроен, так что трафик между этим узлом и кластером Cassandra ограничен, или, возможно, неправильная конфигурация интерфейса Cassandra для этого узла, или, возможно, узел имеет медленный или неисправныйжесткий диск, поэтому чтение объемных данных для вставки происходит медленно и т. д. и т. д.
Диагностика проблем производительности требует сбора данных о производительности, а затем следования подсказкам.