Jump to content

Manual:İş kuyruğu

From mediawiki.org
This page is a translated version of the page Manual:Job queue and the translation is 83% complete.
Outdated translations are marked like this.

MediaWiki 1.6'da, uzun süre çalışan görevleri eşzamansız olarak gerçekleştirmek için bir iş kuyruğu tanıtıldı. İş kuyruğu, toplu işleme kullanarak birçok kısa görevi tutmak için tasarlanmıştır.

Kurulum

Bunun yerine, komut satırı üzerinden işlerin çalışmasını tamamen arka planda planlamanız önerilir. Varsayılan olarak işler bir web talebinin sonunda çalıştırılır. $wgJobRunRate ile 0 olarak ayarlayarak bu varsayılan davranışı devre dışı bırakın.

İşler karşıya yüklenen dosyalara dokunursa dosya sistemi izinlerinin doğru şekilde hesaplanmasını sağlamak için runJobs.php web sunucusunun çalıştığı aynı kullanıcı olarak çalıştırmalısınız.

Cron

İşleri her saat çalıştırmak için cron kullanabilirsiniz. Aşağıdakileri crontab dosyanıza ekleyin:

0 * * * * /usr/bin/php /var/www/wiki/maintenance/runJobs.php --maxtime=3600 > /var/log/runJobs.log 2>&1

Cron kullanmak, başlamayı kolaylaştırır, ancak e-posta bildirimlerini ve basamaklı şablonu yavaşlatabilir (bir saate kadar beklemek için). Bunun yerine sürekli bir iş yürütme aracı kurmak için aşağıdaki yaklaşımlardan birini kullanmayı düşünün.

Hizmet devamı

Kabuk erişiminiz ve başlangıç ​​betikleri oluşturma olanağınız varsa, işleri kullanılabilir hale geldiklerinde çalıştırmak için basit bir hizmet oluşturabilir ve ayrıca iş çalıştırıcısının sunucunun CPU kaynaklarını tekeline almasını önlemek için bunları azaltabilirsiniz:

Örneğin /usr/local/bin/mwjobrunner altında bir bash betiği oluşturun:

Create script

#!/bin/bash
# MediaWiki kurulum yolunu aşağıdaki satıra koyun
MW_INSTALL_PATH="/home/www/www.mywikisite.example/mediawiki"
RUN_JOBS="$MW_INSTALL_PATH/maintenance/runJobs.php --maxtime=3600"
echo İş hizmeti başlatılıyor...
# Diğer işlemlerin başlaması için zaman tanımak için sunucu başladıktan sonra bir dakika bekleyin
sleep 60
echo Başlatıldı.
while true; do
	# Kuyrukta kaç tane olursa olsun en kısa sürede çalıştırılması gereken iş türleri
	# Bu işler çalıştırmak için çok "ucuz" olmalıdır
	php $RUN_JOBS --type="enotifNotify"
	# Diğer her şey, her topludaki iş sayısını sınırlayın
	# --wait parametresi, yeni işler eklenene kadar burada yürütmeyi duraklatacak,
	# döngüyü yapacak bir şey olmadan çalıştırmaktan kaçınmak için
	php $RUN_JOBS --wait --maxjobs=20
	# CPU'nun web isteklerini işleme gibi başka şeyler yapmasına izin vermek için birkaç saniye bekleyin.
	echo 10 saniye bekleniyor...
	sleep 10
done

Sunucunun ne kadar hızlı olduğuna ve işlediği yüke bağlı olarak, her döngüde çalıştırılacak iş sayısını ve her döngüde beklenecek saniye sayısını ayarlayabilirsiniz.

Betiği çalıştırılabilir yapın (chmod 755).

Create service

systemd kullanıyorsa, /etc/systemd/system/mw-jobqueue.service dosyasını oluşturarak yeni bir hizmet birimi oluşturun. User parametresini, web sunucunuzda PHP çalıştıran kullanıcı olarak değiştirin:

[Unit]
Description=MediaWiki Job runner

[Service]
ExecStart=/usr/local/bin/mwjobrunner
Nice=10
ProtectSystem=full
User=php-fpm
OOMScoreAdjust=200
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Etkinleştirin ve şu komutlarla başlatın:

sudo systemctl enable mw-jobqueue
sudo systemctl start mw-jobqueue
sudo systemctl status mw-jobqueue

Sayfa isteklerinde iş yürütme

Varsayılan olarak, her web isteğinin sonunda, iş kuyruğundan bir iş alınır ve yürütülür. Bu davranış, $wgJobRunRate yapılandırma değişkeni tarafından kontrol edilir. Bu değişkeni 1 olarak ayarlamak, her istekte bir iş çalıştırır. Bu değişkeni 0 olarak ayarlamak, web istekleri sırasında işlerin yürütülmesini tamamen devre dışı bırakır, böylece bunun yerine runJobs.php ile elle veya düzenli olarak komut satırından çalıştırabilirsiniz.

MediaWiki sürümü:
1.23

Etkinleştirildiğinde, işler bir soket açılarak ve listelenmemiş bir özel sayfa için dahili bir HTTP isteğinde bulunarak yürütülecektir: Special:RunJobs. Eşzamansız bölüme de bakın.

Performans sorunu

Her web isteğinde iş çalıştırmanın performans yükü çok fazlaysa, ancak işleri komut satırından çalıştıramıyorsanız, $wgJobRunRate , 1 ile 0 arasında bir sayıya düşürebilirsiniz. Bu, bir işin her 1 / $wgJobRunRate isteğinde "ortalama olarak" yürütüleceği anlamına gelir.

$wgJobRunRate = 0.01;

Manüel kullanımı

İş kuyruğunu manüel olarak boşaltmanın bir yolu da vardır, örneğin birçok sayfada bulunan bir şablonu değiştirdikten sonra. maintenance/runJobs.php bakım betiğini çalıştırın. Örneğin:

/path-to-my-wiki/maintenance$ php ./runJobs.php

Abandoned jobs

A job can fail for some reasons. To understand why, you have to inspect the related log file.

In any case, if a job fails 3 times (so if the system has done that number of attempts), the job is then considered "abandoned" and it's not executed again.

Relevant source code:

https://doc.wikimedia.org/mediawiki-core/master/php/JobQueue_8php_source.html#l00085

An abandoned job is:

Geçmiş

Eşzamansız

Yapılandırma değişkeni $wgRunJobsAsync , işin yürütülmesi için dahili bir HTTP isteğinde bulunmanın istenmediği betiklerde, işlerin eşzamanlı olarak yürütülmesini zorlamak için eklenmiştir.

İşleri eşzamansız olarak çalıştırırken, işlerin yürütülmesi için dahili bir HTTP bağlantısı açacak ve işin tamamlanmasını beklemeden sayfanın içeriğini istemciye anında döndürecektir. Aksi takdirde, iş aynı süreçte yürütülecek ve iştemcinin iş tamamlanana kadar beklemesi gerekecektir. İş eşzamansız olarak çalışmadığında, işin yürütülmesi sırasında önemli bir hata oluşursa, istemciye yayılır ve sayfanın yüklenmesini iptal eder.

$wgRunJobsAsync true değerine ayarlansa bile, PHP dahili HTTP isteğini yapmak için bir soket açamazsa, senkronize iş yürütmeye geri döneceğini unutmayın. Ancak, bu dahili isteğin başarısız olabileceği ve eşzamanlı iş yürütmeye geri dönmeden işlerin çalıştırılmayacağı çeşitli durumlar vardır. MediaWiki 1.28.1 ve 1.27.2'den başlayarak, $wgRunJobsAsync artık varsayılan olarak false değerine ayarlanmıştır.

Ertelenen güncellemeler

Ertelenmiş güncellemeler mekanizması, tüm içerik tarayıcıya gönderildikten sonra, kodun yürütülmesinin isteğin sonu için programlanmasına izin verir. This is similar to queuing a job, except that it runs immediately instead of upto several minutes/hours in the future.

DeferredUpdates MediaWiki 1.23'te tanıtıldı ve MediaWiki 1.27 ve 1.28 sırasında büyük değişiklikler aldı. Bu mekanizmanın amacı, daha az iş yaparak web yanıtlarını hızlandırmak ve yanıtın bitiminden sonra mümkün olan en kısa sürede çalıştırılacak bazı işlere öncelik vermektir.

A deferrable update can implement EnqueueableDataUpdate in order to be queueable as a Job as well. This is used by RefreshSecondaryDataUpdate in core, for example, which means if the update fails for any reason, MediaWiki will fallback to queuing as a job and try again later as to fulfil the contract in question.

MediaWiki 1.22'deki değişiklikler

MediaWiki 1.22 üzerinde, her bir sayfa isteğindeki iş kuyruğu yürütmesi değiştirildi (Gerrit change 59797), bu nedenle, işi sayfayı işleyen aynı PHP işlemi içinde yürütmek yerine, arka planda runJobs.php çalıştırmak için yeni bir PHP cli komutu üretilir. Yalnızca $wgPhpCli gerçek bir yola ayarlanmışsa veya güvenli mod kapalıysa çalışır, aksi takdirde eski yöntem kullanılır.

Bu yeni yürütme yöntemi bazı sorunlara neden olabilir:

  • $wgPhpCli , PHP'nin uyumsuz bir sürümüne ayarlanmışsa (örneğin, eski bir sürüm) işler çalışmayabilir (1.23'te düzeltildi).
  • PHP open_basedir kısıtlamaları yürürlükte ve $wgPhpCli ile izin verilmiyor (görev T62208, 1.23'te düzeltildi).
  • Performans: iş kuyruğu boş olsa bile, yeni PHP işlemi yine de başlatılır (görev T62210, 1.23'te düzeltildi).
  • Bazen ortaya çıkan PHP süreci, stdout ve stderr tanımlayıcılarının düzgün bir şekilde yeniden yönlendirilmemesi nedeniyle sunucunun veya yalnızca CLI işleminin askıda kalmasına neden olur (görev T60719, 1.22'de düzeltildi)
  • Paylaşılan kod (viki çiftlikleri) için çalışmaz, çünkü işi çalıştıran vikiyi tanımlamak için gereken ek parametreleri runJobs.php'ye iletmez (görev T62698, 1.23'te düzeltildi)
  • $MaxShellMemory, $MaxShellTime ve $MaxShellFileSize gibi normal kabuk sınırları, arka planda çalıştırılan runJobs.php işleminde uygulanır.

Örneğin $wgPhpCli ile false olarak belirlemenin yanı sıra, eski istek üzerine iş kuyruğu işlemeye geri dönmenin bir yolu yoktur, bu da başka sorunlara neden olabilir (görev T63387). $wgJobRunRate = 0; ayarlayarak tamamen devre dışı bırakılabilir, ancak işler artık sayfa isteklerinde çalışmayacaktır ve beklemedeki işleri düzenli olarak çalıştırmak için runJobs.php'yi açıkça çalıştırmanız gerekir.

MediaWiki 1.23'deki değişiklikler

MediaWiki 1.23'te, 1.22 yürütme yöntemi terk edilir ve işler MediaWiki tarafından kendisine bir HTTP bağlantısı kurarak tetiklenir.

İlk olarak bir API giriş noktası (Gerrit change 113038) olarak tasarlandı ancak daha sonra listelenmemiş özel sayfa Special:RunJobs (Gerrit change 118336) olarak değiştirildi.

1.22'de ortaya çıkan çeşitli hataları çözerken, bir işi yürütmek için yeni bir işlemde belleğe birçok PHP sınıfının yüklenmesini gerektirir ve ayrıca sunucunun işlemesi gereken yeni bir HTTP isteğinde bulunur.

MediaWiki 1.27'deki değişiklikler

MediaWiki 1.25 ve MediaWiki 1.26'da, vikinin özel $wgServerName yapılandırması varsa, $wgRunJobsAsync kullanımı bazen işlerin çalıştırılmamasına neden olabilir. Bu, MediaWiki 1.27'de düzeltildi. görev T107290

MediaWiki 1.28'deki değişiklikler

MediaWiki 1.23 ve MediaWiki 1.27 arasında, $wgRunJobsAsync kullanımı, MediaWiki istekleri şu anda yapılandırılmış olan sunucu adıyla eşleşmeyen bir sunucu adı veya protokol için ise (örneğin hem HTTP hem de HTTPS'yi desteklerken veya MediaWiki, HTTPS'ye yeniden yönlendiren bir ters proxy'nin arkasındadır). Bu, MediaWiki 1.28'de düzeltildi. görev T68485

MediaWiki 1.29'daki değişiklikler

MediaWiki 1.27.0 - 1.27.3 ve 1.28.0 - 1.28.2'de, $wgJobRunRate 0'dan büyük bir değere ayarlandığında, aşağıdaki gibi bir hata, hata günlüklerinde veya sayfada görünebilir:

PHP Notice: JobQueueGroup::__destruct: 1 buffered job(s) never inserted

Bu hatanın bir sonucu olarak, iş kuyruğunu temizlemek için runJobs.php olarak elle çalıştırsanız bile, kategori üyelerinin kategori sayfalarında güncellenmemesi veya silinen sayfaların düzenlemelerini görüntüleyen son değişiklikler gibi bazı durumlarda bazı güncellemeler başarısız olabilir. Hata (görev T100085) olarak bildirildi ve 1.27.4 ve 1.28.3'te çözüldü.

İş örnekleri

Bir şablon değiştiğinde bağlantı tablolarını güncelleme

Bir şablon değiştiğinde, MediaWiki bu şablonu aşan her madde için iş kuyruğuna bir iş ekler. Her iş, bir maddeyi okumak, herhangi bir şablonu genişletmek ve bağlantı tablosunu buna göre güncellemek için bir komuttur. Önceden, ana bilgisayar maddeleri, ayrıştırıcı önbelleği sona erene veya bir kullanıcı maddeyi düzenleyene kadar güncelliğini yitirdi.

HTML önbelleğinin geçersiz kılınması

Daha geniş bir işlem sınıfı, çok sayıda sayfa için HTML önbelleğinin geçersiz kılınmasına neden olabilir:

  • Bir resmi değiştirme (tüm küçük resimlerin yeniden oluşturulması ve boyutları yeniden hesaplanması gerekir)
  • Bir sayfayı silme (diğer sayfalardan ona giden tüm bağlantıların maviden kırmızıya dönmesi gerekir)
  • Bir sayfa oluşturma veya silme işlemini geri alma (yukarıdaki gibi, ancak kırmızıdan maviye)
  • Bir şablonu değiştirme (şablonu aşan tüm sayfaların güncellenmesi gerekir)

Şablon değişiklikleri dışında, bu işlemler bağlantı tablolarını geçersiz kılmaz, ancak o sayfaya bağlanan veya o resmi kullanan tüm sayfaların HTML önbelleğini geçersiz kılar. Bir sayfanın önbelleğini geçersiz kılmak kısa bir işlemdir; önbellekleri temizlemek için yalnızca tek bir veritabanı alanını güncellemeyi ve çok noktaya yayın paketi göndermeyi gerektirir. Ancak yapılacak yaklaşık 1000'den fazla varsa, uzun zaman alır. Varsayılan olarak, 300 işlem başına bir iş eklenir ($wgUpdateRowsPerJob sayfasına bakın)

Bununla birlikte, bir sayfanın önbelleğini temizlemek kısa bir işlem olsa bile, önbellekte olmayan karmaşık bir sayfanın yeniden ayrıştırılması, özellikle çok kullanılan bir şablon düzenlenirse ve bir sayfadaki birçok sayfanın temizlenmesine neden olursa pahalı olabilir. Kısa bir süre ve vikinizde çok sayıda sayfayı yükleyen çok sayıda eşzamanlı ziyaretçi var. Bu, kısa sürede temizlenen sayfa sayısını $wgUpdateRowsPerJob ile küçük bir sayıya (örneğin 20) düşürerek ve ayrıca htmlCacheUpdate için $wgJobBackoffThrottling düşük bir sayıya (örneğin 5) ayarlayarak hafifletilebilir.

Ses ve video kod dönüştürme

Ses ve video dosyalarının yerel yüklemelerini işlemek için TimedMediaHandler kullanıldığında, iş kuyruğu, çeşitli çözünürlüklerde/biçimlerde potansiyel olarak çok yavaş türev kod dönüştürmelerini çalıştırmak için kullanılır.

Bunlar web isteklerinde çalıştırmak için uygun değil. Bir arka plan çalıştırıcısına ihtiyacınız olacak.

Mümkünse webVideoTranscode ve webVideoTranscodePrioritized iş türleri için ayrı koşucular ayarlamanız önerilir. Bu iki kuyruk, farklı dosya alt kümelerini işler. İlki yüksek çözünürlüklü HD videolar için, ikincisi ise daha hızlı işleyen daha düşük çözünürlüklü videolar ve ses dosyaları için.

Tipik değerler

Düşük yük döneminde, iş kuyruğu sıfır olabilir. Wikimedia'da iş kuyruğu pratikte neredeyse hiç sıfır değildir. Yoğun olmayan saatlerde, birkaç yüz ile bin arasında olabilir. Yoğun bir günde birkaç milyon olabilir, ancak hızla %10 veya daha fazla dalgalanabilir. [1]

Special:Statistics

MediaWiki 1.16'ya kadar, iş kuyruğu değeri Special:Statistics sayfasında gösterildi. Ancak, 1,17'den (rev:75272) bu yana kaldırıldı ve şimdi API:Siteinfo ile görülebilir:

Veritabanındaki işlerin sayısını tahmin eden MySQL kullanılırken API sonucunda döndürülen işlerin sayısı biraz hatalı olabilir. Bu sayı, yakın zamanda eklenen veya silinen işlerin sayısına bağlı olarak dalgalanabilir. Hızlı sonuç boyutu tahminini desteklemeyen diğer veritabanları için gerçek iş sayısı verilir.

Geliştiriciler için

Kod yönetimi

Ayrıca bakınız