Jump to content

Руководство:RunJobs.php

From mediawiki.org
This page is a translated version of the page Manual:RunJobs.php and the translation is 59% complete.
Outdated translations are marked like this.
Начиная с MediaWiki 1.40, скрипты обслуживания должны вызываться непосредственно через maintenance/run.php . При прямом вызове скриптов обслуживания появится предупреждение.

Подробности

runJobs.php - файл скрипта обслуживания для ручного принудительного запуска очереди заданий. В обычных условиях задания в очереди выполняются в зависимости от взаимодействия пользователя с вики (обычные запросы apache). Скорость выполнения заданий по умолчанию составляет 1 к 1 и может быть изменена путем изменения значения $wgJobRunRate в файле LocalSettings.php . Обратите внимание, что по умолчанию лимит памяти для задания составляет 150 МБ, чтобы неудачное задание не заняло всю память сервера.

Вы можете использовать этот сценарий, потому что трафик вашей вики слишком медленный, чтобы очистить очередь, или может быть исключительно большое количество заданий, которые нужно очистить. Однако имейте в виду, что для многих конфигураций серверов это может привести к тому, что ваша вики станет медлительной или даже не будет реагировать на запросы, пока скрипт не выполнится. Попробуйте для начала выполнить скрипт для 50 или 100 заданий, чтобы почувствовать скорость его работы, прежде чем запускать скрипт на несколько сотен заданий или без параметров.

Обратите внимание, что если вы случайно запустили скрипт, который загрузил очередь заданий большим количеством нежелательных или ненужных заданий, можно также полностью очистить очередь заданий, очистив таблицу job в базе данных вашей вики. Убедитесь, что в очереди нет нужных вам заданий, так как все задания будут удалены безвозвратно.

Использование

Before MW 1.40
php maintenance/runJobs.php
MW 1.40+
php maintenance/run.php runJobs

Расширенное использование

Before MW 1.40
php maintenance/runJobs.php [--conf|--dbpass|--dbuser|--globals|--help|--maxjobs|--maxtime|--memory-limit|--nothrottle|--procs|--quiet|--server|--type|--wait|--wiki]
MW 1.40+
php maintenance/run.php runJobs [--conf|--dbpass|--dbuser|--globals|--help|--maxjobs|--maxtime|--memory-limit|--nothrottle|--procs|--quiet|--server|--type|--wait|--wiki]

Общие параметры обслуживания

Опция/Параметр Описание
нет параметров Запустятся все задания, находящиеся в очереди.
--help (-h) Вывести справку
--quiet (-q) Следует ли запретить вывод без ошибок
--conf Местонахождение LocalSettings.php, если не указано по умолчанию
--wiki Для указания идентификатора (ID) вики
--globals Вывод глобальных переменных в конце обработки для отладки
--memory-limit Устанавливает определённый лимит памяти для скрипта, max для отсутствия лимита или default, чтобы не менять его
--server Протокол и имя сервера для использования в URL-адресах, например https://en.wikipedia.org. Это иногда необходимо, поскольку определение имени сервера может не работать в сценариях командной строки.

Параметры скрипта

Опция/Параметр Описание
--dbuser Пользователь БД, который будет использоваться для этого скрипта
--dbpass Пароль для использования этого скрипта

Специальные параметры скрипта

Опция/Параметр Описание
--maxjobs Максимальное число заданий для запуска
--maxtime Максимальное количество фактического времени (в секундах)
--procs Количество используемых процессов
--type Тип выполняемого задания. См. $wgJobClasses для получения списка доступных заданий.
--wait Дождаться новых заданий вместо завершения
--nothrottle Игнорируйте конфигурацию ограничения скорости заданий
--result Устанавливает значение json, чтобы вывести только ответ в формате JSON

Use limits

Не рекомендуется запускать "runJobs.php" без каких-либо ограничений. Самостоятельное использование --maxjobs недостаточно, поэтому его лучше использовать в паре с --maxtime и/или --memory-limit. Обычно используется периодический запуск с установкой хотя бы одного из ограничений, чтобы не допустить слишком долгого выполнения за один раз.

Пример

Before MW 1.40
php maintenance/runJobs.php --maxjobs 5  --memory-limit 150M --type refreshLinks
MW 1.40+
php maintenance/run.php runJobs --maxjobs 5  --memory-limit 150M --type refreshLinks
Before MW 1.40
/home/flowerwiki/public_html/w/maintenance$ php runJobs.php --maxjobs 5 --memory-limit 150M --type refreshLinks
MW 1.40+
/home/flowerwiki/public_html/w/maintenance$ php run.php runJobs --maxjobs 5 --memory-limit 150M --type refreshLinks

When the script is run, you may see an output like this, here including jobs from the refreshLinks queue:

2010-10-29 13:50:38 refreshLinks Daisies STARTING
2010-10-29 13:50:38 refreshLinks Daisies t=501 good
2010-10-29 13:50:38 refreshLinks Magnolias STARTING
2010-10-29 13:50:38 refreshLinks Magnolias t=501 good
2010-10-29 13:50:39 refreshLinks Heirloom_Roses STARTING
2010-10-29 13:50:39 refreshLinks Heirloom_Roses t=500 good
2010-10-29 13:50:39 refreshLinks Carnations STARTING
2010-10-29 13:50:39 refreshLinks Carnations t=501 good
2010-10-29 13:50:40 refreshLinks Tulips STARTING
2010-10-29 13:50:40 refreshLinks Tulips t=563 good


Возможные проблемы

The job queue appears to be stuck

Under certain circumstances, "runJobs.php" may hang indefinitely. Some jobs may fail to get completed, clogging up the queue.

As noted above, it is best to prevent this from happening by providing the necessary flags, but if you do find yourself in this situation, ideally you should find the cause of the problem. Possible causes include

  • A missing PHP extension in the php.ini of the PHP being run from the command line.
  • A buggy extension.

No standard tools or methods are currently available to let you diagnose the issue.

Object caching

"runJobs.php" may hang if you have object caching enabled. If this happens, there is something you could try, with the caveat below in mind.

  1. Create another "LocalSettings.php" file with object caching disabled:
    $wgMainCacheType = CACHE_NONE;
    
  2. Then run runJobs.php, or run.php runJobs, with the --conf parameter to specify the location of the new LocalSettings.php file with caching disabled.

This approach is not recommended, since some jobs will purge objects from the object cache, which won't get purged because caching is disabled. This will result in some updates not being reflected on the wiki.

Terminate a running process

Sometimes, if you cannot find the problem and the job queue is creating overhead, you may have no other choice than to terminate it, possibly at the expense of deleting jobs you might need. If this is the case and you accept the risk, you can try to clear the job that you think is causing trouble, or clear the entire jobs table.

Note that on some control panels that use cronjob automation, clearing jobs may have no visible effect. The process initiated may still appear to hang even if there are no jobs left to execute.

Using a database administration tool
  • Go to your database administration tool (e.g. phpMyAdmin) and locate the job table.
  • If you're lucky, it may just be an active job that is causing trouble and that needs to be cleared. You can locate it by finding the row that has a hash value in the job_token column.
  • Repeat if necessary. If all else fails, clear the entire jobs table.
Using manageJobs.php

The maintenance script manageJobs.php does not lend you insights but it does let you delete jobs by group.

См. также