Numéro d’ID de bogue |
BUG-000105758 |
Envoi | June 10, 2017 |
Dernière modification | June 5, 2024 |
S’applique à | ArcGIS GeoEvent Server |
Version trouvée | 10.4.1 |
Système d’exploitation | Windows OS |
Version du système d’exploitation | 2012 R2 |
Statut | Known Limit
Après examen par l’équipe de développement, il a été déterminé que ce problème est lié à une limitation connue du logiciel sur laquelle Esri n’a aucun contrôle. Pour d’autres explications, reportez-vous à la section Informations supplémentaires correspondant au problème.
|
Informations supplémentaires
Operations which pull data records, like complete geometries, into memory are intensive. Java's memory management anticipates this sort of memory usage and its default is to not scale down a JVM immediately after garbage collection simply because a block of memory is not immediately needed. Dynamic scaling requires instantiating a completely new JVM instance and copying the running state of the current JVM into the new instantiation before destroying the old JVM. This activity is itself resource intensive and represents a potential disruption to real-time processing activities.
Future releases of Java are anticipated to offer additional strategies for memory allocation and management, but it is unlikely ArcGIS GeoEvent Server will be refactored to leverage an aggressive Java memory allocation / deallocation strategy. Best practice recommendation are to use Java's -Xms / -Xmx settings to establish a fixed memory allocation and disable dynamic JVM scaling.
Esri recommends system architects follow principles of resource isolation and deploy ArcGIS Enterprise components such that system resources can be dedicated to specific functions (e.g. responding to map/feature service requests, geoprocessing, maintaining large volumes of feature record sets 'hot' in memory for the spatiotemporal big data store, adapting and processing data at velocity in real-time, etc.)
Étapes pour reproduire
ID de bogue: BUG-000105758
Logiciel: