Устранение неполадок с памятью и JVM¶
Glarus BI работает на Java Virtual Machine (JVM) и (в зависимости от конфигурации) может использовать файловую систему сервера для хранения части данных. Поэтому проблемы с JVM или файловой системой могут помешать запуску и работе Glarus BI.
Версия Java¶
Glarus BI нужно запускать на Java версии 21 или выше (более старые версии не поддерживаются).
При выборе Java‑версии всегда используйте свежую минорную версию выбранной мажорной ветки. Например, если выбирать между Java 21.0.1 и Java 21.0.4, используйте самую новую (в этом примере — 21.0.4).
Мы рекомендуем устанавливать на сервер только одну версию Java: наличие нескольких версий Java на одном сервере может приводить к проблемам с приложением. Если вам нужно запускать несколько приложений, каждому из которых требуется своя Java‑версия, рассмотрите использование контейнеров. В противном случае убедитесь, что вы можете запускать все приложения на одной версии Java.
Потребление памяти Glarus BI¶
Glarus BI поставляется как JAR‑файл и запускается на JVM.
Важно различать потребление памяти самим приложением Glarus BI и потребление памяти JVM.
JVM будет постоянно занимать некоторый объём памяти. По умолчанию JVM использует примерно четверть оперативной памяти машины (хотя вы можете изменить, сколько ОЗУ использовать JVM).
JVM‑приложения (включая Glarus BI) будут потреблять и освобождать память, выделенную JVM. Но сама JVM не возвращает неиспользуемую память обратно системе, поэтому потребление памяти JVM со стороны ОС выглядит как постоянное.
Например, на машине с ОЗУ 8 Гбайт по умолчанию JVM будет использовать около 2 Гбайт. Glarus BI будет использовать часть или все эти 2 Гбайта JVM‑памяти — в зависимости от нагрузки. Но с точки зрения ОС JVM будет постоянно занимать выделенные 2 Гбайта, даже когда Glarus BI использует лишь часть этой памяти.
Диагностика проблем с памятью¶
Учитывая то, как JVM работает с памятью, если у вас есть проблемы с производительностью Glarus BI, которые (как вам кажется) не связаны с хранилищем данных, обратите внимание на «красные флаги» ниже.
Glarus BI аварийно завершает работу из-за OutOfMemoryError: Java heap space¶
Обычно JVM может определить, сколько ОЗУ доступно в системе, и автоматически установить разумную верхнюю границу для heap‑памяти. Однако в некоторых средах (например, на определённых shared‑хостингах) это может работать не так, как ожидается. Частый симптом — ошибка вида:
Если вы видите эту ошибку «out of memory» (OOM), вам нужно выделить JVM больше памяти.
В графике потребления памяти видно «пилообразное» поведение¶
Вы можете использовать инструменты мониторинга, чтобы посмотреть, как Glarus BI использует память со временем. См.:
Конкретная метрика Prometheus: jvm_memory_bytes_used{area="heap"}
На что обратить внимание: «пилообразный» паттерн. Glarus BI быстро потребляет память, это запускает сборку мусора (garbage collection), которая освобождает память, после чего Glarus BI снова быстро её потребляет. Такой up‑down‑up‑down-паттерн — признак частых циклов GC. Сборка мусора «съедает» время ЦП и может замедлять приложение.
Если вы видите этот паттерн, вам нужно увеличить объём памяти, выделенный JVM.
Выделение большего объёма памяти JVM¶
Вы можете задать опцию JVM, чтобы увеличить heap‑память. Например, вы можете использовать флаг -X:
Увеличивайте выделение памяти до тех пор, пока Glarus BI не начнёт работать стабильно, но следите, чтобы значение было меньше общего объёма ОЗУ на машине: Glarus BI — не единственный процесс. Обычно достаточно оставить 1–2 Гбайта ОЗУ для остальных процессов. Например, можно поставить -Xmx равным 1g на машине с 2 Гбайт ОЗУ, 2g — на машине с 4 Гбайт ОЗУ и т.д. Возможно, вам придётся поэкспериментировать с настройками, чтобы найти баланс (а иногда — обновить сервер до машины с большим объёмом памяти).
Также можно использовать переменную окружения JAVA_OPTS, чтобы задавать аргументы JVM, вместо того чтобы передавать их напрямую в java. Это особенно полезно при запуске Docker‑образа:
Диагностика OutOfMemoryError через heap dump¶
Если экземпляр Glarus BI запускается и работает достаточно долго, прежде чем «упасть» по памяти, возможно, OutOfMemoryError вызывает конкретное событие (например, большой запрос). Один из способов понять, где расходуется память, — включить heap dump при возникновении OutOfMemoryError. Для этого нужно добавить два флага к запуску java:
Флаг -XX:HeapDumpPath задаёт каталог для дампа (по умолчанию — текущий). При OutOfMemoryError JVM сохранит hprof‑файл. Эти файлы могут быть большими (примерно размера -Xmx), поэтому убедитесь, что на диске достаточно места. hprof‑файлы можно анализировать с помощью разных инструментов, например jhat (входит в JDK) или Eclipse Memory Analyzer Tool.
Glarus BI не получает доступ к файлам или каталогам на чтение или запись (IOError)¶
Если вы видите ошибку, связанную с правами доступа к файлам (например, Glarus BI не может прочитать базу данных SQLite или пользовательский файл карты GeoJSON), см. раздел «Glarus BI не может записывать или читать в/из файла или каталога» в руководстве по устранению неполадок Docker.
ВНИМАНИЕ: sun.reflect.Reflection.getCallerClass не поддерживается¶
Если вы видите это сообщение, просто игнорируйте его: ваш экземпляр Glarus BI работает нормально и производительность не страдает.