Reduce memory usage of Docker containers in development

[humphd]

$ docker stats --no-stream
CONTAINER ID   NAME                   CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
c6d663dfa922   supabase-storage       2.56%     177MiB / 9.718GiB     1.78%     8.65kB / 13.4kB   1.54MB / 0B       13
d1891a42fdb2   supabase-meta          0.00%     41.05MiB / 9.718GiB   0.41%     2.04kB / 0B       48.9MB / 4.1kB    18
ba15bb8b5c9f   supabase-auth          0.00%     6.441MiB / 9.718GiB   0.06%     12.4kB / 15.9kB   246kB / 0B        9
7a4516e3ae5b   supabase-realtime      1.41%     99.82MiB / 9.718GiB   1.00%     1.08MB / 3.17MB   16.7MB / 3.86MB   37
e750ebfd2fd6   supabase-rest          0.66%     14.61MiB / 9.718GiB   0.15%     365kB / 84.8kB    46.7MB / 0B       28
dc66a31ad328   posts                  0.00%     48.1MiB / 9.718GiB    0.48%     11.1kB / 966B     17.3MB / 0B       12
30210b6bbd54   status                 0.00%     31.34MiB / 9.718GiB   0.31%     6.88kB / 820B     10.6MB / 0B       12
be20e4b21988   sso                    0.00%     34.76MiB / 9.718GiB   0.35%     2.04kB / 0B       10.9MB / 0B       8
e74bda0b386f   rss-bridge             0.02%     14.53MiB / 9.718GiB   0.15%     2.04kB / 0B       32.4MB / 12.3kB   7
6b43677ef3ad   image                  0.00%     30.96MiB / 9.718GiB   0.31%     27.1MB / 1MB      143kB / 25.7MB    12
05a6642e99d7   feed-discovery         0.00%     35.86MiB / 9.718GiB   0.36%     2.04kB / 0B       14.2MB / 0B       8
d80ef1298a9b   search                 0.00%     29.02MiB / 9.718GiB   0.29%     2.04kB / 0B       9.02MB / 0B       8
0c98a4af27c1   supabase-kong          0.04%     530.1MiB / 9.718GiB   5.33%     2.04kB / 0B       16.8MB / 90.1kB   9
112134f679ab   nginx                  0.00%     30.06MiB / 9.718GiB   0.30%     2.04kB / 0B       127kB / 12.3kB    10
77ee5f6e94d7   dependency-discovery   0.00%     22.38MiB / 9.718GiB   0.22%     2.04kB / 0B       0B / 0B           8
af3b16dcfdd4   login                  0.01%     43.5MiB / 9.718GiB    0.44%     2.3kB / 0B        24.5MB / 4.1kB    12
5435d5d21070   elasticsearch          1.29%     1.127GiB / 9.718GiB   11.60%    46MB / 518kB      234MB / 182MB     77
ede712e30551   test-web-content       0.00%     9.016MiB / 9.718GiB   0.09%     2.52kB / 0B       4.94MB / 16.4kB   9
889158e50d95   redis                  0.20%     5.793MiB / 9.718GiB   0.06%     4.23kB / 13.9kB   11.1MB / 0B       5
d6a5c910e21d   supabase-studio        0.00%     98.46MiB / 9.718GiB   0.99%     1.83MB / 59.5kB   57.8MB / 16.4kB   23
688f336a597f   traefik                0.00%     16.49MiB / 9.718GiB   0.17%     2.61kB / 0B       67MB / 0B         13
78458b53522e   planet                 0.00%     47.04MiB / 9.718GiB   0.47%     1.83MB / 59kB     8.47MB / 1.76MB   19
bd1323b368a7   supabase-db            14.23%    156.8MiB / 9.718GiB   1.58%     3.27MB / 1.02MB   51.3MB / 70.5MB   24

The biggest offender in our containers are:

• elasticsearch, using ~1G of RAM
• supabase-kong using 530M or RAM
• supabase-storage, supabase-realtime, supabase-db containers each using ~150M

Most other containers are pretty well behaved. We could set some memory limits via Docker to not let things grow so much.

Reducing the heap size for Elasticsearch would be a good start, see https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html#_setting_jvm_heap_size and https://github.com/Seneca-CDOT/telescope/blob/master/docker/docker-compose.yml#L332-L335. We should do something different in development.yml vs. production.yml

[humphd]

This continues to be a big issue for new contributors. I'm not 100% sure what the solution is, beyond making our architecture more simple, or using staging/prod instances for backend services in dev.