Aerospike - 从磁盘集群迁移到内存中集群的延迟没有改善
首先，我们在AWS中有一个具有5个i2.2xlarge类型节点的空中飞行集群，我们的生产队伍约有200台服务器用于存储/检索数据。集群的aerospike配置如下 -
service {
user root
group root
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 4
fabric-workers 8
transaction-pending-limit 100
proto-fd-max 25000
}
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
port 3002 # Heartbeat port for this node.
# List one or more other nodes, one ip-address & port per line:
mesh-seed-address-port <IP> 3002
mesh-seed-address-port <IP> 3002
mesh-seed-address-port <IP> 3002
mesh-seed-address-port <IP> 3002
# mesh-seed-address-port <IP> 3002
interval 250
timeout 10
}
fabric {
port 3001
}
info {
port 3003
}
}
namespace FC {
replication-factor 2
memory-size 7G
default-ttl 30d # 30 days, use 0 to never expire/evict.
high-water-disk-pct 80 # How full may the disk become before the server begins eviction
high-water-memory-pct 70 # Evict non-zero TTL data if capacity exceeds # 70% of 15GB
stop-writes-pct 90 # Stop writes if capacity exceeds 90% of 15GB
storage-engine device {
device /dev/xvdb1
write-block-size 256K
}
}
正确处理与命名空间“FC”相对应的流量，延迟时间在14毫秒内，如下图所示，使用石墨绘制 -
然而，在打开另一个命名空间时，同一群集上的流量要高得多，它开始提供大量超时和更长的延迟，因为我们扩大了使用5个节点的相同群集的服务器数量（增加数量）使用以下命名空间配置 -
，从20到40到60）逐步执行服务器namespace HEAVYNAMESPACE {
replication-factor 2
memory-size 35G
default-ttl 30d # 30 days, use 0 to never expire/evict.
high-water-disk-pct 80 # How full may the disk become before the server begins eviction
high-water-memory-pct 70 # Evict non-zero TTL data if capacity exceeds # 70% of 35GB
stop-writes-pct 90 # Stop writes if capacity exceeds 90% of 35GB
storage-engine device {
device /dev/xvdb8
write-block-size 256K
}
}
以下是观察结果 -
---- FC命名空间----
20 - servers, 6k Write TPS, 16K Read TPS
set latency = 10ms
set timeouts = 1
get latency = 15ms
get timeouts = 3
40 - servers, 12k Write TPS, 17K Read TPS
set latency = 12ms
set timeouts = 1
get latency = 20ms
get timeouts = 5
60 - servers, 17k Write TPS, 18K Read TPS
set latency = 25ms
set timeouts = 5
get latency = 30ms
get timeouts = 10-50 (fluctuating)
---- ---- HEAVYNAMESPACE
20 - del servers, 6k Write TPS, 16K Read TPS
set latency = 7ms
set timeouts = 1
get latency = 5ms
get timeouts = 0
no of keys = 47 million x 2
disk usage = 121 gb
ram usage = 5.62 gb
40 - del servers, 12k Write TPS, 17K Read TPS
set latency = 15ms
set timeouts = 5
get latency = 12ms
get timeouts = 2
60 - del servers, 17k Write TPS, 18K Read TPS
set latency = 25ms
set timeouts = 25-75 (fluctuating)
get latency = 25ms
get timeouts = 2-15 (fluctuating)
* 设置延迟是指设置aerospike缓存键的延迟，同样也可以获取密钥。
我们不得不在达到60台服务器后关闭命名空间“HEAVYNAMESPACE”。
然后我们开始了一个新的POC，其中一个集群的节点是AWS的r3.4xlarge实例（在此处查找详细信息https://aws.amazon.com/ec2/instance-types/），其中airospike配置的关键区别在于内存仅用于缓存，希望它会提供更好的性能。这是aerospike.conf文件 -
service {
user root
group root
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 16
transaction-queues 16
transaction-threads-per-queue 4
proto-fd-max 15000
}
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
port 3002 # Heartbeat port for this node.
# List one or more other nodes, one ip-address & port per line:
mesh-seed-address-port <IP> 3002
mesh-seed-address-port <IP> 3002
mesh-seed-address-port <IP> 3002
mesh-seed-address-port <IP> 3002
mesh-seed-address-port <IP> 3002
interval 250
timeout 10
}
fabric {
port 3001
}
info {
port 3003
}
}
namespace FC {
replication-factor 2
memory-size 30G
storage-engine memory
default-ttl 30d # 30 days, use 0 to never expire/evict.
high-water-memory-pct 80 # Evict non-zero TTL data if capacity exceeds # 70% of 15GB
stop-writes-pct 90 # Stop writes if capacity exceeds 90% of 15GB
}
我们仅从FC名称空间开始，并且只有在我们看到FC命名空间的重大改进时才决定继续使用HEAVYNAMESPACE，但我们没有。以下是节点计数和服务器计数的不同组合的当前观察结果 -
当前统计信息
观察点1 - 4个服务130个服务器的节点。 Point 2 - 5个节点，服务于80台服务器。 Point 3 - 5个节点，为100台服务器提供服务。
这些观察点在下图中突出显示 -
获得延迟 -
设置成功（给出集群处理的负载的度量） -
我们也观察到了 -
- 群集中的总内存使用量为5.52 GB（144 GB）。在28.90 GB中，节点内存使用量约为1.10 GB。
- 还没有观察到写入失败。
- 偶尔获得/设置超时看起来很好。
- 没有被驱逐的物品。
结论
通过使用仅内存配置，我们没有看到我们预期的改进。我们想得到一些指示，能够以相同的成本扩大规模 - - 通过调整aerospike配置 - 或者使用一些更合适的AWS实例类型（即使这会导致成本削减）。
更新
在其中一个aerospike服务器上输出top命令，以显示SI（@Sunil在他的回答中指出） -
$ top
top - 08:02:21 up 188 days, 48 min, 1 user, load average: 0.07, 0.07, 0.02
Tasks: 179 total, 1 running, 178 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.4%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 125904196k total, 2726964k used, 123177232k free, 148612k buffers
Swap: 0k total, 0k used, 0k free, 445968k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
63421 root 20 0 5217m 1.6g 4340 S 6.3 1.3 461:08.83 asd
如果我没错，SI似乎是0.2％。我在群集的所有节点上检查了相同的内容，其中一个节点为0.2％，其余节点为0.1％。
此外，这是同一节点上网络统计数据的输出 -
$ sar -n DEV 10 10
Linux 4.4.30-32.54.amzn1.x86_64 (ip-10-111-215-72) 07/10/17 _x86_64_ (16 CPU)
08:09:16 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:09:26 lo 12.20 12.20 5.61 5.61 0.00 0.00 0.00 0.00
08:09:26 eth0 2763.60 1471.60 299.24 233.08 0.00 0.00 0.00 0.00
08:09:26 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:09:36 lo 12.00 12.00 5.60 5.60 0.00 0.00 0.00 0.00
08:09:36 eth0 2772.60 1474.50 300.08 233.48 0.00 0.00 0.00 0.00
08:09:36 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:09:46 lo 17.90 17.90 15.21 15.21 0.00 0.00 0.00 0.00
08:09:46 eth0 2802.80 1491.90 304.63 245.33 0.00 0.00 0.00 0.00
08:09:46 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:09:56 lo 12.00 12.00 5.60 5.60 0.00 0.00 0.00 0.00
08:09:56 eth0 2805.20 1494.30 304.37 237.51 0.00 0.00 0.00 0.00
08:09:56 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:10:06 lo 9.40 9.40 5.05 5.05 0.00 0.00 0.00 0.00
08:10:06 eth0 3144.10 1702.30 342.54 255.34 0.00 0.00 0.00 0.00
08:10:06 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:10:16 lo 12.00 12.00 5.60 5.60 0.00 0.00 0.00 0.00
08:10:16 eth0 2862.70 1522.20 310.15 238.32 0.00 0.00 0.00 0.00
08:10:16 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:10:26 lo 12.00 12.00 5.60 5.60 0.00 0.00 0.00 0.00
08:10:26 eth0 2738.40 1453.80 295.85 231.47 0.00 0.00 0.00 0.00
08:10:26 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:10:36 lo 11.79 11.79 5.59 5.59 0.00 0.00 0.00 0.00
08:10:36 eth0 2758.14 1464.14 297.59 231.47 0.00 0.00 0.00 0.00
08:10:36 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:10:46 lo 12.00 12.00 5.60 5.60 0.00 0.00 0.00 0.00
08:10:46 eth0 3100.40 1811.30 328.31 289.92 0.00 0.00 0.00 0.00
08:10:46 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
08:10:56 lo 9.40 9.40 5.05 5.05 0.00 0.00 0.00 0.00
08:10:56 eth0 2753.40 1460.80 297.15 231.98 0.00 0.00 0.00 0.00
Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
Average: lo 12.07 12.07 6.45 6.45 0.00 0.00 0.00 0.00
Average: eth0 2850.12 1534.68 307.99 242.79 0.00 0.00 0.00 0.00
从上面可以看出，我认为每秒处理的数据包总数应该是2850.12 + 1534.68 = 4384.8（rxpck / s和txpck / s之和），它在每秒250K数据包内，如{{3在@ RonenBotzer的回答中提及。
更新2
我在群集的一个节点上运行了asadm命令后跟show latency，并且从输出中看来，读取和写入都没有超过1 ms的延迟 -
Admin> show latency
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~read Latency~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node Time Ops/Sec >1Ms >8Ms >64Ms
. Span . . . .
ip-10-111-215-72.ec2.internal:3000 11:35:01->11:35:11 1242.1 0.0 0.0 0.0
ip-10-13-215-20.ec2.internal:3000 11:34:57->11:35:07 1297.5 0.0 0.0 0.0
ip-10-150-147-167.ec2.internal:3000 11:35:04->11:35:14 1147.7 0.0 0.0 0.0
ip-10-165-168-246.ec2.internal:3000 11:34:59->11:35:09 1342.2 0.0 0.0 0.0
ip-10-233-158-213.ec2.internal:3000 11:35:00->11:35:10 1218.0 0.0 0.0 0.0
Number of rows: 5
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~write Latency~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node Time Ops/Sec >1Ms >8Ms >64Ms
. Span . . . .
ip-10-111-215-72.ec2.internal:3000 11:35:01->11:35:11 33.0 0.0 0.0 0.0
ip-10-13-215-20.ec2.internal:3000 11:34:57->11:35:07 37.2 0.0 0.0 0.0
ip-10-150-147-167.ec2.internal:3000 11:35:04->11:35:14 36.4 0.0 0.0 0.0
ip-10-165-168-246.ec2.internal:3000 11:34:59->11:35:09 36.9 0.0 0.0 0.0
ip-10-233-158-213.ec2.internal:3000 11:35:00->11:35:10 33.9 0.0 0.0 0.0
Number of rows: 5
2 个答案:
答案 0 :(得分：4)
Aerospike有几个modes for storage你可以配置：
- 内存中没有持久性的数据
- 内存中的数据，持久存储到磁盘
- SSD上的数据，内存中的primary index（AKA Hybrid Memory架构）
内存中优化
Release 3.11和release 3.12 Aerospike包括内存命名空间的几项重大性能改进。
其中包括如何表示分区，从单个红黑树到小树枝（许多子树）。应适当使用新的配置参数partition-tree-sprigs和partition-tree-locks。在您的情况下，由于r3.4xlarge实例具有122G的DRAM，因此您可以承担与将partition-tree-sprigs设置为最大值4096相关的311M开销。
您还应该考虑auto-pin=cpu设置。此选项需要Linux Kernal＆gt; = 3.19，它是Ubuntu＆gt; = 15.04的一部分（但还不是很多其他）。
群集改进
最近的releases 3.13 and 3.14包括重写集群管理器。一般来说，您应该考虑使用最新版本，但我指出了会直接影响您的表现的方面。
EC2 Networking and Aerospike
您没有显示群集本身的延迟数，因此我怀疑问题出在网络上，而不是节点上。
较旧的实例系列类型（例如r3，c3，i2）附带ENI - 具有单个发送/接收队列的NIC。随着CPU数量的增加，访问此队列的内核的软件中断可能成为瓶颈，所有这些都需要等待轮到他们使用NIC。在using multiple ENIs with Aerospike的Aerospike社区讨论论坛中有一篇知识库文章，以解决您最初使用此类实例获得的单个ENI的有限性能。当您在使用ENI的实例中时，Aerospike网站上的Amazon EC2 deployment guide会谈到使用RPS来最大化TPS。
或者，您应该考虑移动到具有多队列ENAs的较新实例（r4，i3等）。这些不需要RPS，并且在不添加额外卡的情况下支持更高的TPS。他们也碰巧有更好的芯片组，成本明显低于他们的兄弟姐妹（r4比r3便宜约30％，i3约为i2价格的1/3）。
答案 1 :(得分：3)
你的头衔有误导性。请考虑更改它。您从磁盘上移动到内存中。 mem + disk意味着数据在磁盘和mem上（使用data-in-memory = true）。
我最好的猜测是，一个CPU是做网络I / O的瓶颈。 您可以查看顶部输出并查看si（软件中断） 如果一个CPU显示比另一个高得多， 您可以尝试的最简单的事情是RPS（接收数据包转向）
def _supercheck(type_, obj):
try:
if issubclass(obj, type_):
return obj
except TypeError:
# obj is not a type so issubclass throws a TypeError
pass
if isinstance(obj, type_):
return type(obj)
raise TypeError(
"super(type, obj): obj must be an instance or subtype of type")
class super_:
def __init__(self, type_, obj):
# simplified for the two-argument case
self.type_ = type_
self.obj = obj
self.obj_type = _supercheck(type_, obj)
def __getattribute__(self, name):
if name == '__class__':
# __class__ should always come from this object, not
# the represented MRO.
return super().__getattribute__(name)
# avoid infinite recursion issues
sd = super().__getattribute__('__dict__')
starttype = sd['obj_type']
type_ = sd['type_']
obj = sd['obj']
mro = iter(starttype.__mro__)
# skip past the start type in the MRO
for tp in mro:
if tp == type_:
break
# Search for the attribute on the remainder of the MRO
for tp in mro:
attrs = vars(tp)
if name in attrs:
res = attrs[name]
# if it is a descriptor object, bind it
descr = getattr(type(res), '__get__', None)
if descr is not None:
res = descr(
res,
None if obj is starttype else obj,
starttype)
return res
return super().__getattribute__(name)
一旦确认其网络瓶颈， 您可以按照@Ronen
的建议尝试ENA详细介绍， 如果只有FC的15ms延迟，假设它的tps很低。 但是当你在生产中加入HEAVYNAMESPACE的高负荷时， 随着您添加更多客户端节点并因此添加tps，延迟会不断增加。
同样在你的POC中，延迟随着客户端节点的增加而增加。 即使有130台服务器，延迟也不到15毫秒。它的部分优点。 我不确定我是否理解你的set_success图。用ktps来表示它。
<强>更新：
在查看服务器端延迟直方图后，看起来服务器运行正常。 最有可能是客户问题。检查客户端计算机上的CPU和网络。
- 如何找出Set在Aerospike中占用多少磁盘空间？
- 如何在云上设置和配置aerospike集群
- Aerospike：写腌制失败（Disk＆amp; Memory Available＆gt; 70％）
- Aerospike：错误导致群集失败（重启一个节点时在2节点群集上）
- 如何使用单个节点设置aerospike集群？
- Aerospike - 从磁盘集群迁移到内存中集群的延迟没有改善
- Aerospike-go-cilent：高延迟和连接卡在CLOSE_WAIT中
- 从golang连接到kubernetes-aerospike网状集群
- hadoop混合集群上的延迟
- 错误：（1）Aerospike中的不稳定群集如何解决此问题
- 我写了这段代码，但我无法理解我的错误
- 我无法从一个代码实例的列表中删除 None 值，但我可以在另一个实例中。为什么它适用于一个细分市场而不适用于另一个细分市场？
- 是否有可能使 loadstring 不可能等于打印？卢阿
- java中的random.expovariate()
- Appscript 通过会议在 Google 日历中发送电子邮件和创建活动
- 为什么我的 Onclick 箭头功能在 React 中不起作用？
- 在此代码中是否有使用“this”的替代方法？
- 在 SQL Server 和 PostgreSQL 上查询，我如何从第一个表获得第二个表的可视化
- 每千个数字得到
- 更新了城市边界 KML 文件的来源？