File access in mounted volumes extremely slow, CPU bound

Docker Desktop for Mac
290

I have the same issue running a few containers to run a development version of WordPress. The idea is that WordPress is installed in the container and theme files are kept in sync between macOS’ file system and the container.

However, accessing the site is extremely slow. I’ve tried to use :cached and :delegated at some point but made no difference. Does anyone know if there are any new strategies to overcome this issue?

Here’s my docker-compose.yml:

services:
  wordpress:
    image: wordpress:latest
    container_name: app-wordpress
    environment:
      WORDPRESS_DB_HOST: app-mysql
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_PASSWORD: password
      WORDPRESS_TABLE_PREFIX: "wp_"
      WORDPRESS_DEBUG: 1
    ports:
      - "8080:80"
    depends_on:
      - "database"
    volumes:
      # Allows changes made to project directory to be accessed by the container via a bind mount.
      - ./wp-content/themes/hello-elementor:/var/www/html/wp-content/themes/hello-elementor
      - ./wp-content/themes/hello-theme-child:/var/www/html/wp-content/themes/hello-theme-child
      # Uploads and plugins used by the site.
      - ./docker/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
      - ./docker/volumes/wordpress/wp-content/ai1wm-backups:/var/www/html/wp-content/ai1wm-backups
      - ./docker/volumes/wordpress/wp-content/plugins:/var/www/html/wp-content/plugins/
      - /var/www/html/wp-content/uploads/
      
      
  database:
    image: mysql:latest
    container_name: app-mysql
    # PHP mysqli connector does not support caching_sha2_password plugin so using mysql_native_password instead.
    command: "--default-authentication-plugin=mysql_native_password"
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: password
      MYSQL_ROOT_PASSWORD: password
    # This allows for the database to be consulted via a software such as SQL Workbench or TablePlus
    ports:
      - 3307:3306
    volumes:
      - ./docker/volumes/mysql:/var/lib/mysql
  composer:
    build:
      # Setting a context and dockerfile paths allows for Dockerfiles to be stored away in a sub-directory.
      context: . # Context of build, this is where the project files are stored.
      dockerfile: ./docker/php.dockerfile # The path to Dockerfile and name of the dockerfile to be built
    # Setting an image name avoids the same image being built multiple times.
    image: rotorotor/composer-tooling:latest
    depends_on:
      - "wordpress"
    volumes:
      # Allows changes made to project directory to be accessed by the container via a bind mount.
      - ${PWD}/wp-content/themes/hello-theme-child:/app
      - ${PWD}/wp-content/themes/hello-theme-child/vendor:/app/vendor/
    tty: true
  # Used to compile styles and scripts.
  node:
    # Building a custom image described in a docker file.
    build:
      # Setting a context and dockerfile paths allows for Dockerfiles to be stored away in a sub-directory.
      context: . # Context of build, this is where the project files are stored.
      dockerfile: ./docker/node.dockerfile # The path to Dockerfile and name of the dockerfile to be built
    # Setting an image name avoids the same image being built multiple times.
    image: rotorotor/node-tooling:latest
    # Specified the name of the container, commented out to avoid name conflicts when running multiple instances of the image.
    # container_name: protonmail_themes
    ports:
      - 3000:3000
      - 3001:3001
    depends_on:
      - "wordpress"
    restart: always
    volumes:
      # Allows changes made to project directory to be accessed by the container via a bind mount.
      - ${PWD}/wp-content/themes/hello-theme-child:/var/www/html/wp-content/themes/app
      # Adds a volume to store node dependencies.
      - /var/www/html/wp-content/themes/app/node_modules
291

Hey, guys. I had the same issue on Linux. Or maybe it’s not the same problem, but it could probably help someone else in the universe.

The file access on volumes inside containers was very very slow and the file acess was normal in other folders. After days of war I found that the volume had auditing enabled… so I turned it off.

I checked with auditctl -l and I noticed the line -w /var/lib/docker -k docker. I than removed the line with auditctl -w /var/lib/docker -k docker, restarted the container and the sun shone again. Dont forget to verify the audity rules (/etc/audit/rules.d/audit.rules).