【问题标题】：Wrong balance between Aerospike instances in cluster集群中 Aerospike 实例之间的错误平衡
【发布时间】：2016-06-07 00:34:27
【问题描述】：

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

通过查看 Google Cloud Monitoring Graphs，我注意到服务器之间的负载非常不平衡：一些服务器的 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

【问题讨论】：

您是否检查了这些节点的配置是否相同？您可以将配置添加到问题中吗？
@RonenBotzer 所有服务器都有相同的 conf 文件（有问题编辑）
让我知道这些配置更改是否有影响。可能是对象没有像预期的那样均匀分布（这是一个正态分布），但这种调整可能会加剧问题。我想听听它事后的表现。

标签： load-balancing google-cloud-platform key-value-store aerospike

【解决方案1】：

我有一些关于您的配置的信息。首先，transaction-threads-per-queue 应该设置为 3 或 4（不要设置为核心数）。

第二个与您的批量读取调整有关。您使用的是（默认）batch-index 协议，您需要为批量读取性能调整的配置参数是：

您将batch-max-requests 设置得非常高。这可能会影响您的 CPU 负载和内存消耗。您访问每个节点的密钥数量略有不平衡就足够了，这将反映在您显示的图表中。至少，这可能是问题所在。最好迭代较小的批次，而不是尝试一次为每个节点获取 20 万条记录。
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 中花费的时间要长得多。

【讨论】：

我的意思是您可以将一个大批量读取分解为几个较小的批量读取，但您说您没有看到批量更改产生效果。您节点上的主对象数量是多少？
那么每个节点的主对象数量大致相同吗？你能分享你的 AMC（或 asinfo）输出吗？
我想查看节点上的对象分布。你能做asadm -e 'asinfo -v "objects"' 并发布它的输出吗？另外，请将您的日志 grep 为“缓存读取”。我想看看你的 post-write-queue 上的缓存命中是什么。
我在上面的答案中更新了有关强制重新分配分区的信息。似乎 10.240.0.40:3000 的对象比其他对象少得多。您可能想杀死它并启动一个新实例。此外，您可能希望动态增加post-write-queue，然后检查是否获得更好的缓存读取命中率。这假设您有可用的内存。增加的是每台设备。
Aerospike 对分区的对象分布非常正常。当在极少数情况下分区数量没有达到应有的水平时，就会出现问题。有一个 JIRA 问题对其开放，因此已排队等待修复，但目前解决方法可能会解决该问题。至于写入后队列，其中包含更多块可能会提高缓存读取命中率，这将是有益的。如果没有，您可以随时将其调低。您可以在单个节点上执行此操作一段时间并对其进行监控。

【解决方案2】：

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

【讨论】：