美国航空航天公司的不良延迟

Question

在2节点机群的裸金属机中，我们可以在软层上运行飞机。我们的配置文件平均大小为1.5KB，在峰值时，每个节点的操作将大约为6000 ops/秒。潜伏期都很好，峰值> 1ms将在5%左右。

现在我们计划迁移到aws。所以我们启动了2台i3.x大型机器。我们运行的基准测试对象大小为1.5KB，加载为3x。结果满意，约4~5%(>1ms)。现在我们开始实际的处理，高峰时的延迟跃升到25-30%，也就是> 1ms，并且它可以容纳的最大值大约是5K ops/秒。因此，我们又添加了一个节点，进行了基准测试(4.5KB对象大小和3x加载)。结果为2-4%(>1ms)。加入聚类后，峰值降至16-22%.我们增加了一个节点，峰值现在是10-15%.

aws中的版本是aerospike-server-community-3.15.0.2，Sl中的版本是Aerospike企业版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的性能特征与您在软层上的不同。如果您运行软盘上的飞机，您将得到0.5TPS。

Piyush的评论提到了行动，这是一个开源工具Aerospike创建的，用来测试带有真实数据库工作负载的SSD。ACT的目的是找到可以依赖SSD来传递所需延迟的持续速率。对于数据库来说，突发速率并不重要。

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

因此，您获取ACT信息，并使用它来执行容量规划。您需要知道的主要因素是平均对象大小(您可以发现使用objsz直方图)、对象数量(同样可以通过阿萨德姆获得)、峰值读取TPS和峰值写入TPS (您提到的60 60Ktps是如何在读和写之间分离的)。

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