Service

Service — системный модуль, собирающий административную поверхность сервера: действия обслуживания и пересчёта базы данных, управление виртуальной машиной и памятью, запланированный перезапуск сервера, общесистемные настройки, пользовательские признаки диагностики и журналирования, пользовательские настройки клиентского интерфейса, масштабирование базы данных и API серверных настроек, выгружаемое клиентам. Подключается через REQUIRE Service (сам делает REQUIRE System, Security, SystemEvents; собственные объявления лежат в NAMESPACE Service).

Большинство действий объявлены через оператор INTERNAL над Java-классом реализации, то есть открывают серверные операции, у которых нет тела на чистом .lsf. Модуль также публикует формы maintenance, settings, scaling вместе с соответствующими пунктами навигатора в системной папке.

Обслуживание базы данных

Эти однопоточные действия выполняют обслуживание и пересчёт базы данных напрямую. Они вынесены на форму maintenance.

Действие	Что делает
serviceDBAction[]	выполняет полный цикл обслуживания базы данных
checkClassesAction[]	проверяет согласованность хранимых классов объектов
checkMaterializationsAction[]	сверяет значения материализованных свойств с их определениями
checkIndicesAction[]	проверяет наличие ожидаемых индексов в базе
checkTablesAction[]	проверяет таблицы базы данных
recalculateClassesAction[]	пересчитывает хранимые классы объектов
recalculateAction[]	пересчитывает хранимые (материализованные) значения свойств
recalculateFollowsAction[]	заново применяет правила следствий (RESOLVE) для приведения данных к согласованному виду
recalculateStatsAction[]	пересчитывает статистику по таблицам и колонкам
overCalculateStatsAction[]	пересчитывает расширенную статистику; maxQuantityOverCalculate[] ограничивает число выбираемых различных значений
updateStats[]	обновляет статистику, используемую оптимизатором запросов
analyzeDBAction[]	выполняет ANALYZE базы данных
vacuumDBAction[]	выполняет VACUUM базы данных
packAction[]	физически удаляет помеченные на удаление строки

analyzeDBAction[] стоит вызвать вручную после первого запуска или крупной синхронизации схемы: пока PostgreSQL не собрал собственную статистику планировщика, он строит неоптимальные планы и формы работают заметно медленнее. Это статистика самой СУБД, а не внутренняя статистика платформы, питающая оптимизатор запросов (recalculateStatsAction[] / updateStats[], строка Recalculating stats... в логе старта).

Многопоточные варианты

Более тяжёлые действия обслуживания и пересчёта есть и в многопоточном семействе, вынесенном в блок multiThread формы maintenance: serviceDBMultiThreadAction, checkClassesMultiThreadAction, checkMaterializationsMultiThreadAction, recalculateClassesMultiThreadAction, recalculateMultiThreadAction, recalculateFollowsMultiThreadAction, recalculateStatsMultiThreadAction, overCalculateStatsMultiThreadAction. Каждое делает ту же работу, что и его однопоточная пара, но распределяет работу по таблицам между несколькими рабочими потоками.

У каждого действия семейства есть три формы с одним именем:

Сигнатура	Как выбирает число потоков и таймаут
…MultiThreadAction[INTEGER, INTEGER]	базовая форма: первый аргумент — число потоков (NULL — выбор остаётся за платформой), второй — таймаут на свойство в секундах (NULL — без таймаута)
…MultiThreadAction[INTEGER]	обёртка только с таймаутом: вызывает базовую форму с NULL-числом потоков и заданным таймаутом
…MultiThreadAction[]	обёртка только с числом потоков: вызывает базовую форму с threadCountMultiThread[] и без таймаута

threadCountMultiThread[] — локальное свойство, к которому форма maintenance привязывает бесаргументные обёртки, так что число потоков задаётся на форме.

Режимы базы данных

Эти признаки переключают, как идут обслуживание и пересчёт базы. Каждый — хранимое свойство, изменение которого проталкивается в сервер: модуль объявляет действие set… через INTERNAL, действие refresh…, заново применяющее текущее значение, событие WHEN CHANGED, вызывающее обновление при каждом изменении, и повторное применение в onStarted, чтобы значение пережило перезапуск. Метакод @defineMode порождает весь этот набор под один признак.

Свойство	Чем управляет
disableTILMode[]	отключает режим уровня изоляции транзакций (REPEATABLE READ) для операций обслуживания; собран через @defineMode
hostnameServerComputer[]	имя хоста компьютера (Computer), считающегося сервером (через serverComputer); собран через @defineMode
reupdateMode[]	включает режим повторного обновления при пересчёте; разведён собственной парой setReupdateMode[BOOLEAN] / refreshReupdateMode[]
singleTransaction[]	выполняет цикл обслуживания внутри одной транзакции

Виртуальная машина и память

Эти действия осматривают и освобождают ресурсы JVM сервера; вынесены в блок virtualMachine формы maintenance.

Действие / свойство	Что делает
runGarbageCollector[]	принудительно запускает сборку мусора JVM
getVMInfo[]	собирает текущую информацию о виртуальной машине
makeHeapDump[]	пишет дамп кучи JVM
makeProcessDumpAction[]	пишет дамп процесса
dropLRU[]	сбрасывает кэшированные значения по политике вытеснения давно не использованных; вызывает dropLRUCustom[DOUBLE, BOOLEAN] с dropLRUPercent[] (доля для сброса) и randomDropLRU[] (сбрасывать случайно, а не по давности)

Перезапуск сервера

Модуль управляет аккуратным перезапуском сервера и блокировкой входа. restartPushed[] фиксирует, что перезапуск запрошен; notRestartPushed[] — его отрицание, определяющее, какой элемент управления показывает форма.

Свойство / действие	Что делает
scheduledRestart[]	признак: при установке запрос перезапуска реально перезапускает сервер
forbidLogin[]	признак: при установке запрос перезапуска блокирует новые входы (отложенный перезапуск)
restartServer[]	абстрактное списочное действие, выполняющее запрос перезапуска: при scheduledRestart[] вызывает restartServerAction[], при forbidLogin[] — setPendingRestartAction[], ставит restartPushed[] и применяет изменения
cancelRestartServer[]	абстрактное списочное действие, отменяющее запрос: вызывает cancelRestartServerAction[] и resetPendingRestartAction[], снимает restartPushed[] и применяет изменения
restartServerAction[] / cancelRestartServerAction[]	низлежащие действия перезапуска и отмены перезапуска сервера
setPendingRestartAction[] / resetPendingRestartAction[]	установить / снять признак отложенного перезапуска у сервера
isServerRestarting[]	родной признак: сервер находится в процессе перезапуска; isNotServerRestarting[] — его отрицание

Настройки

Механизм Setting хранит именованные общесистемные настройки, значение которых можно переопределить по роли пользователя. Объект Setting опознаётся по name[Setting] (ISTRING); setting[ISTRING] ищет настройку по имени.

У настройки есть три хранимых значения, и она разрешает их через OVERRIDE, беря первое непустое:

Свойство	Роль в разрешении
baseValue[Setting, UserRole]	значение, заданное для конкретной роли — проверяется первым
baseValue[Setting]	значение, заданное для настройки в целом — проверяется следующим
defaultValue[Setting]	встроенное значение по умолчанию — проверяется последним

Таким образом, value[Setting, UserRole] разрешается в baseValue[Setting, UserRole], затем baseValue[Setting], затем defaultValue[Setting]; value[Setting] (без роли) — в baseValue[Setting], затем defaultValue[Setting]. overBaseValue[Setting, UserRole] — базовое значение по роли или общее (без значения по умолчанию).

Для чтения настройки по имени из логики: valueSetting[ISTRING] возвращает разрешённое строковое значение именованной настройки, а valueSettingBoolean[ISTRING] — равно ли это значение 'true'.

pushSetting[STRING, STRING] и popSetting[STRING] временно задают и восстанавливают значение настройки на сервере. writeDefaultSettings[] заполняет значения по умолчанию; updateSetting[Setting, UserRole, BOOLEAN] и вспомогательное updateGlobalSetting проталкивают изменённое значение в работающий сервер (системный пользователь, пользователи без роли и каждая роль), что запускается через WHEN CHANGED на baseValue и заново применяется в onInit. Платформа поставляет ряд именованных настроек (читаемых через valueSetting / valueSettingBoolean по всей платформе); заполняемые значения по умолчанию здесь не перечисляются.

Пользовательская диагностика

Эти признаки на User включают дополнительное журналирование и диагностику запросов для отдельного пользователя. Каждый устроен одинаково: хранимое свойство DATA BOOLEAN (User), действие set…, объявленное через INTERNAL и проталкивающее значение в сервер, действие refresh…, заново применяющее текущее значение, событие WHEN CHANGED, обновляющее при каждом изменении, и повторное применение в onStarted. Показаны на вкладке пользовательского журналирования формы settings.

Свойство	Что включает для пользователя
explainAnalyzeMode[User]	журналирование EXPLAIN ANALYZE выполняемых запросов (turnExplainAnalizeOnCurrentUser[] включает его для текущего пользователя)
loggerDebugEnabled[User]	журналирование сервера на уровне debug
explainTemporaryTablesEnabled[User]	включение временных таблиц в explain запросов
remoteLoggerDebugEnabled[User]	журналирование удалённых вызовов на уровне debug
remoteExLogEnabled[User]	журналирование выполнения удалённых вызовов
remotePausableLogEnabled[User]	журналирование приостанавливаемых удалённых вызовов
explainAppEnabled[User]	explain выделения памяти
volatileStatsEnabled[User]	использование изменчивой статистики для запросов пользователя

Пользовательские настройки выполнения

Эти свойства на пользователе настраивают выполнение запросов и поведение клиента. execEnv[User] (класс TypeExecEnv с объектами materialize, disablenestloop, none) выбирает среду выполнения запросов и проталкивает выбранный id[TypeExecEnv] в сервер тем же набором set… / refresh… / WHEN CHANGED, что и у признаков диагностики; nameExecEnv[User] — его подпись.

Свойство	Чем управляет
useBusyDialogCustom[CustomUser]	принудительно включает диалог ожидания для пользователя
useRequestTimeout[CustomUser]	применяет таймаут запроса для пользователя
devMode[CustomUser]	режим разработки для пользователя (отладка)
transactTimeout[CustomUser]	таймаут транзакции (в секундах) для пользователя

turnCacheStatsOff[] отключает кэширование статистики на сервере.

Клиентские логи и дампы

Модуль позволяет администратору вытянуть логи и дамп потоков с клиента подключённого пользователя; показано на вкладке пользовательского журналирования формы settings.

Действие	Что делает
requestUserLogs[CustomUser]	просит каждый подключённый клиент пользователя выгрузить свои логи в fileUserLogs[Connection]; предупреждает, если пользователь не подключён
openUserLogs[CustomUser]	открывает выгруженные логи соединений пользователя
requestThreadDump[CustomUser]	просит каждый подключённый клиент пользователя выгрузить дамп потоков в fileThreadDump[Connection]
openThreadDump[CustomUser]	открывает выгруженный дамп потоков

Клиентский интерфейс по пользователям

Форма settings позволяет задавать настройки клиентского интерфейса по пользователям (и значения по умолчанию). Цвета хранятся на User: selectedRowBackgroundColor[User], selectedCellBackgroundColor[User], focusedCellBackgroundColor[User], focusedCellBorderColor[User], tableGridColor[User]; варианты override… (overrideFocusedCellBorderColor[], overrideTableGridColor[]) берут сначала значение текущего пользователя, иначе — значение по умолчанию приложения. resetWindowsLayout[] сбрасывает сохранённую раскладку окон.

SSL-учётные данные для внешнего (HTTP) сервера также хранятся здесь, в двух вариантах, управляемых useKeystore[]:

• хранилище ключей: keystore[] плюс keystorePassword[] и keyPassword[], с тройкой действий над файлом loadKeystore[] / openKeystore[] / resetKeystore[];
• PEM: privateKey[] и chain[] со своими тройками load / open / reset и privateKeyPassword[].

computerSettings[] собирает клиентские настройки по Computer (сейчас textFieldPropertyEditorScannerSleep[Computer]) в виде значения JSON для клиента.

Масштабирование базы данных

DBServer (абстрактный) — узел базы данных со свойствами host[DBServer] и snmpPort[DBServer]. Конкретные классы — DBMaster (главный узел; его host — настроенный сервер базы данных) и DBSlave (реплика; её host — это slaveHost[DBSlave]). Форма scaling показывает серверы и их локальные свойства мониторинга — load, lsn, readyStatus, availability, lag, usedCpu, numberConnections (все DATA LOCAL на DBServer, обновляются действием updateServersAction[]).

addSlave[DBSlave] и removeSlave[DBSlave] регистрируют и снимают регистрацию реплики на работающем сервере; асинхронные обёртки asyncAddSlave / asyncRemoveSlave выполняют их в новой сессии и потоке. Смена хоста реплики перерегистрирует её, а на onStarted регистрируется каждая реплика.

API серверных настроек

Три действия выгружают серверную конфигурацию клиентам в виде JSON; все объявлены @@noauth, поэтому доступны до входа в систему. Каждое — абстрактное действие CASE с реализацией по умолчанию, собирающей конфигурацию и выдающей её оператором EXPORT JSON.

Действие	Что выгружает
getServerSettings[]	конфигурацию до входа: имя и графику приложения, версии платформы / API, признаки регистрации и двухфакторной аутентификации, ресурсы без авторизации и нужные lsfParams
getInitSettings[]	ресурсы инициализации веб-клиента, загружаемые при старте клиента
getClientSettings[]	конфигурацию клиента по пользователю: цвета, шрифты, локаль, диапазоны пикеров и множество клиентских опций, управляемых valueSetting / valueSettingBoolean

resetServerSettingsCacheAction[] сбрасывает кэш серверных настроек; срабатывает по WHEN CHANGED на lsfParams и на имени / графике приложения, чтобы следующий вызов API пересобрал их.

Формы и навигатор

Форма	Назначение
maintenance	обслуживание и пересчёт базы данных, управление перезапуском, действия над ВМ / памятью
settings	общие настройки, таблица Setting, пользовательская диагностика, выполнение, клиентский интерфейс и клиентские опции
scaling	серверы базы данных и их значения мониторинга

Навигатор добавляет settings (первым), maintenance (после performance) и scaling в системную папку.

Язык

• Оператор INTERNAL — объявляет действия обслуживания, режимов, диагностики, настроек и масштабирования над их Java-классами реализации.

Связано

• System modules — общий перечень модулей платформы.
• Process monitor — представление работающих процессов, которое поддерживают диагностика и дампы этого модуля.
• Journals and logs — логи сервера, которые наполняют пользовательские признаки журналирования.
• Working parameters — рабочие параметры и настройки, конфигурируемые этой административной поверхностью.
• Backup and restore — резервное копирование базы данных рядом с действиями обслуживания базы здесь.
• Reflection — модуль метаданных, на котором держатся административные формы.
• SystemEvents — модуль событий жизненного цикла сервера, подключаемый через REQUIRE.
• Authentication — пользователи и роли, относительно которых хранятся настройки и предпочтения интерфейса.