[
https://issues.jboss.org/browse/TEIID-5007?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-5007:
---------------------------------------
I'm not finding good guidelines around ephemeral disk usage. You can put limits based
upon image and node usage, but there doesn't seem to be an a priori way of
automatically determining a limit for a single container -
https://docs.openshift.com/container-platform/3.6/admin_guide/out_of_reso...
As is things like the logs, temp files (buffer manager, deployment related), etc. just go
to their default location. For the server log the console is probably sufficient.
Concerns such locations for heap and other dumps should they be needed should be looked at
(Burr has material on this and I'm not sure what we're planning on baking into the
base java image).
Options:
- fully read-only image and manage all disk usage through volumes (seems unnecessary as we
don't need persistence)
- add more parameters, in particular buffermanager disk consumption to the templates (or
even useDisk=false)
- something else?
Changes to reduce Teiid in the cloud footprint
----------------------------------------------
Key: TEIID-5007
URL:
https://issues.jboss.org/browse/TEIID-5007
Project: Teiid
Issue Type: Quality Risk
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 10.1
A Teiid instance even as swarm or springboot needs additional considerations to minimize
the runtime footprint. This includes:
* container aware auto-sizing. Detection of the number of cpus and available memory need
refined - there are experimental settings being considered for containerized vms to better
report these values and there is logic in WildFly and other projects that attempts better
auto-detection. We also need to utilize the memory buffer space more and probably as
off-heap space (and ideally direct operations on the serialized data)
* Subsystems required include JTA, webserver, security, which could be satisfied by
slimmer alternative versions - especially if we make new assumptions, such as not
utilizing xa transactions.
* Engine dependencies could be application specific - removing xml/xsl support, geometry
support, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)