时间戳

首页 > 解决方案 > aerospike 与 aws 的不良延迟

latency - aerospike 与 aws 的不良延迟

问题描述

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

现在我们计划迁移到 aws。所以我们启动了 2 台 i3.xlarge 机器。我们以 1.5KB 的对象大小和 3 倍的负载运行基准测试。结果令人满意，大约为 4-5%(>1ms)。现在我们开始实际处理，峰值延迟跃升至 25-30%，即 > 1 毫秒，它可以容纳的最大值约为 5K 操作/秒。所以我们又增加了一个节点，我们做了基准测试（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中的延迟？

标签： latencyaerospike

解决方案

这归结为 i3 节点 SSD 的性能特征与 Softlayer 上的不同。如果您在软盘上运行 Aerospike，您将获得 0.5TPS。

Piyush 的评论提到了ACT，这是 Aerospike 创建的开源工具，用于对具有真实数据库工作负载的 SSD 进行基准测试。ACT 的重点是找到可以依靠 SSD 提供所需延迟的持续速率。突发率对数据库来说并不重要。

Aerospike 的性能工程团队已经使用 ACT 来发现 i3 1900G SSD 可以做什么，并在帖子中发布了结果。它的 ACT 等级是 4 倍，这意味着完整的1900G SSD 可以在标准 1.5K 对象大小、128K 块大小下进行 8Ktps 读取、4Ktps 写入，并且保持在 95% < 1ms、99% < 8ms、99.9% < 64ms。这对于 SSD 来说并不是特别好。相比之下，美光 9200 PRO 的速率为 94.5 倍，TPS 负载高出近 24 倍。更重要的是，使用 i3.xlarge，您可以与邻居共享一半的驱动器. 没有办法限制 IOPS，以便每个人得到一半，只有一个存储分区。这意味着您可以预期源自邻居的延迟峰值。i3.2xlarge 是为您提供整个 SSD 的最小实例。

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

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

推荐阅读