Aerospike数据库配置文件。

Question

我有一个具有高负载的应用程序用于批量读取操作。我的Aerospike集群（v 3.7.2）有14台服务器，每台服务器在Google Cloud中有7GB RAM和2个CPU。

通过查看Google云监控图，我发现服务器之间的负载非常不平衡：某些服务器的CPU负载几乎为100％，而其他服务器的负载不到50％（图片如下）。即使经过数小时的操作，群集不平衡模式也不会发生变化。

我是否可以更改任何配置以使此群集更加同质？如何优化节点平衡？

修改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
        }
}

编辑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协议，并且您需要调整批处理读取性能的配置参数：

您batch-max-requests设置得非常高。这可能会影响您的CPU负载和内存消耗。这足以使每个节点访问的密钥数量略有不平衡，这将反映在您显示的图表中。至少，这可能是个问题。迭代较小的批次比尝试一次获取每个节点200K的记录更好。
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个缓冲区，每个缓冲区占用128K的RAM。 batch-max-unused-buffers限制了所有这些缓冲区的内存使用量，破坏了未使用的缓冲区，直到它们的数量减少为止。分配和销毁这些缓冲区会产生开销，因此您不希望将其设置为与总数相比过低。您当前的费用为32 x 256 x 128KB = 1GB。

最后，您将数据存储在文件系统中。这对开发实例很好，但不建议用于生产。在GCE中，您可以为数据存储配置SATA SSD或NVMe SSD，这些应该是initialized，并用作块设备。有关详细信息，请查看GCE recommendations。我怀疑你的日志中有关于设备无法跟上的警告。

您的某个节点可能是一个与其所拥有的分区数量（因此对象数量）有关的异常值。您可以使用asadm -e 'asinfo -v "objects"'进行确认。如果是这种情况，您可以终止该节点，并启动一个新节点。这将强制重新分配分区。这确实会触发迁移，这在CE服务器中比在EE服务器中需要更长的时间。

Answer 2

对于感兴趣的任何人，Aerospike Enterpirse 4.3引入了“均匀平衡”，可以均匀地平衡数据分区。在此处阅读更多信息：https://www.aerospike.com/blog/aerospike-4-3-all-flash-uniform-balance/

集群中Aerospike实例之间的错误平衡

Aerospike数据库配置文件。

2 个答案: