当前位置：首页 > 文章列表 > Golang > Go问答 > 最大程度提升在受限 NVMe AWS 磁盘上大小为 4-20kb 的文件更新效率（低带宽、低延迟）

最大程度提升在受限 NVMe AWS 磁盘上大小为 4-20kb 的文件更新效率（低带宽、低延迟）

来源：stackoverflow 2024-03-20 14:51:32 0浏览收藏

在 AWS c6gd.large 实例受限的 NVMe 磁盘上，为平均大小为 4-20 KB 的文件更新优化效率至关重要。由于带宽限制和低延迟，实现传统数据库变得困难。本文探索了各种解决方案，包括使用 Go 通道、Unix 数据报套接字和 SQLite3 进行缓冲和批量插入，以及使用 RocksDB 和 Badger 等数据库。通过基准测试，结果表明 SQLite3 和 unix 数据报套接字的组合可以实现 18,000 次请求/秒，而使用 fdatasync 的文件更新会显着降低性能。此外，文章讨论了文件系统日志排序和强制执行的可能性，以及使用其他消息队列解决方案的潜在好处。

问题内容

在解决我们无法使用数据库的问题陈述时，我们必须实现自己的数据库。

问题陈述：-

使用 blob（平均 4KB，最大 20KB）和 UUID 向服务器发出请求，并将 blob 存储在磁盘上，这听起来是密钥对 blobfs 的完美用例，但问题是，一个请求来自同一个 UUID 将再次生成，我们必须用新数据替换以前写入的数据，即在任何时候我们只关心最新的 blob。
来自同一个 UUID 的请求将每 10 秒发出一次。
可以向服务器发送SIGKILL来检查文件的完整性。丢失最后 3 秒内发出的请求的数据是可以的。不过，我们希望这个时间尽可能短。
写入次数远多于读取次数
我们想知道给定基础设施上可以支持的 UUID 的最大数量。

基础设施：-

我们有一个 c6gd.large AWS 实例，配备 4GB RAM、2 个 CPU、120GB NVMe。但 NVMe 的问题在于带宽受到 AWS 的限制（来源），但是我们确实获得了低延迟（150 微秒以内）。

如下所示，当存储在 5kb 的 bs 中时，我们比 1GB 获得更多的带宽。此外，创建新文件比覆盖现有文件更快。

到目前为止我已经尝试过：-

由于上述基准，对于每个请求，我都会使用每个 UUID 创建/更新一个文件，并将 blob 写入其中。
我尝试过 xfs 和 ext4 文件系统，ext4 的性能稍好一些，并且在 2 小时的测试中每秒提供大约 8.5k 请求。这意味着我们可以支持 85k 个探针，因为每个探针每 10 秒仅发送一次请求。
我使用 wrk 进行了测试，发现 CPU 使用率平均约为 70-80%，RAM 使用率约为 3GB（4GB 中）
我已使用 ext4 和 rw、seclabel、noatime、nodiratime、journal_async_commit、nobarrier 这些装载选项装载了磁盘。
注意：我单独对 http 服务器进行了基准测试，它支持 100k Req/sec，因此它不会成为瓶颈。
我使用了 golang，这就是我写入文件的方式。

我读过有关 RocksDB 架构的内容，LSM 树看起来很有前途，但我认为，考虑到 badwidth 仅为 100MBps 左右，压缩过程不会给我们带来巨大的好处。我这样想有错吗？

另一个需要考虑的问题是，当批量中有 1000 次写入写入磁盘时，我假设 fs (ext4) 日志会对这些操作进行排序。这个假设正确吗？如果没有，有没有办法强制执行？另外，我可以每（比如 100 毫秒）批量处理这些写入请求吗？

还有其他我可以尝试的想法吗？

正确答案

想法

缓冲请求（go 通道、unix 数据报套接字、redis...）
每 100 毫秒批量更新插入

尝试过

badger 数据库和 go 通道
rocks db 和 unix 数据报套接字
sqlite3 和 unix 数据报套接字

未尝试

rabbitmq
卡夫卡
纳兹
postgresql
redis

front	communication	db	result
net/http(go)	go channel	badger(go)	killed(oom)
net/http(go)	unix datagram socket	rocksdb(rust)	many timeouts
net/http(go)	unix datagram socket	sqlite3(rust)	18,000 rps

基准结果

延迟分布（毫秒）和每秒请求

50%	75%	90%	99%	rps	description
0.6	0.7	1.2	9.9	176k	1. create files(direct)
2.4	4.5	7.1	14	54k	2. create files(indirect)
6.9	13	19	71	18k	3. sqlite3
10	18	24	46	13k	4. upsert files(dirty)
339	350	667	1320	0.4k	5. upsret files(fdatasync)

连接数：128
线程：128
持续时间：60 秒

1。创建文件（直接）

wrk -> get 请求
get 请求 -> actix web 服务器
创建空文件

2.创建文件（间接）

wrk -> get 请求
get 请求 -> net/http 服务器
data(4k) -> unix 数据报套接字
unix 数据报套接字 -> 创建空文件

3. sqlite3

wrk -> get 请求
get 请求 -> net/http 服务器
data(4k) -> unix 数据报套接字
unix 数据报套接字 -> 通道（buffer=128）
channel -> sqlite3（批量更新插入，每 100 毫秒）

4。更新插入文件（脏）

wrk -> get 请求
get 请求 -> net/http 服务器
data(4k) -> unix 数据报套接字
unix 数据报套接字 -> ext4（无 fdatasync）

5。 upsret 文件（fdatasync）

wrk -> get 请求
get 请求 -> net/http 服务器
data(4k) -> unix 数据报套接字
unix 数据报套接字 -> ext4（临时文件）
fdatasync
重命名

本地电脑信息

存储

猫/etc/fstab

label=cloudimg-rootfs   /        ext4   defaults        0 1

cpu信息

fgrep '型号名称' /proc/cpuinfo|cat -n

1  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
     2  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
     3  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
     4  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
     5  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
     6  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
     7  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
     8  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
     9  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
    10  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
    11  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz
    12  model name      : intel(r) core(tm) i7-9750h cpu @ 2.60ghz

dd

% dd if=/dev/zero of=./zeros.dat bs=4096 count=262144
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 gb, 1.0 gib) copied, 2.67881 s, 401 mb/s

% dd if=/dev/zero of=./zeros.dat bs=4096 count=262144 conv=fdatasync
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 gb, 1.0 gib) copied, 1.02852 s, 1.0 gb/s

% dd if=/dev/zero of=./zeros.dat bs=4096 count=262144 conv=fsync
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 gb, 1.0 gib) copied, 0.875749 s, 1.2 gb/s

好了，本文到此结束，带大家了解了《最大程度提升在受限 NVMe AWS 磁盘上大小为 4-20kb 的文件更新效率（低带宽、低延迟）》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！

版本声明

本文转载于：stackoverflow 如有侵犯，请联系study_golang@163.com删除