Нестабильность кластера с протоколом TCPPING

У меня есть 8 разных процессов, распределенных по 6 разным серверам со следующей конфигурацией протокола TCP/TCPPING:

<config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">

  <TCP 
    bind_port="${jgroups.tcp.bind_port:16484}" 
    bind_addr="${jgroups.tcp.bind_addr:127.0.0.1}"
    recv_buf_size="20M"
    send_buf_size="20M" 
    max_bundle_size="64K" 
    sock_conn_timeout="300"
    
    use_fork_join_pool="true" 
    thread_pool.min_threads="10" 
    thread_pool.max_threads="100" 
    thread_pool.keep_alive_time="30000" /> 
  <TCPPING 
    async_discovery="true"
    initial_hosts="${jgroups.tcpping.initial_hosts:127.0.0.1[16484]}"
    port_range="5" #/>
  <MERGE3 min_interval="10000" max_interval="30000" />
  <FD_SOCK get_cache_timeout="10000"
        cache_max_elements="300"
        cache_max_age="60000"
        suspect_msg_interval="10000"
        num_tries="10"
        sock_conn_timeout="10000"/>
  <FD timeout="10000" max_tries="10" />
  <VERIFY_SUSPECT timeout="10000" num_msgs="5"/>
  <BARRIER />
  <pbcast.NAKACK2
        max_rebroadcast_timeout="5000"
        use_mcast_xmit="false"
        discard_delivered_msgs="true" />
  <UNICAST3 />
  <pbcast.STABLE
        stability_delay="1000"
        desired_avg_gossip="50000"
        max_bytes="4M" />
  <AUTH
        auth_class="com.qfs.distribution.security.impl.CustomAuthToken"
        auth_value="distribution_password"
        token_hash="SHA" />
  <pbcast.GMS
        print_local_addr="true"
        join_timeout="10000"
        leave_timeout="10000"
        merge_timeout="10000"
        num_prev_mbrs="200"
        view_ack_collection_timeout="10000"/>
</config>

Кластер продолжает разбиваться на подгруппы, а затем снова и снова объединяется, что приводит к высокому использованию памяти. Я также вижу в журналах много подозрительных предупреждений, возникающих из-за периодических тактов, отправляемых всеми другими членами кластера. Я что-то упускаю ?

ИЗМЕНИТЬ

После включения журналов gc у меня не появилось ничего подозрительного. С другой стороны, я заметил, что эти журналы jgroups появляются много:

WARN: lonlx21440_FrtbQueryCube_QUERY_29302: I was suspected by woklxp00330_Sba-master_DATA_36219; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK

DEBUG: lonlx21440_FrtbQueryCube_QUERY_29302: closing expired connection for redlxp00599_Sba-master_DATA_18899 (121206 ms old) in send_table

DEBUG: I (redlxp00599_Sba-master_DATA_18899) will be the merge leader

DEBUG: redlxp00599_Sba-master_DATA_18899: heartbeat missing from lonlx21503_Sba-master_DATA_2175 (number=1)

DEBUG: redlxp00599_Sba-master_DATA_18899: suspecting [lonlx21440_FrtbQueryCube_QUERY_29302]

DEBUG: lonlx21440_FrtbQueryCube_QUERY_29302: removed woklxp00330_Sba-master_DATA_36219 from xmit_table (not member anymore)enter code here

и этот

2020-08-31 16:35:34.715 [ForkJoinPool-3-worker-11] org.jgroups.protocols.pbcast.GMS:116
WARN: lonlx21440_FrtbQueryCube_QUERY_29302: failed to collect all ACKs (expected=6) for view [redlxp00599_Sba-master_DATA_18899|104] after 2000ms, missing 6 ACKs from (6) lonlx21503_Sba-master_DATA_2175, lonlx11179_DRC-master_DATA_15999, lonlx11184_Rrao-master_DATA_31760, lonlx11179_Rrao-master_DATA_25194, woklxp00330_Sba-master_DATA_36219, lonlx11184_DRC-master_DATA_49264

Я до сих пор не могу понять, откуда берется нестабильность. Спасибо


java jgroups
person Mr. D    schedule 06.08.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Любая нестабильность не связана с протоколом TCPPING — он принадлежит к семейству протоколов Discovery, и его цель — найти новых членов, а не выгнать их из кластера.

Вы используете как FD_SOCK, так и FD, чтобы узнать, ушли ли участники, а затем VERIFY_SUSPECT, чтобы подтвердить, что узел недоступен. Настройка вроде нормальная.

Первое, что нужно проверить, это ваши журналы GC. Если вы сталкиваетесь с паузами STW дольше, чем, скажем, 15 секунд, есть вероятность, что кластер отключится из-за отсутствия ответа из-за GC.

Если ваши журналы GC в порядке, увеличьте уровень ведения журнала для FD, FD_SOCK и VERIFY_SUSPECT до TRACE и посмотрите, что происходит.

person Radim Vansa    schedule 07.08.2020
comment
Спасибо за эти подсказки. К сожалению, активность gc нормальна. Я обновил исходный пост с некоторыми журналами Jgroups... - person Mr. D; 02.09.2020