Devicemapper Performance: Best Practices and Considerations

**Writing and then deleting a file**: If a container writes to a file and later deletes the file, all of those operations happen in the container's writable layer. In that case, if you are using `direct-lvm`, the blocks are freed. If you use `loop-lvm`, the blocks may not be freed. This is another reason not to use `loop-lvm` in production. ## Device Mapper and Docker performance - **`allocate-on demand` performance impact**: The `devicemapper` storage driver uses an `allocate-on-demand` operation to allocate new blocks from the thin pool into a container's writable layer. Each block is 64KB, so this is the minimum amount of space that is used for a write. - **Copy-on-write performance impact**: The first time a container modifies a specific block, that block is written to the container's writable layer. Because these writes happen at the level of the block rather than the file, performance impact is minimized. However, writing a large number of blocks can still negatively impact performance, and the `devicemapper` storage driver may actually perform worse than other storage drivers in this scenario. For write-heavy workloads, you should use data volumes, which bypass the storage driver completely. ### Performance best practices Keep these things in mind to maximize performance when using the `devicemapper` storage driver. - **Use `direct-lvm`**: The `loop-lvm` mode is not performant and should never be used in production. - **Use fast storage**: Solid-state drives (SSDs) provide faster reads and writes than spinning disks. - **Memory usage**: the `devicemapper` uses more memory than some other storage drivers. Each launched container loads one or more copies of its files into memory, depending on how many blocks of the same file are being modified at the same time. Due to the memory pressure, the `devicemapper` storage driver may not be the right choice for certain workloads in high-density use cases. - **Use volumes for write-heavy workloads**: Volumes provide the best and most predictable performance for write-heavy workloads. This is because they bypass the storage driver and do not incur any of the potential overheads introduced by thin provisioning and copy-on-write. Volumes have other benefits, such as allowing you to share data among containers and persisting even when no running container is using them. > [!NOTE] > > When using `devicemapper` and the `json-file` log driver, the log files generated by a container are still stored in Docker's dataroot directory, by default `/var/lib/docker`. If your containers generate lots of log messages, this may lead to increased disk usage or the inability to manage your system due to a full disk. You can configure a [log driver](/manuals/engine/logging/configure.md) to store your container logs externally. ## Related Information - [Volumes](../volumes.md) - [Understand images, containers, and storage drivers](./_index.md) - [Select a storage driver](select-storage-driver.md)

This section focuses on the performance implications of using the `devicemapper` storage driver in Docker, particularly regarding file operations. It covers the `allocate-on-demand` and `copy-on-write` mechanisms, and how the driver handles writing and deleting files. It recommends using `direct-lvm` over `loop-lvm`, utilizing fast storage like SSDs, and considering memory usage. It also suggests using volumes for write-heavy workloads to bypass the storage driver's overhead, and mentions considerations for the `json-file` logging driver.