mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 19:01:54 +00:00
kevinveenbirkenbachandClaude Opus 5.5
3fb237a143
The heaps of the central Elasticsearch, Zammad's Elasticsearch and Magento's OpenSearch follow their container through the lookup, so far at half of the limit. That doubled them to 2048, 1024 and 1024 MiB. Xms equals Xmx, so each container claims that heap from its start, and the central one locks it in memory. A quarter of the limit gives 1024, 512 and 512 MiB, the sizes these engines ran with before. The heap still follows the limit. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
18 lines
1.0 KiB
YAML
18 lines
1.0 KiB
YAML
---
|
|
application_id: svc-db-elasticsearch
|
|
entity_name: "{{ application_id | get_entity_name }}"
|
|
|
|
database_type: "{{ entity_name }}"
|
|
|
|
ELASTICSEARCH_CONTAINER: "{{ lookup('config', application_id, 'services.' ~ entity_name ~ '.name') }}"
|
|
ELASTICSEARCH_CONTAINER_ADDRESS: "{{ lookup('container_address', application_id, ELASTICSEARCH_CONTAINER) }}"
|
|
ELASTICSEARCH_PASSWORD: "{{ lookup('config', application_id, 'secrets.credentials.ELASTIC_PASSWORD') }}"
|
|
ELASTICSEARCH_EXPOSE_LOCAL: true
|
|
ELASTICSEARCH_LOCAL_HOST: "127.0.0.1"
|
|
ELASTICSEARCH_INTERNAL_PORT: "{{ lookup('config', application_id, 'services.elasticsearch.ports.internal.elasticsearch') }}"
|
|
ELASTICSEARCH_HEAP_MB: "{{ lookup('service_memory_mb', application_id, entity_name, 0.25) }}"
|
|
ELASTICSEARCH_RETRIES: 5
|
|
ELASTICSEARCH_DELAY: 2
|
|
ELASTICSEARCH_API_BASE: "http://{{ ELASTICSEARCH_LOCAL_HOST }}:{{ ELASTICSEARCH_INTERNAL_PORT }}"
|
|
ELASTICSEARCH_EXEC_SHELL: "container exec -e ELASTIC_PW={{ ELASTICSEARCH_PASSWORD | quote }} {{ ELASTICSEARCH_CONTAINER_ADDRESS }} sh -lc"
|