Skip to content

Resource Limits

Refer to Docker Compose File Requirements for information on how to implement these limits and examples.

It is possible to run multiple applications on a HCC2 in addition to the core services, but the device does have finite resources to share. As the permutations of different configurations is impractical to validate, it isn't possible to impose absolute limits on an application to guarantee it will safely co-exist with other resources that can & will change as system upgrades are made. This is especially true with various third-party applications installed. To mitigate this risk, and to have the best starting point for maintaining system availability, the default resource limits one should apply are:

  • Memory : 256MB per container application. Use docker-compose directive mem_limit: 256m
  • CPU : 0.5 cores. Use the docker-compose directive cpus: 0.5
  • Communications poll rate: Typically no faster than 1 second
  • Number of apps: It depends on the application complexity and available resources in the HCC2
  • Temporary file system, tmpfs. Use size=500K (guideline value)
  • Writing to flash: Keep to the absolute minimum required for functionality. Benchmark to be ensure under 10KBs per minute.
  • IP Port access: Avoid clashes with reserved IPs. Do not bind to ports unnecessarily. Consider how frequently connections are being opened and closed (some remote devices may not tolerate frequent opening and closing of connections). The HCC2 does contain a firewall and it may restrict IP port access.

Example docker-compose:

deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 256M

Required

  • Define and enforce reasonable resource limits for the container via compose file settings
  • Unless absolutely necessary, avoid any CPU limit greater than 0.5 and memory (RAM) limit greater than 256M
  • Avoid reservations. These should be used for stable, low demand, critical services.
  • Set read_only: true unless impossible due to language or base container constraints. Refer to Rules and Best Practices
    • This implies using Docker volumes for all non-volatile data
    • Encourage use of tmpfs for any temporary files (good practice, especially for flash wear)
  • Make the container image size as small as practical by meeting all the following:
    • Uncompressed size of layers that are not shared total 128MB or less (AKA Unique size).
    • Size of shared layers does not exceed 300MB
    • Use one of the base containers listed in Base Images to limit the # of shared base images and increase layer reuse

Strongly Suggested

  • In regression/stress test environments, track worst case and typical CPU and memory use
    • Use this information to guide the limits required above. For internally developed applications, these limits are already in place and checked/tracked in our production hardware in the loop test.
  • Follow guidance here:
  • Have separate slim and debug builds (easier to meet the above and still have a test image)
  • If using a container not listed above, use:
    • a distroless base container.
    • If distroless is unavailable for your development language or you must install packages into the container, debian-slim
    • Alpine