Question

我们在2节点集群的裸机中的软层中运行了aerospike。我们的配置文件平均大小为1.5 KB，在峰值时，每个节点的操作大约为6000 ops / sec。延迟都很好，在峰值时> 1毫秒将是5％左右。

现在我们计划迁移到aws。所以我们启动了2台i3.xlarge机器。我们使用1.5倍的对象大小和3倍负载运行基准测试。结果令人满意，即约4-5％（> 1ms）。现在我们开始实际处理，峰值的延迟跳跃到25-30％，即＆gt; 1ms和最大可容纳的是大约5K操作/秒。所以我们添加了一个节点，我们做了基准测试（4.5KB对象大小和3x负载）。结果为2-4％（> 1ms）。现在添加到集群后，峰值降至16-22％。我们又添加了一个节点，峰值现在为10-15％。

aws中的版本是aerospike-server-community-3.15.0.2.S1中的版本是Aerospike Enterprise Edition 3.6.3

我们的配置如下

#Aerospike database configuration file.
service {
    user xxxxx 
    group xxxxx 
    run-as-daemon
    paxos-single-replica-limit 1 # Number of nodes where the replica count is automatically reduced to 1.
    pidfile /var/run/aerospike/asd.pid 
    service-threads 8 
    transaction-queues 8
    transaction-threads-per-queue 8
    proto-fd-max 15000
}

logging {

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

network {
    service {
        port 13000
        address h1 reuse-address
    }

    heartbeat {
        mode mesh
        port 13001
        address h1

        mesh-seed-address-port h1 13001
        mesh-seed-address-port h2 13001
        mesh-seed-address-port h3 13001
        mesh-seed-address-port h4 13001
        interval 150
        timeout 10
    }

    fabric {
        port 13002
        address h1
    }

    info {
        port 13003
        address h1
    }
}

namespace XXXX { 
    replication-factor 2
    memory-size 27G
    default-ttl 10d
    high-water-memory-pct 70
    high-water-disk-pct 60
    stop-writes-pct 90
    storage-engine device {
        device /dev/nvme0n1
        scheduler-mode noop
        write-block-size 128K
    }
}

如何降低aws的延迟？

Answer 1

这归结为与Softlayer相比，i3节点的SSD性能特征的差异。如果您运行了Aerospike on a floppy disk，那么您将获得0.5TPS。

Piyush的评论提到了ACT，这是开源工具Aerospike创建的，用于将SSD与真实的数据库工作负载进行对比。 ACT的目的是找到可依赖SSD的持续速率，以提供您想要的延迟。对于数据库而言，突发率并不重要。

Aerospike的性能工程团队使用ACT查找i3 1900G SSD可以执行的操作，以及published the results in a post。其ACT等级为4倍，这意味着完整 1900G SSD可以进行8Ktps读取，4Ktps写入，标准1.5K对象大小，128K块大小，并保持在95％<100％。 1毫秒，99％＆lt; 8毫秒，99.9％＆lt; 8毫秒64ms的。 这对SSD来说不是特别好。相比之下，美光9200 PRO的速率为94.5倍，是TPS负载的近24倍。更重要的是，使用i3.xlarge，与邻居分享一半的驱动器。没有办法限制IOPS，以便你们每个人都获得一半，只有一个存储分区。这意味着您可以预期来自邻居的延迟峰值。 i3.2xlarge是为您提供整个SSD的最小实例。

因此，您获取ACT信息并使用它来执行capacity planning。您需要知道的主要因素是平均对象大小（您可以使用objsz histogram找到），对象数量（同样可以通过asadm获得），峰值读取TPS和峰值写入TPS（如何使用您提到的60Ktps在读写之间分开？）。

检查日志中的cache-read-pct值。如果它们在10％或更高的范围内，您应该提高post-write-queue值以获得更好的读取延迟（并且还会降低驱动器的IOPS压力）。

aws

1 个答案: