Celery: Masalah drift substansial

Apakah Anda menjalankan versi terbaru? Jika seseorang mengubah zona waktu mesin, Anda mungkin harus memulai ulang pekerja/bunga.

dikirim dari iPhone saya

Pada 18 Januari 2014, pukul 17.00, Ash Christopher [email protected] menulis:

Mirip dengan masalah "Pergeseran substansial" lainnya, saya melihat yang berikut:

11:57:32 bunga.1 | [W 140118 11:57:32 state:163 ] Penyimpangan substansial dari [email protected] mungkin berarti jam tidak sinkron. Penyimpangan saat ini adalah
11:57:32 bunga.1 | 3600 detik. [asal: 18-01-2014 11:57:32.070727 penerimaan: 18-01-2014 12:57:32.069728]
11:57:32 bunga.1 |

11:57:34 bunga.1 | [W 140118 11:57:34 state:163 ] Penyimpangan substansial dari [email protected] mungkin berarti jam tidak sinkron. Penyimpangan saat ini adalah
11:57:34 bunga.1 | 3600 detik. [asal: 18-01-2014 11:57:34.657175 penerimaan: 18-01-2014 12:57:34.656147]
11:57:34 bunga.1 |

11:57:37 bunga.1 | [W 140118 11:57:37 state:163 ] Penyimpangan substansial dari [email protected] mungkin berarti jam tidak sinkron. Penyimpangan saat ini adalah
11:57:37 bunga.1 | 3600 detik. [asal: 18-01-2014 11:57:37.047058 penerimaan: 18-01-2014 12:57:37.045609]
11:57:37 bunga.1 |

11:57:39 bunga.1 | [W 140118 11:57:39 state:163 ] Penyimpangan substansial dari [email protected] mungkin berarti jam tidak sinkron. Penyimpangan saat ini adalah
11:57:39 bunga.1 | 3600 detik. [asal: 18-01-2014 11:57:39.054193 penerimaan: 18-01-2014 12:57:39.052635]

Seperti yang Anda lihat, tugas sedang dibuat pada waktu yang tepat, tetapi dikatakan bahwa itu diterima satu jam kemudian. Saya menduga ini adalah masalah DST - apakah menurut kami ini adalah masalah di pihak Flower atau masalah Seledri?

—
Balas email ini secara langsung atau lihat di GitHub.

[vagrant<strong i="5">@vagrant</strong> wave_drop]$ pip freeze
...
celery==3.1.8
flower==0.6.0
...

Saya menjalankan seledri terbaru. Zona waktu kotak tidak diubah. Ini terjadi setiap kali bunga melawan seledri.

Anda harus mencari tahu apakah celery.utils.timeutils.utcoffset() mengembalikan nilai yang benar untuk setiap node

dikirim dari iPhone saya

Pada 20 Januari 2014, pukul 17:02, Ash Christopher [email protected] menulis:

[ gelandangan@gelandangan wave_drop]$ pip membeku
...
seledri == 3.1.8
bunga == 0.6.0
...
Saya menjalankan seledri terbaru. Zona waktu kotak tidak diubah. Ini terjadi setiap kali bunga melawan seledri.

—
Balas email ini secara langsung atau lihat di GitHub.

Ini sedang berjalan di mesin lokal saya. Saat aku berlari
celery.utils.timeutils.utcoffset() ia mengembalikan 0.
Pada 21 Jan 2014 09:25, "Ask Solem Hoel" [email protected] menulis:

Anda harus mencari tahu apakah celery.utils.timeutils.utcoffset() mengembalikan
nilai yang benar untuk setiap node

dikirim dari iPhone saya

Pada 20 Januari 2014, pukul 17.02 , Ash [email protected]
menulis:

[ gelandangan@gelandangan wave_drop]$ pip membeku
...
seledri == 3.1.8
bunga == 0.6.0
...
Saya menjalankan seledri terbaru. Zona waktu kotak belum
berubah. Ini terjadi setiap kali bunga melawan seledri.

—
Balas email ini secara langsung atau lihat di GitHub.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/celery/celery/issues/1802#issuecomment -32888911
.

Saya mengalami masalah serupa. Saya melewati seluruh pengaturan Django saya.

Celery == 3.1.8
Django == 1.6.X
Flower == 0.6.0

Saya di PST.

[1] % date
Wed Jan 22 15:00:48 PST 2014

Dalam pengaturan Django saya, yang saya berikan ke seledri dengan --config='mysettings' , saya punya:

TIME_ZONE = "America/New_York"

Saya memulai bunga dengan konfigurasi yang sama:

Current drift is
    10800 seconds.  [orig: 2014-01-22 15:03:12.572711 recv: 2014-01-22 12:03:12.571017]

Bahkan ketika saya mencoba mengatur:

CELERY_ENABLE_UTC = True
CELERY_TIMEZONE = "UTC"

Pergeseran itu ada. Namun, jika saya menyetel TIME_ZONE dalam pengaturan Django saya ke America/Los_Angeles , penyimpangannya hilang. Tampaknya pekerja seledri, bukan bunga, adalah orang yang sensitif terhadap perubahan pengaturan TIME_ZONE .

Saya telah menempelkan info yang relevan dari file pengaturan saya.

TIME_ZONE = 'UTC'
USE_TZ = True

CELERY_ENABLE_UTC = True
CELERY_TIMEZONE = "UTC"

Saya di Toronto ("Amerika/Toronto").

Saya ingin tahu apakah mungkin Django memodifikasi zona waktu dalam modul waktu.

Perhatikan bahwa stempel waktu acara tidak menggunakan TIME_ZONE, CELERY_ENABLE_UTC, atau pengaturan terkait datetime apa pun, karena hanya menggunakan zona waktu lokal mesin.

Kami juga mengalami masalah ini.

Oh, dan itu benar-benar _spams_ logging output ke Loggly, dan satu ton bandwidth keluar dari Rackspace. :( Apakah ini benar-benar perlu masuk pada setiap tugas, daripada saat startup pekerja?

Tolong beri kami cara untuk mematikan pesan ini.

Saya memiliki masalah yang sama.
Menjalankan dua server di Digital Ocean dengan Ubuntu 12.04.3 x64

• turbo mesin menjalankan Redis
• Mesin archiver hanya menjalankan pekerja dan sedang terhubung melalui terowongan SSH dengan penerusan port (untuk melihat port redis di localhost).

Tugas berjalan agak lama, masing-masing setidaknya 300 detik, beberapa kali lebih lama. Tidak ada tugas yang berjalan lebih lama dari 90 menit.

"Pergeseran substansial" hanya dilaporkan pada mesin archiver itu.

Menggunakan redis 2.2.12 (sedikit lebih tua - menggunakan paket yang disertakan dengan Ubuntu saya).

Beban pada kedua mesin adalah sekitar 8 hingga 10 - menjalankan 3 pekerja pada turbo dan 4-5 pekerja pada archiver . Setiap pekerja memiliki --autoscale=5,3 . Tugasnya adalah I/O intensif, membaca data dari ember AWS S3 dan mempostingnya kembali (jadi umumnya lalu lintas HTTP), terkadang memposting file besar 1GB (dalam potongan yang lebih kecil).

Saya juga mendapatkan masalah drift substansial dengan pengaturan berikut:

seledri == 3.1.10, bunga == 0.6.0
Mesin saya berada di zona waktu "Eropa/Paris".

Pada shell python biasa:

import time
def utcoffset():
    if time.daylight:
        return time.altzone // 3600
    return time.timezone // 3600

mengembalikan -2 (kami memang berada di UTC+2 saat ini).

Dengan celery shell , dan parameter CELERY_ENABLE_UTC = True dan CELERY_TIMEZONE = 'UTC' , from celery.utils.timeutils import utcoffset; utcoffset() memberikan 1.

Acara di celery events -d laporkan utcoffset=1

Tapi Bunga melaporkan:
Substantial drift from celery<strong i="22">@hostname</strong> may mean clocks are out of sync. Current drift is 3600 seconds. [orig: 2014-04-10 14:07:51.240687 recv: 2014-04-10 15:07:51.238797]

Sepertinya tidak ada efek apa pun jika saya mengganti CELERY_TIMEZONE ke yang lain..

Saya tidak terlalu terganggu dengan ini, saya hanya mencoba untuk mengerti!

@NotSqrt Apakah Anda menggunakan Django? Sepertinya saya ingat melihat Django memiliki beberapa efek samping pada zona waktu, mungkin itu melakukan semacam penambalan?

Saya menggunakan Django, jadi ya, mungkin itu saja.

Oke : Jika saya menyetel parameter Django TIME_ZONE ke zona waktu mesin saya, pesan drift Substansial menghilang. Jika saya mengaturnya ke sesuatu yang lain (UTC, Pacific/Tahiti atau di tempat lain), Flower melaporkan penyimpangan arus 3600 detik sepanjang waktu..

Pasti Django yang melakukan ini:

$ python manage.py shell
>>> from django.conf import settings
>>> settings.TIME_ZONE
'America/Chicago'
>>> import time, datetime
>>> time.timezone
21600
>>> time.altzone
18000
>>> str(datetime.datetime.fromtimestamp(time.time()))
>>> '2014-05-30 07:48:39.947606'

Tanpa Django:

 $ python
 >>> import time, datetime
 >>> time.timezone
 0
 >>> time.altzone
 -3600
 >>> str(datetime.datetime.fromtimestamp(time.time()))
 '2014-05-30 13:49:38.935562'

Jadi Django mengubah ini entah bagaimana

Saya harus mencatat (untuk orang-orang di masa depan yang menemukan masalah ini dengan googling) adalah bahwa itu juga dapat muncul saat menggunakan 3.1.9 dan 3.1.10 bersama-sama:

>>> import celery
>>> celery.__version__
'3.1.9'
>>> from celery.utils import timeutils
>>> timeutils.utcoffset()
-4

Melawan:

>>> import celery
>>> celery.__version__
'3.1.10'
>>> from celery.utils import timeutils
>>> timeutils.utcoffset()
4

@wolever , Anda perlu memutakhirkan ke versi yang lebih baru, saya pikir, itu mungkin diperbaiki lebih dari 3.1.9 setidaknya.

Tapi benar, ya bahwa Anda mencampur versi mungkin tidak langsung terlihat, jadi ide bagus untuk mengingatkan orang untuk memverifikasi bahwa mereka telah memutakhirkan semua host :)

Saya masih melihat ini

USE_TZ = Benar
TIME_ZONE = 'Asia/Seoul'
CELERY_ENABLE_UTC = Benar
CELERY_TIMEZONE = 'Asia/Seoul'

seledri versi 3.1.18
bunga 0.8.2

ketika saya menjalankan 'tanggal' di kotak ubuntu saya
itu menunjukkan waktu dalam UTC, => Saya melihat substantial drift

kotak ubuntu lain dengan zona waktu KST => tidak ada pesan drift substansial

@pcompassion Apakah ntpd dikonfigurasi dengan benar?

1. 
   
   1. 
      
      
      1. (월) 17:11:06 KST (kotak ubuntu yang tidak menunjukkan pesan peringatan)
      
      
      
   
   
2. 
   
   1. 
      
      
      1. (월) 08:11:45 UTC (kotak ubuntu dengan pesan kesalahan)
      
      
      
   
   

Mereka terlihat benar.

Saya masih melihat ini juga:

WARNING 2015-07-29 15:50:26,590 state 20212 140561769498432 Substantial drift from celery@together-dev may mean clocks are out of sync.  Current drift is
7200 seconds.  [orig: 2015-07-29 15:50:26.504807 recv: 2015-07-29 13:50:26.503507]

Server adalah UTC dengan pengaturan ini:

CELERY_ENABLE_UTC = True
TIME_ZONE = 'Europe/Stockholm'
USE_TZ = True

Harap sertakan versi seledri, saya telah memperbaiki masalah ini sejak lama

Saya menjalankan Django Django==1.8.1,celery==3.1.18 dengan NTP pada 7 mesin.
Setiap mesin berjalan ~10 pekerja mengkonsumsi dari antrian yang berbeda, salah satu pekerja menyebabkan drift dan semua pekerja untuk semua antrian di setiap mesin terus mengeluh tentang drift dan mereka tidak mengkonsumsi tugas.

Penyimpangan substansial dari celery@CELERY_ADMINMGRQ_appv mungkin berarti jam tidak sinkron. Drift saat ini adalah 17 detik

Bisakah saya mengecualikan satu pekerja dan tidak menurunkan seluruh sistem?

Saya percaya bahwa baris berikut adalah pelakunya:

https://github.com/celery/celery/blob/def92d580fe7a2c42fcc5f47feed802fd6f7ff48/celery/utils/timeutils.py#L359

Menurut dokumentasi Python, time.daylight bukan nol jika DST didefinisikan:

https://docs.python.org/2/library/time.html#time.daylight

Namun, Seledri memperlakukan nilai itu seolah-olah itu berarti apakah waktu lokal saat ini adalah waktu musim panas atau waktu standar. Saya memiliki mesin yang disetel ke zona waktu Amerika/New_York sekarang dan time.daylight mengembalikan 1 meskipun saat ini kita berada di EST bukan EDT. Ini menyebabkan metode utcoffset() dimatikan satu kali di musim dingin di sini, yang menyebabkan adjust_timestamp salah satu jam.

Untuk memperbaikinya, saya sarankan untuk menghentikan penggunaan waktu lokal di mana saja di Celery dan gunakan UTC hanya untuk semua stempel waktu. Saya percaya ini akan sangat menyederhanakan banyak hal!

Tangkapan yang bagus @rbarlow .
Saya sepenuhnya setuju dengan hanya menggunakan UTC. Ini membantu untuk memiliki sesuatu yang konstan ketika berhadapan dengan target bergerak seperti waktu (bahkan ketika itu hanya offset zona waktu). Saya berurusan dengan informasi lalu lintas yang dibuat dan diproses di beberapa zona waktu dan tanpa menyimpan stempel waktu di UTC, itu akan menjadi kekacauan besar.
Di sisi lain, seseorang harus menyelami kode untuk melakukan itu dan ini bisa menjadi pekerjaan yang menantang (mungkin menghasilkan solusi kerja yang lebih baik yang ditulis dalam lebih sedikit baris kode).

Saya percaya ini telah diperbaiki oleh https://github.com/celery/celery/commit/85fbe12567eeb6e675c4ca0af963c199cdc2793e

Dan tambalan ini adalah bagian dari 3.1.20, jadi silakan coba tingkatkan :)

Acara sebenarnya tidak menggunakan stempel waktu untuk apa pun selain menampilkan waktu manusia dari acara tersebut, sebagai pemesanan mundur, jadi saya hanya mencoba menemukan solusi kompatibel ke belakang paling sederhana yang dapat saya temukan.

Menggunakan pytz/datetime menambahkan banyak overhead yang merupakan masalah ketika kami harus memproses 4 kali lebih banyak peristiwa, karena ada tugas di cluster.

Pada 3.1.20 saya terkadang mendapatkan misalnya Substantial drift from celery<strong i="5">@saver</strong> may mean clocks are out of sync. Current drift is 17 seconds. [orig: 2016-03-02 20:31:10.494412 recv: 2016-03-02 20:30:53.695555] juga (seperti pada 3.1.19). Zona waktu tuan rumah adalah UTC. ntp diinstal dan ntpdate -q pool.ntp.org menunjukkan offset 0.002794 sec

saya juga ! @terisi +1

@ask Ini tidak akan hilang ya?

menambahkan,

USE_TZ = False
TIME_ZONE = 'Asia/Kolkata'

ke pengaturan Django dan menambahkan,
CELERY_TIMEZONE = 'Asia/Kolkata'
kemudian restart seledri dan uwsgi, selesaikan masalah untuk saya

Tidak masalah jika jam disinkronkan oleh NTP sebenarnya. Pergeseran jam didasarkan pada stempel waktu dalam pesan, dan waktu kami menerimanya.

Jadi jika pekerja tidak dapat mengikuti peristiwa tersebut, dan memprosesnya terlambat, peringatan penyimpangan akan dihasilkan.

Anda harus mengatur pengaturan CELERY_EVENT_QUEUE_TTL, CELERY_EVENT_QUEUE_EXPIRES untuk menghindari ini (ini akan diaktifkan secara default di 4.0)

Kami juga melihat ini terjadi hari ini dengan seledri versi 3.1.23 !!!
seledri (3.1.23)

25-01-2017 11:36:07,506: PERINGATAN/Proses Utama] Penyimpangan substansial dari [email protected] mungkin berarti jam tidak sinkron. Penyimpangan saat ini adalah
842 detik. [asal: 25-01-2017 11:36:07.015840 penerimaan: 25-01-2017 11:22:05.133577]

Udah coba upgrade ke 4.x?

Saya memiliki masalah yang sama, tetapi mengubah $ celery flower menjadi $ celery proj flower memperbaikinya.

Hai,
Saya memiliki masalah yang sama sayangnya ...

Versi seledri: 4.0.2
Versi Django: 1.10.6

USE_TZ = True
TIME_ZONE = 'Israel'
enable_utc = True
timezone = 'Israel'

[2017-06-21 14:52:59,483: WARNING/MainProcess] Substantial drift from celery@2fcd73b4-6bf3-4f39-8e8b-f157d4548bf5 may mean clocks are out of sync. Current drift is 10800 seconds. [orig: 2017-06-21 14:52:59.483377 recv: 2017-06-21 17:52:59.470257]

@maxandron Informasi yang diberikan tidak cukup untuk men-debug masalah ini. Harap buka masalah baru dengan informasi yang diperlukan bagi kami untuk men-debug masalah ini.

@thedrow Terima kasih atas jawabannya, informasi seperti apa yang akan membantu?

@maxandron Lihat daftar periksa saat membuka edisi baru.
Juga, harap sertakan konfigurasi ntpd yang Anda miliki.

Saya mendapat peringatan ini dan tidak dapat memperbaiki dengan mengatur zona waktu, akhirnya saya menemukan bahwa saya hanya me-restart pekerja tetapi tidak me-restart aplikasi web ...

Tidak masalah jika jam disinkronkan oleh NTP sebenarnya. Pergeseran jam didasarkan pada stempel waktu dalam pesan, dan waktu kami menerimanya.

Jadi jika pekerja tidak dapat mengikuti peristiwa tersebut, dan memprosesnya terlambat, peringatan penyimpangan akan dihasilkan.

Anda harus mengatur pengaturan CELERY_EVENT_QUEUE_TTL, CELERY_EVENT_QUEUE_EXPIRES untuk menghindari ini (ini akan diaktifkan secara default di 4.0)

@tanya . Bagaimana memastikan bahwa pekerja dapat mengikuti acara tersebut? Ini terjadi pada saya ketika saya menskalakan pekerja saya ke 100 dan lebih tinggi.. Haruskah saya meningkatkan sumber daya RabbitMQ saya yang berfungsi sebagai perantara pada pekerja seledri saya?

Saya menggunakan seledri 4.2.0

Silakan gunakan milis, IRC atau stack overflow untuk pertanyaan seperti itu.