使用 Fluid 对接 OSS 存储及性能测试
· ☕ 4 分钟
1. Jindo 直接加速 OSS 配置环境变量 1 2 3 4 export ENDPOINT=oss-cn-beijing-internal.aliyuncs.com export BUCKET= export AK= export SK= 创建凭证 1 2 3 4 5 6 7 8 9 10 kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: myosssecret type: Opaque stringData: fs.oss.accessKeyId: ${AK} fs.oss.accessKeySecret: ${SK} 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: ${ENDPOINT} encryptOptions: - name: fs.oss.accessKeyId valueFrom: secretKeyRef: name: myosssecret key: fs.oss.accessKeyId - name: fs.oss.accessKeySecret valueFrom:

如何预热 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 如果没有提前创建好目录,并

模型研发周期中的数据存储
· ☕ 3 分钟
1. 基于对象存储的数据交付 如上图,在模型研发过程中,主要涉及三个子平台,分别是: 数据平台 数据平台主要负责数据相关的管理,比如: 数据接入、数据处理,最终生成训练所需的数据。 数据平台将原始数据存储到对象存储中,在处理时,从对象存储中获取数据,进行