Нестабильность кластера с протоколом TCPPING - PullRequest
Новая
       81

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

0 голосов
/ 06 августа 2020

У меня есть 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>

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

EDIT

После включения журналов g c мне ничего подозрительного не показалось. С другой стороны, я заметил, что эти журналы 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

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

1 Ответ

0 голосов
/ 07 августа 2020

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

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

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

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

...