Неверный баланс между аэрокосмическими экземплярами в кластере

Question

У меня есть приложение с высокой нагрузкой для операций пакетного чтения. Мой аэрокосмический кластер (v 3.7.2) имеет 14 серверов, каждый из которых имеет 7 ГБ оперативной памяти и 2 процессора в Google Cloud.

Просмотрев графики Google Cloud Monitoring, я заметил очень несбалансированную нагрузку между серверами: на некоторых серверах почти 100% загрузка процессора, в то время как другие имеют менее 50% (изображение ниже). Даже после нескольких часов работы кластер неуравновешенный шаблон не изменяется.

Есть ли какая-либо конфигурация, которую я мог бы изменить, чтобы сделать этот кластер более однородным? Как оптимизировать балансировку узла?

Edit 1

Все серверы в кластере имеют один и тот же идентичный aerospike.conf файл:

Aerospike файл конфигурации базы данных.

service { 
    user root 
    group root 
    paxos-single-replica-limit 1 # Number of nodes where the replica count is automatically reduced to 1. 
     paxos-recovery-policy auto-reset-master 
    pidfile /var/run/aerospike/asd.pid 
    service-threads 32 
    transaction-queues 32 
    transaction-threads-per-queue 32 
     batch-index-threads 32 
    proto-fd-max 15000 
     batch-max-requests 200000 
} 

logging { 
    # Log file must be an absolute path. 
    file /var/log/aerospike/aerospike.log { 
     context any info 
    } 
} 

network { 
    service { 
     #address any 
     port 3000 
    } 

    heartbeat { 
       mode mesh 
       mesh-seed-address-port 10.240.0.6 3002 
       mesh-seed-address-port 10.240.0.5 3002 
       port 3002 

     interval 150 
     timeout 20 
    } 

    fabric { 
     port 3001 
    } 

    info { 
     port 3003 
    } 
} 

namespace test { 
    replication-factor 3 
    memory-size 5G 
    default-ttl 0 # 30 days, use 0 to never expire/evict. 
     ldt-enabled true 

    storage-engine device { 
      file /data/aerospike.dat 
      write-block-size 1M 
      filesize 180G 
     } 
} 

Edit 2:

$ asinfo 
1 : node 
    BB90600F00A0142 
2 : statistics 
    cluster_size=14;cluster_key=E3C3672DCDD7F51;cluster_integrity=true;objects=3739898;sub-records=0;total-bytes-disk=193273528320;used-bytes-disk=26018492544;free-pct-disk=86;total-bytes-memory=5368709120;used-bytes-memory=239353472;data-used-bytes-memory=0;index-used-bytes-memory=239353472;sindex-used-bytes-memory=0;free-pct-memory=95;stat_read_reqs=2881465329;stat_read_reqs_xdr=0;stat_read_success=2878457632;stat_read_errs_notfound=3007093;stat_read_errs_other=0;stat_write_reqs=551398;stat_write_reqs_xdr=0;stat_write_success=549522;stat_write_errs=90;stat_xdr_pipe_writes=0;stat_xdr_pipe_miss=0;stat_delete_success=4;stat_rw_timeout=1862;udf_read_reqs=0;udf_read_success=0;udf_read_errs_other=0;udf_write_reqs=0;udf_write_success=0;udf_write_err_others=0;udf_delete_reqs=0;udf_delete_success=0;udf_delete_err_others=0;udf_lua_errs=0;udf_scan_rec_reqs=0;udf_query_rec_reqs=0;udf_replica_writes=0;stat_proxy_reqs=7021;stat_proxy_reqs_xdr=0;stat_proxy_success=2121;stat_proxy_errs=4739;stat_ldt_proxy=0;stat_cluster_key_err_ack_dup_trans_reenqueue=607;stat_expired_objects=0;stat_evicted_objects=0;stat_deleted_set_objects=0;stat_evicted_objects_time=0;stat_zero_bin_records=0;stat_nsup_deletes_not_shipped=0;stat_compressed_pkts_received=0;err_tsvc_requests=110;err_tsvc_requests_timeout=0;err_out_of_space=0;err_duplicate_proxy_request=0;err_rw_request_not_found=17;err_rw_pending_limit=19;err_rw_cant_put_unique=0;geo_region_query_count=0;geo_region_query_cells=0;geo_region_query_points=0;geo_region_query_falsepos=0;fabric_msgs_sent=58002818;fabric_msgs_rcvd=57998870;paxos_principal=BB92B00F00A0142;migrate_msgs_sent=55749290;migrate_msgs_recv=55759692;migrate_progress_send=0;migrate_progress_recv=0;migrate_num_incoming_accepted=7228;migrate_num_incoming_refused=0;queue=0;transactions=101978550;reaped_fds=6;scans_active=0;basic_scans_succeeded=0;basic_scans_failed=0;aggr_scans_succeeded=0;aggr_scans_failed=0;udf_bg_scans_succeeded=0;udf_bg_scans_failed=0;batch_index_initiate=40457778;batch_index_queue=0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0;batch_index_complete=40456708;batch_index_timeout=1037;batch_index_errors=33;batch_index_unused_buffers=256;batch_index_huge_buffers=217168717;batch_index_created_buffers=217583519;batch_index_destroyed_buffers=217583263;batch_initiate=0;batch_queue=0;batch_tree_count=0;batch_timeout=0;batch_errors=0;info_queue=0;delete_queue=0;proxy_in_progress=0;proxy_initiate=7021;proxy_action=5519;proxy_retry=0;proxy_retry_q_full=0;proxy_unproxy=0;proxy_retry_same_dest=0;proxy_retry_new_dest=0;write_master=551089;write_prole=1055431;read_dup_prole=14232;rw_err_dup_internal=0;rw_err_dup_cluster_key=1814;rw_err_dup_send=0;rw_err_write_internal=0;rw_err_write_cluster_key=0;rw_err_write_send=0;rw_err_ack_internal=0;rw_err_ack_nomatch=1767;rw_err_ack_badnode=0;client_connections=366;waiting_transactions=0;tree_count=0;record_refs=3739898;record_locks=0;migrate_tx_objs=0;migrate_rx_objs=0;ongoing_write_reqs=0;err_storage_queue_full=0;partition_actual=296;partition_replica=572;partition_desync=0;partition_absent=3228;partition_zombie=0;partition_object_count=3739898;partition_ref_count=4096;system_free_mem_pct=61;sindex_ucgarbage_found=0;sindex_gc_locktimedout=0;sindex_gc_inactivity_dur=0;sindex_gc_activity_dur=0;sindex_gc_list_creation_time=0;sindex_gc_list_deletion_time=0;sindex_gc_objects_validated=0;sindex_gc_garbage_found=0;sindex_gc_garbage_cleaned=0;system_swapping=false;err_replica_null_node=0;err_replica_non_null_node=0;err_sync_copy_null_master=0;storage_defrag_corrupt_record=0;err_write_fail_prole_unknown=0;err_write_fail_prole_generation=0;err_write_fail_unknown=0;err_write_fail_key_exists=0;err_write_fail_generation=0;err_write_fail_generation_xdr=0;err_write_fail_bin_exists=0;err_write_fail_parameter=0;err_write_fail_incompatible_type=0;err_write_fail_noxdr=0;err_write_fail_prole_delete=0;err_write_fail_not_found=0;err_write_fail_key_mismatch=0;err_write_fail_record_too_big=90;err_write_fail_bin_name=0;err_write_fail_bin_not_found=0;err_write_fail_forbidden=0;stat_duplicate_operation=53184;uptime=1001388;stat_write_errs_notfound=0;stat_write_errs_other=90;heartbeat_received_self=0;heartbeat_received_foreign=145137042;query_reqs=0;query_success=0;query_fail=0;query_abort=0;query_avg_rec_count=0;query_short_running=0;query_long_running=0;query_short_queue_full=0;query_long_queue_full=0;query_short_reqs=0;query_long_reqs=0;query_agg=0;query_agg_success=0;query_agg_err=0;query_agg_abort=0;query_agg_avg_rec_count=0;query_lookups=0;query_lookup_success=0;query_lookup_err=0;query_lookup_abort=0;query_lookup_avg_rec_count=0 
3 : features 
    cdt-list;pipelining;geo;float;batch-index;replicas-all;replicas-master;replicas-prole;udf 
4 : cluster-generation 
    61 
5 : partition-generation 
    11811 
6 : edition 
    Aerospike Community Edition 
7 : version 
    Aerospike Community Edition build 3.7.2 
8 : build 
    3.7.2 
9 : services 
    10.0.3.1:3000;10.240.0.14:3000;10.0.3.1:3000;10.240.0.27:3000;10.0.3.1:3000;10.240.0.5:3000;10.0.3.1:3000;10.240.0.43:3000;10.0.3.1:3000;10.240.0.30:3000;10.0.3.1:3000;10.240.0.18:3000;10.0.3.1:3000;10.240.0.42:3000;10.0.3.1:3000;10.240.0.33:3000;10.0.3.1:3000;10.240.0.24:3000;10.0.3.1:3000;10.240.0.37:3000;10.0.3.1:3000;10.240.0.41:3000;10.0.3.1:3000;10.240.0.13:3000;10.0.3.1:3000;10.240.0.23:3000 
10 : services-alumni 
    10.0.3.1:3000;10.240.0.42:3000;10.0.3.1:3000;10.240.0.5:3000;10.0.3.1:3000;10.240.0.13:3000;10.0.3.1:3000;10.240.0.14:3000;10.0.3.1:3000;10.240.0.18:3000;10.0.3.1:3000;10.240.0.23:3000;10.0.3.1:3000;10.240.0.24:3000;10.0.3.1:3000;10.240.0.27:3000;10.0.3.1:3000;10.240.0.30:3000;10.0.3.1:3000;10.240.0.37:3000;10.0.3.1:3000;10.240.0.43:3000;10.0.3.1:3000;10.240.0.33:3000;10.0.3.1:3000;10.240.0.41:3000 

Answer 1

У меня есть несколько замечаний по поводу вашей конфигурации. Во-первых, transaction-threads-per-queue должно быть установлено 3 или 4 (не устанавливайте его на количество ядер).

Вторая связана с настройкой периодического чтения. Вы используете (по умолчанию) batch-index протокола и конфигурации PARAMS вам нужно настроить для пакетного чтения производительности являются:

• Вы batch-max-requests установлены очень высокими. Это, вероятно, влияет на загрузку вашего процессора и потребление памяти. Достаточно того, что есть небольшой дисбаланс в количестве ключей, к которым вы обращаетесь за каждый узел, и это отразится на графиках, которые вы указали. По крайней мере, это, возможно, проблема. Лучше, чтобы вы перебирали более мелкие партии, чем пытались получить 200 тыс. Записей за узел за раз.
• batch-index-threads - по умолчанию его значение равно 4, и вы устанавливаете его на 32 (максимум 64). Вы должны сделать это постепенно, выполнив тот же тест и сравнив производительность. На каждой итерации настраивается выше, а затем вниз, если она снижается в производительности. Например: тест с 32, +8 = 40, +8 = 48, -4 = 44. Нет простого правила для настройки, вам нужно будет настроить итерации на аппаратном обеспечении, которое вы будете использовать , и контролировать производительность.
• batch-max-buffer-per-queue - это более непосредственно связано с количеством одновременных операций пакетного чтения, которые может поддерживать узел. Каждый запрос на чтение партии будет потреблять по меньшей мере один буфер (если данные не могут быть помещены в 128K). Если у вас недостаточно их выделенных для поддержки количества одновременных запросов на чтение в пакетном режиме, вы получите исключения с кодом ошибки 152 BATCH_QUEUES_FULL. Отслеживайте и регистрируйте такие события четко, потому что это означает, что вам нужно повысить это значение. Обратите внимание, что это количество буферов за очередь. Каждый рабочий поток рабочего ответа имеет свою собственную очередь, поэтому у вас будет batch-index-threads x batch-max-buffer-per-queue буферов, каждый из которых принимает 128 Кбайт ОЗУ. batch-max-unused-buffers позволяет использовать память всех этих буферов, уничтожая неиспользуемые буферы до тех пор, пока их количество не будет уменьшено. Есть накладные расходы на выделение и уничтожение этих буферов, поэтому вы не хотите устанавливать слишком низкую по сравнению с общей суммой. Ваша текущая стоимость составляет 32 x 256 x 128KB = 1GB.

Наконец, вы сохраняете свои данные в файловой системе. Это нормально для примеров разработки, но не рекомендуется для производства. В GCE вы можете установить SSD SSD или SSD NVMe для хранения данных, и они должны быть initialized и использоваться в качестве блочных устройств. Взгляните на GCE recommendations для более подробной информации. Я подозреваю, что у вас есть предупреждения в вашем журнале о том, что устройство не поддерживает.

Вероятно, что один из ваших узлов является выбросом относительно количества его разделов (и, следовательно, числа объектов). Вы можете подтвердить это с помощью asadm -e 'asinfo -v "objects"'. Если это так, вы можете завершить этот узел и создать новый. Это заставит перераспределять разделы. Это вызывает миграцию, которая занимает больше времени на сервере CE, чем в EE.