gpt4 book ai didi

java - Aerospike 中 batchRequests 的低性能

转载 作者:搜寻专家 更新时间:2023-11-01 03:35:04 26 4
gpt4 key购买 nike

我有一个执行大量 batchGet 的应用程序(主要使用 ~2000 个键)。这是我使用的代码:

AerospikeClient aerospike = new AerospikeClient("10.0.240.2", port)

public byte[][] getBatch(byte[][] keys) {
Key[] aeroKeys = new Key[keys.length];
for (int i = 0; i < keys.length; i++) {
aeroKeys[i] = new Key(NAMESPACE, setName, keys[i]);
}
Record[] records = aerospike.get(batchPolicy, aeroKeys);
byte[][] response = new byte[keys.length][];

for (int i = 0; i < keys.length; i++) {
if (records[i] != null) {
response[i] = (byte[]) records[i].getValue(DEFAULT_BIN_NAME);
}
}
return response;
}

当我有一个请求时,这段代码可以完美且快速地运行。但是当我运行多个并行线程执行 batchGets 时,速度非常慢(性能下降与线程数量成线性关系,例如 4 个线程 = 慢 4 倍,8 个线程 = 慢 8 倍)。我在监控中没有看到太多 CPU 或 I/O 使用情况,所以我怀疑有什么东西在等待,但我不知道它是什么。

我尝试了很多不同的配置,这是我现在的配置(16 核服务器):

    service-threads 16
transaction-queues 16
transaction-threads-per-queue 16
batch-index-threads 16
batch-max-buffers-per-queue 1000
proto-fd-max 15000
batch-max-requests 2000000

知道发生了什么事吗?

编辑 1:命名空间配置:

namespace test {
replication-factor 2
memory-size 5G
default-ttl 0 # 30 days, use 0 to never expire/evict.
ldt-enabled true

storage-engine device {
file /data/aerospike.dat
filesize 300G
disable-odirect true
write-block-size 1M
max-write-cache 1G
}
}

和延迟统计:

$ asadm -e 'show latency' 
~~~~~~~~~~~~~~~~~~~~~~~~proxy Latency~~~~~~~~~~~~~~~~~~~~~~~~
Node Time Ops/Sec >1Ms >8Ms >64Ms
. Span . . . .
p 23:00:09-GMT->23:00:19 0.0 0.0 0.0 0.0
Number of rows: 1

~~~~~~~~~~~~~~~~~~~~~~~~query Latency~~~~~~~~~~~~~~~~~~~~~~~~
Node Time Ops/Sec >1Ms >8Ms >64Ms
. Span . . . .
p 23:00:09-GMT->23:00:19 0.0 0.0 0.0 0.0
Number of rows: 1

~~~~~~~~~~~~~~~~~~~~~~~~~reads Latency~~~~~~~~~~~~~~~~~~~~~~~~~
Node Time Ops/Sec >1Ms >8Ms >64Ms
. Span . . . .
p 23:00:09-GMT->23:00:19 15392.1 92.67 62.89 6.03
Number of rows: 1

~~~~~~~~~~~~~~~~~~~~~~~~~udf Latency~~~~~~~~~~~~~~~~~~~~~~~~~
Node Time Ops/Sec >1Ms >8Ms >64Ms
. Span . . . .
p 23:00:09-GMT->23:00:19 0.0 0.0 0.0 0.0
Number of rows: 1

~~~~~~~~~~~~~~~~~~~~writes_master Latency~~~~~~~~~~~~~~~~~~~~
Node Time Ops/Sec >1Ms >8Ms >64Ms
. Span . . . .
p 23:00:09-GMT->23:00:19 0.0 0.0 0.0 0.0
Number of rows: 1

编辑 2:

我觉得这个问题和java客户端有点关系。我做了以下实验:在不同的机器上创建了我的应用程序的两个实例,都访问一个 aerospike 服务器我设置了一个负载平衡来在这两个服务器之间分配请求。通过此配置,我获得了双倍的吞吐量。

当所有请求都来自单个服务器时,aerospike 服务器现在可以正确接收和响应双倍的流量。但是如果我查看我的 java 应用程序服务器,它不会消耗 CPU,所以我不受 CPU 限制。在请求期间网络似乎非常密集。它在服务器中显示 5Gps。

因此,对于 5 台应用服务器,每台都有一个 CPU,我可以将 1Gps 的网络流量发送到服务器并且它可以正常工作。但是,如果我在一台 8 核机器中有一个应用程序实例,它似乎会将服务器请求排入队列。

按照文档中的建议,我的代码对所有请求使用单个 AerospikeClient 实例。我从不关闭这个 aerospike 客户端连接,我在系统工作时保持打开状态。

编辑 3:

$asloglatency -h reads
reads
Jan 04 2016 19:12:55
% > (ms)
slice-to (sec) 1 8 64 ops/sec
-------------- ------ ------ ------ --------
19:13:25 10 87.27 14.87 0.00 242.7
19:13:35 10 89.44 21.90 0.00 3432.0
19:13:45 10 89.68 26.87 0.00 4981.6
19:13:55 10 89.61 25.62 0.00 5469.9
19:14:05 10 89.89 27.56 0.00 6190.8
19:14:15 10 90.59 33.84 0.30 6138.2
19:14:25 10 89.79 29.44 0.00 5393.2


ubuntu@aerospike1:~$ asloglatency -h batch_index_reads
batch_index_reads
Jan 04 2016 19:30:36
% > (ms)
slice-to (sec) 1 8 64 ops/sec
-------------- ------ ------ ------ --------
19:30:46 10 100.00 100.00 3.33 3.0
19:30:56 10 100.00 100.00 23.40 9.4
19:31:06 10 100.00 100.00 27.59 11.6
19:31:16 10 100.00 100.00 31.30 13.1
19:31:26 10 100.00 100.00 30.00 13.0
19:31:36 10 100.00 100.00 27.14 14.0

编辑 4:

$ asadm -e "show distribution"
~~~~~~~~~~~~~~~~~~~test - TTL Distribution in Seconds~~~~~~~~~~~~~~~~~~
Percentage of records having ttl less than or equal to value
measured in Seconds
Node 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
aerospike1 0 0 0 0 0 0 0 0 0 0
aerospike2 0 0 0 0 0 0 0 0 0 0
Number of rows: 2

~~~~~~~~~~~~test - Object Size Distribution in Record Blocks~~~~~~~~~~~
Percentage of records having objsz less than or equal to
value measured in Record Blocks
Node 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
aerospike1 3 3 3 3 3 65 94 97 100 100
aerospike2 3 3 3 3 3 65 94 97 100 100

编辑 5:

$ asadm -e "show stat like batch"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Service Statistics~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NODE : aerospike1 aerospike2
batch_errors : 0 0
batch_index_complete : 403423 3751948
batch_index_created_buffers : 8425500 169997886
batch_index_destroyed_buffers: 8423984 169994324
batch_index_errors : 3 8305
batch_index_huge_buffers : 7075094 64191339
batch_index_initiate : 403428 3760270
batch_index_queue : 0:0,0:0,0:0,1:99,1:205,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0,0:0 1:212,0:0,1:25,1:87,0:0,1:13,1:33,1:66,1:199,1:183,1:221,1:256,1:198,1:39,1:0,0:0,0:0,0:0,1:26,0:0,0:0,0:0,0:0,0:0,1:53,0:0,0:0,0:0,0:0,1:172,1:206,0:0
batch_index_timeout : 0 0
batch_index_unused_buffers : 1210 1513
batch_initiate : 0 0
batch_queue : 0 0
batch_timeout : 0 0
batch_tree_count : 0 0

$ iostat -x 1 3
Linux 4.2.0-18-generic (aerospike1) 01/05/2016 _x86_64_ (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
2.31 0.00 7.56 5.50 0.00 84.64

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.79 4.69 0.97 152.23 21.28 61.31 0.01 2.37 2.43 2.07 1.46 0.83
sdb 0.03 1828.07 1955.80 62.88 87448.89 8924.42 95.48 3.81 1.88 0.55 43.26 0.08 15.45

avg-cpu: %user %nice %system %iowait %steal %idle
4.57 0.00 18.91 0.00 0.00 76.52

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
3.91 0.00 16.27 0.00 0.00 79.82

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 1.00 4.00 4.00 16.00 8.00 0.01 2.40 12.00 0.00 2.40 1.20
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

最佳答案

您的磁盘似乎是瓶颈。如果您看到 asadm 延迟输出,60% 的读取时间超过 8 毫秒。您可以使用 iostat 命令进行交叉检查。根据延迟,我猜您正在使用旋转驱动器。

根据您的配置,您的数据不在内存中。因此,每次读取都需要命中磁盘,并且所有读取都将是磁盘上的随机读取。这对旋转驱动不利。

当数据只在磁盘上时,Aerospike 推荐使用 ssd。如果您对命名空间使用内存中数据选项,则可以将数据持久保存在旋转驱动器中。请阅读有关 Aerospike 存储选项的更多信息。

关于java - Aerospike 中 batchRequests 的低性能,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34504583/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com