aws 的 aerospike 不良延迟

Question

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

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

aws中的版本是aerospike-server-community-3.15.0.2 Sl中的版本是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

这归结为 i3 节点的 SSD 的性能特征与您在 Softlayer 上的差异。如果你运行 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 评级是 4x，这意味着 full 1900G SSD 可以执行 8Ktps 读取，4Ktps 写入标准 1.5K 对象大小，128K 块大小，并保持在 95% < 1ms，99 % < 8 毫秒，99.9% < 64 毫秒。 这对 SSD 来说不是特别好。相比之下，美光 9200 PRO 的速率为 94.5 倍，TPS 负载高出近 24 倍。更重要的是，使用 i3.xlarge，您 与邻居 共享一半的驱动器。没有办法限制 IOPS 以便每个人得到一半，只有一个存储分区。这意味着您可以预期源自邻居的延迟峰值。 i3.2xlarge 是为您提供整个 SSD 的最小实例。

因此，您获取 ACT 信息并使用它来执行 capacity planning. The main factors you need to know are the average object size (you can find that using objsz histogram), number of objects (again, available via asadm）、峰值读取 TPS 和峰值写入 TPS（您提到的 60Ktps 如何在读取和写入之间分配？）。

检查日志中的 cache-read-pct values. If they're in the range of 10% or higher you should be raising your post-write-queue 值以获得更好的读取延迟（并减少驱动器的 IOPS 压力）。

aws 的 aerospike 不良延迟

aerospike bad latencies with aws

latency

aerospike