Overview

NVMe Disk Pods are ALYPOD compute instances built on high-speed NVMe SSDs. They suit I/O-heavy workloads where disk latency, not CPU, is the bottleneck — databases, caches, log processing and busy web applications. This article explains the storage model and how to get the most from it.

How the storage works

• Local NVMe: your data lives on NVMe SSDs attached to the host for the lowest possible latency and high random IOPS.
• Dedicated size: the disk size in your plan belongs to your Pod only.
• Ephemeral caution: local disks are tied to the host. For critical data, take regular snapshots and keep off-box backups on a Storage Box or S3.

Ideal workloads

• MySQL/PostgreSQL/MariaDB and Redis with high transaction rates.
• Elasticsearch, ClickHouse and other analytics stores.
• Container registries, caches and build caches.
• WordPress or e-commerce sites with large databases.

Checking disk performance

1. Install a benchmark tool on the Pod:

bash apt update && apt install -y fio

1. Run a quick random-read test (adjust --filename to a real data path):

bash fio --name=randread --ioengine=libaio --rw=randread --bs=4k \ --size=1G --runtime=30 --filename=/var/tmp/fio.test

1. Compare the IOPS figure to your expectations; the console Graphs tab shows ongoing disk activity.

Best practices

• Keep the filesystem below ~85% full; full disks lose performance and can corrupt.
• Use noatime in /etc/fstab for busy data volumes.
• Match MySQL's innodb_flush_method to your stack and size the buffer pool sanely.

Troubleshooting

• Problem: high disk wait (%iowait in top). Solution: look for swap activity, then add RAM or move cold data to a Storage Box.
• Problem: disk filling up unexpectedly. Solution: du -xh --max-depth=1 / | sort -h to find the culprit, then prune logs or expand the Pod.

Related articles

• [How to deploy a CPU Pod]
• [Creating and restoring snapshots]
• [Dedicated CPU Pods explained]