博文
MemoryFS 存储系统的一些构想
· ☕ 3 分钟
1. 使用内存作为存储介质 如上图是存储金字塔,展示了存储介质价格与速度的关系。 目前,企业之所以广泛采用磁带和磁盘作为存储介质,主要是因为它们的价格优势。市场价格受市场供需影响,即便是价格较高的存储介质,如果生产成本低廉,具有足够大的市场,生产过

使用 Fluid 对接 OSS 存储及性能测试
· ☕ 4 分钟
1. Jindo 直接加速 OSS 创建凭证 1 2 3 4 5 6 7 8 9 10 kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque stringData: aws.accessKeyId: xxx aws.secretKey: xxx EOF 创建 Dataset 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 kubectl apply -f - <<EOF apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: myoss-jindo spec: mounts: - mountPoint: oss://{BUCKET}/test2/ options: fs.oss.endpoint: oss-cn-beijing-internal.aliyuncs.com encryptOptions: - name: fs.oss.accessKeyId valueFrom: secretKeyRef: name: mysecret key: fs.oss.accessKeyId - name: fs.oss.accessKeySecret valueFrom: secretKeyRef: name: mysecret key: fs.oss.accessKeySecret accessModes: - ReadWriteMany EOF 创建 JindoRuntime 1 2 3 4 5 6

如何预热 Juicefs 数据
· ☕ 1 分钟
1. 关于 JuiceFS 的缓存 在主机上,预热的缓存是直接放在主机上的。 在集群中,分为两级缓存: Worker,提供集群级别共享的缓存 Fuse,提供仅当前节点级别的缓存 2. 使用 JuiceFS 客户端预热数据 指定目录 1 juicefs warmup /mnt/jfs/dataset-1 批量指定目录 1 juicefs warmup -f warm.txt 其中 warm.txt 为预热目录列表,每行一个目

高频 IO 的 POD 并不适合设置 Limit
· ☕ 2 分钟
1. 现象 基于 Kubernetes 的 Elasticsearch 频繁重启,导致服务几乎不可用。 在导入数据过程中,Pod 的内存使用持续增长 Pod 内存使用接近 Limit 之后,继续导入就会触发 Pod 异常退出,错误日志 ERROR: Elasticsearch exited unexpectedly Pod 内存使用率并不会下降,而是维持在 Limit 附近,不久又异常退出 Elasticsearch Pod 内存限制在 64GB,而 JVM 内

部署基于内存存储的 Elasticsearch - 一亿+条数据,全文检索 100ms 响应
· ☕ 6 分钟
1. 在主机上挂载内存存储目录 创建目录用于挂载 1 mkdir /mnt/memory_storage 挂载 tmpfs 文件系统 1 mount -t tmpfs -o size=800G tmpfs /mnt/memory_storage 存储空间会按需使用,也就是使用 100G 存储时才会占用 100G 内存。主机节点上有 2T 内存,这里分配 800G 内存用于存储 Elasticsearch 数据。 提前创建好目录 1 2 3 mkdir /mnt/memory_storage/elasticsearch-data-es-jfs-prod-es-default-0 mkdir /mnt/memory_storage/elasticsearch-data-es-jfs-prod-es-default-1 mkdir /mnt/memory_storage/elasticsearch-data-es-jfs-prod-es-default-2 如果没有提前创建好目录,并