НАЧАЛО >> Документация >> Руководство администратора >> Технические особенности📄 Скачать в DOCX
Раздел описывает внутренние механизмы модуля Queue, которые важны при настройке производительности, диагностике зависших задач и разборе высокой нагрузки на сервер.
Модуль снижает количество обращений к файловой системе и SQLite за счет системного кеша. Часто изменяемые состояния не перечитываются из базы при каждом опросе интерфейса или рабочего потока, а синхронизируются через быстрые ключи кеша.
| Механизм | Что кешируется или оптимизируется | Практический эффект |
|---|---|---|
QueueTaskStatus_<ID> |
Прогресс задачи, текст прогресса и время последней активности (progress, progressmsg, lastactivity) |
Частые обновления прогресса не создают постоянную запись в QueueInfo.db, а мониторинг получает актуальное состояние из памяти. |
QueuePaused |
Глобальная пауза очереди | Диспетчер и уже запущенные потоки быстрее узнают, что очередь остановлена, без лишнего чтения записи настроек. |
QueueOnlyHigh |
Режим обработки только приоритетных задач | Рабочие потоки быстро отсекают обычные задачи, когда сервер должен выполнять только приоритетные операции. |
SqlBatch |
Пакетное выполнение накопленных SQL-запросов | Очистка завершенных, ошибочных и зависших задач делает меньше отдельных операций записи и короче удерживает блокировку SQLite. |
При постановке задачи в очередь Queue сразу создает запись состояния QueueTaskStatus_<ID> с начальным прогрессом и временем активности. При вызовах SetProgress, GetProgress, SetTaskInfoElm и GetTaskInfoElm поля прогресса и lastactivity обрабатываются через кеш, поэтому частые обновления не перегружают диск.
Выбор задачи для запуска учитывает время отложенного старта: в работу попадают только задачи, у которых started меньше или равен текущему времени. Это позволяет заранее помещать задания в очередь без риска преждевременного запуска.
Сборщики мусора (ClearDonedTasks, ClearErroredTasks, ClearTimeoutedTasks) используют пакетные транзакции и синхронизируют удаление с кешем. Когда завершенная задача физически удаляется из базы, ее QueueTaskStatus_<ID> также удаляется из памяти, чтобы кеш не накапливал устаревшие состояния.
Для удаленных задач действие RetrieveRemoteResult после чтения результата удаляет временный SID-файл через SidFileRemove. Это предотвращает повторное получение старого результата при следующем обращении с тем же идентификатором.
QueueInfo.db), работающую в режиме журналирования WAL. Файл базы располагается в корневой директории данных системы (DataPath).donetimeout). Задачи, зависшие по таймауту, автоматически переводятся в статус ошибки скриптом ClearTimeoutedTasks.database is locked или sqlite3::busy), распознаются эвристическим алгоритмом системы и автоматически отправляются на повторный запуск (по умолчанию до 3 попыток) без вмешательства администратора.Cache.php).lastactivity), методы SetTaskInfoElm и GetTaskInfoElm могут обращаться напрямую в кеш, полностью минуя обращения к SQLite.dedupstring, система проверит наличие аналогичной задачи в очереди и проигнорирует новую. Это эффективно спасает сервер от перегрузок при случайных многократных кликах в интерфейсе.cURL с таймаутом в 100 мс) к самому веб-серверу. Это позволяет мгновенно отдавать ответ браузеру пользователя, не дожидаясь реального старта тяжелого фонового процесса.CURLOPT_SSL_VERIFYPEER=0). Это гарантирует работу подсистемы на локальных серверах с самоподписанными сертификатами.FileLock). Это полностью исключает «состояние гонки» (race condition) и гарантирует, что одну задачу не смогут захватить два воркера одновременно.SqlBatch), что радикально снижает количество I/O операций и время блокировки файла SQLite.AppendBatch), что снижает накладные расходы при генерации сотен связанных подзадач.MonitorSubTasksProgress) модуль не опрашивает их построчно. Состояния проверяются единым агрегированным SQL-запросом (IN (...)), что избавляет систему от проблемы N+1 запросов.mmap_size=128 МБ), временные таблицы в RAM (temp_store=MEMORY), а также ускоренный режим синхронизации (synchronous=NORMAL) с ограничением размера файла журналирования (WAL) до 64 МБ.busyTimeout (60 секунд). В режиме обычной рядовой эксплуатации он автоматически снижается до 10 секунд для предотвращения "залипания" рабочих потоков.Queue умеет автоматически сканировать исходный код других модулей системы (по наличию флага _checkQueueAction) и динамически генерировать для них фоновые задачи-мониторы, кешируя этот список на сутки.started) меньше или равно текущему системному времени.SetProgress) происходит сверка актуального статуса задачи в БД. Если задача была отменена пользователем или удалена из очереди администратором, скрипт прекращает сохранение её состояния, что позволяет безопасно прервать процесс и сэкономить ресурсы сервера.max_execution_time до 20 часов), предотвращая принудительное завершение поллинга системой.worker_id) и регулярно обновляет свой системный «пульс» (QueueThreadState_) в APCu-кеше. Это позволяет панели управления выявлять намертво зависшие потоки PHP.SetMonitorLogFile). Данные о путях к логам сохраняются в кеш потока, обеспечивая возможность живого чтения детализированной аналитики прямо в пользовательском интерфейсе.MonitorSubTasksProgress) интервал опроса базы данных не является фиксированным. Он динамически увеличивается (с 1 до 5 секунд) по мере ожидания завершения операций, чтобы исключить лишнюю нагрузку на подсистему I/O.5). При его активации диспетчер полностью блокирует обычные фоновые задачи (статус 0), резервируя все мощности и потоки сервера под критически важные операции.QueuePaused) кешируется в оперативной памяти и проверяется не только диспетчером при старте новых задач, но и внутри уже запущенных процессов при обновлении ими своего прогресса (SetProgress), что позволяет им своевременно реагировать на системные события.dedupstring со специальным значением @, система автоматически вычислит MD5-хеш от имени действия и предварительно отсортированного массива параметров. Это гарантирует, что абсолютно идентичные задачи с одинаковой полезной нагрузкой не будут поставлены в очередь дважды.single=true при добавлении гарантирует, что в очереди может находиться только одна задача указанного типа (action), независимо от передаваемых параметров.IDX_state_started), которые покрывают сразу и фильтрацию по статусу, и проверку времени отложенного запуска. Это позволяет избегать избыточных одиночных индексов и ускоряет INSERT/UPDATE операции.SQLITE3_OPEN_READONLY. Это минимизирует конфликты с пишущими воркерами и повышает параллельную производительность.QueueDB.log, а логика жизненного цикла задач — в Queue.log.params, options, result) прозрачно сериализуются при записи в БД и безопасно восстанавливаются (@unserialize), позволяя передавать в фоновые процессы массивы и объекты любой вложенности без создания реляционных таблиц.QueueEmptyState_0, QueueEmptyState_5). Это мгновенно сигнализирует спящим рабочим потокам о появлении новой работы, минуя таймауты анти-коллизионного поллинга.InfoQueue не генерирует HTML на сервере при регулярных обновлениях данных. Она работает как SPA, запрашивая легковесный JSON (Queue/GetState) и обновляя DOM-дерево в браузере, что снимает нагрузку с сервера даже при сотнях активных воркеров.FileLock). Если задача не обновляла свой пульс, но её лок всё ещё удерживается "живым" процессом, сборщик не прервет её выполнение.state=3) ограничено счетчиком попыток (опция max_retries, по умолчанию 3). При исчерпании лимита задача переводится в специальный статус "Фатальная ошибка" (state=6), прекращает попытки автоматического запуска и сохраняется для ручного разбора администратором.data-close-window="true"), то при клике на нее окно автоматически закроется через 2 секунды, позволяя пользователю предварительно ознакомиться с результатами.FileLock) на конкретный ID задачи сроком на 5 минут (lock('QueueProcessTask_ID', 300)). Это страхует от состояний гонки и ситуаций, когда другой воркер попытается взять ту же задачу при временных сбоях в базе данных.window.history.pushState для динамического обновления URL без перезагрузки страницы. Это позволяет делиться прямыми ссылками на определенные выборки (например, "все фатальные ошибки") и использовать системные кнопки браузера "Назад"/"Вперед".AppendTask) поддерживает флаг isRemote, который генерирует уникальный remoteId для задачи, позволяя внешним системам отслеживать исполнение своих команд через очередь ИРБИС.Queue/RemoveTask. При следующей попытке рабочего потока обновить свой прогресс через SetProgress, система обнаружит отсутствие задачи в БД и вернет false. Разработчики могут обрабатывать этот ответ в цикле задачи для ее немедленного и безопасного (graceful) завершения.StartProcessBackground) защищен не только глобальной блокировкой (FileLock), но и ограничением на уровне сессии PHP ($_SESSION). Это решает классическую проблему «залипания» сессии, предотвращая зависание всего интерфейса пользователя, если браузер инициирует несколько ресурсоемких задач одновременно.KillThread или KillAllStuck), мгновенно возвращая в строй лимиты воркеров без рестарта веб-сервера.UPDATE data SET ... WHERE ...), оптимизируя работу с тысячами записей.