feat: cloud disk io & ai

ryan4yin · Nov 23, 2023 · 19127b4 · 19127b4
1 parent c969d05
commit 19127b4
Show file tree

Hide file tree

Showing 2 changed files with 33 additions and 6 deletions.
diff --git a/AI & Data-Science/Nvidia CUDA.md b/AI & Data-Science/Nvidia CUDA.md
@@ -20,3 +20,26 @@
 2. [Torch-TensorRT -  Compile Stable Diffusion and Inference](https://pytorch.org/TensorRT/tutorials/_rendered_examples/dynamo/torch_compile_stable_diffusion.html)
 3. [Compile a Torch Model(.pt) into Torch-TensorRT(xxx_trt.ts) via CLI](https://pytorch.org/TensorRT/cli/torchtrtc.html)
 
+## Nvidia GPU 架构、CUDA 版本、Nvidia 驱动版本、PyTorch 版本之间的兼容性
+
+> https://docs.nvidia.com/deeplearning/frameworks/support-matrix/index.html
+
+上述这几个版本 / 架构之间存在一定的兼容性关系，如果不匹配，可能会导致程序无法充分利用上 GPU，导致运行效率低下，甚至直接无法运行。
+
+对于容器方案，建议参考 [Nvidia Frameworks Support Matrix](https://docs.nvidia.com/deeplearning/frameworks/support-matrix/index.html) 列出的搭配方案，以 Nvidia 官方提供的 Docker 镜像为基础镜像构建符合自己需求的应用镜像。
+
+如果容器运行在云服务上，建议同时参考云服务商官方的文档，比如：
+
+1. GCP 的 GPU 驱动相关文档: https://cloud.google.com/compute/docs/gpus/install-drivers-gpu#no-secure-boot
+    1. 比如说其中就建议 Nvidia L4 使用 525.60.13+ 版本的驱动，以及 CUDA Toolkit 12.1+ 的 CUDA. 对应的支持 CUDA 12.1 的 PyTorch 版本是 2.1.0.
+
+## Nvidia 相关容器镜像
+
+> https://catalog.ngc.nvidia.com/containers
+
+1. cuda: https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda/tags
+    1. such as `nvcr.io/nvidia/cuda:12.1.0-cudnn8-devel-ubi8`
+2. tensorrt: https://catalog.ngc.nvidia.com/orgs/nvidia/containers/tensorrt
+3. pytorch: https://catalog.ngc.nvidia.com/orgs/nvidia/containers/pytorch
+    1. such as `nvcr.io/nvidia/pytorch:23.10-py3`
+
diff --git a/linux/Linux IO 性能问题与解决思路.md b/linux/Linux IO 性能问题与解决思路.md
@@ -53,8 +53,14 @@ SSD 的性能受两方面的影响：
     5. **IO Pattern**：IO Pattern影响了SSD内部的GC数据布局，间接影响了GC过程中的数据搬移量，决定了后端流量。当IO Pattern为全顺序时，这种Pattern对SSD内部GC是最为友好的，写放大接近于1，因此具有最好的性能；当IO Pattern为小块随机时，会产生较多的GC搬移数据量，因此性能大为下降。在实际应用中，需要通过本地文件系统最优化IO Pattern，获取最佳性能。
     6. FTL算法 / Bit error 处理机制，这几个不展开了。
     7. 系统层面的系统优化：比如内存中的 Page Cache、文件系统、SSD 驱动程序的实现方式等等。
+3. 云服务场景下的特殊因素：
+    1. AWS 的 GP3 或 GCP 的 pd-ssd 都是云磁盘，底层架构的差异会导致一些意料之外的性能差异。
+        1. 比如说 AWS 上从 EBS 快照（或 AMI 镜像）新建的 EBS 卷在第一次被读取时是「冷数据」，这些数据的读速度非常慢（可能低于 10M/s），不论如何调整 IOPS 与吞吐量都无济于事。而一旦这些数据被读取过一次（[初始化 Amazon EBS 卷](https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-initialize.html)），就会被缓存到离 EC2 最近的后端存储系统中，后续再读取这些数据就能达到预设的 IOPS / 吞吐量了。
 
-我们在前面看到的两个案例中，都是因为 IO 利用率一直 100%，但 IOPS 和读写速率都很低。GP3 是 AWS 目前的主流 EBS 磁盘类型，在软件层面肯定能做一些优化。
+我们在前面看到的两个案例中，都是因为 IO 利用率一直 100%，但 IOPS 和读写速率、CPU 利用率等都很低。
+这说明 AWS 的 GP3 云磁盘卡在了其他因素上，与 GP3 磁盘本身的 IOPS / 吞吐量以及 CPU 性能等无关。
+
+进一步排查实际上就能确认这是因为 AWS EBS 快照未预热，读「冷数据」导致的。
 
 
 #### 3.2. 排查
@@ -72,11 +78,9 @@ SSD 的性能受两方面的影响：
 2. 对于顺序读较多的场景，调整 /sys/block/sdb/queue/read_ahead_kb 的值，增大磁盘的预读数据。
 3. 对应用程序进行磁盘级别的隔离，比如把 kafka 的数据目录和日志目录这些 IO 压力较高的目录分别放到不同的磁盘上。
 4. 应用程序层面的优化，比如 kafka 自身就通过追加写的方式来减少磁盘随机写的次数，从而提高性能。kafka 本身也有一些 IO 行为相关的参数可调整。
-5. 对于云主机，可以考虑使用本地存储卷（Local SSD / Local NVMe Storage），它的性能远高于 AWS EBS / Aliyun ESSD 等云磁盘，但其中的数据在多种情况下并不持久化，需要自己做好数据备份与容灾考量。
-
-此外，云服务器还存在各种其他由其底层设计带来的性能问题。
-比如说在 AWS 上使用刚刚新建的 AMI 镜像创建 EC2 虚拟机，尝试去读一个 AMI 中的文件，你可能会发现性能差得离谱（我这边的实测是顺序读速度低于 10M/s），无论你如何调高 EBS 卷的 IOPS / 吞吐量，都无济于事。
-这很可能是 AWS 的底层设计问题，新建的 AMI 镜像在第一次被读取时是「冷数据」，EC2 机器去访问这些数据时会非常慢，而一旦这些数据被读取过一次，就会被缓存到离 EC2 最近的后端存储系统中，后续再去读取这些数据时就正常了。
+5. 对于云主机可以考虑如下手段：
+    1. 使用本地存储卷（Local SSD / Local NVMe Storage），它的性能远高于 AWS EBS / GCP pd-ssd / Aliyun ESSD 等云磁盘，但其中的数据在多种情况下并不持久化，需要自己做好数据备份与容灾考量。
+    2. 不要将数据预置在 AWS 的 EBS 卷快照中，而是在启动时再从 S3 将数据下载到本地，这样就能避免 EBS 卷冷数据读取速度慢的问题。
 
 
 ## 参考