Dieser lästigste Fehler ist immer noch bei uns. Könntest du mir Anweisungen geben, um das Problem zu beheben?
Leider stoßen wir von Zeit zu Zeit immer noch auf dieses Problem. Ich habe einige Daten zu einem kürzlichen Vorfall gesammelt, bei dem das Verschieben von 27 Beiträgen in ein bestehendes Thema (2013 Beiträge) fehlgeschlagen ist:
Beginning move at 2021-05-25 20:54:57 +0000
create_temp_table
0.000134 0.000027 0.000161 ( 0.002810)
delete_invalid_post_timings
0.000317 0.000065 0.000382 ( 0.306869)
move_incoming_emails
0.000056 0.000006 0.000062 ( 0.000478)
move_notifications
0.000074 0.000008 0.000082 ( 0.005584)
update_reply_counts
0.000088 0.000010 0.000098 ( 0.001058)
update_quotes
0.000079 0.000008 0.000087 ( 0.002426)
move_first_post_replies
0.000071 0.000008 0.000079 ( 0.000695)
delete_post_replies
0.000062 0.000006 0.000068 ( 0.000834)
copy_first_post_timings
0.000064 0.000007 0.000071 ( 0.002660)
move_post_timings
0.000082 0.000009 0.000091 ( 0.008195)
copy_topic_users
0.000398 0.000043 0.000441 ( 0.043640)
move_each_post
4.345220 0.132652 4.477872 ( 3.447047)
create_moderator_post_in_original_topic
0.163962 0.000253 0.164215 ( 0.207101)
update_statistics
0.217266 0.051660 0.268926 ( 45.258070)
update_user_actions
0.000934 0.000101 0.001035 ( 0.178894)
update_last_post_stats
0.001589 0.000171 0.001760 ( 0.003156)
update_upload_security_status
0.000030 0.000003 0.000033 ( 0.000034)
update_bookmarks
0.000492 0.000054 0.000546 ( 0.003832)
Finished move at 2021-05-25 20:55:47 +0000
Die meisten Methoden sind sehr schnell abgeschlossen, aber update_statistics hat in diesem Fall über 45 Sekunden gedauert. Die gesamte Zeit entfällt auf den folgenden Methodenaufruf:
Vielleicht verschieben wir die update_statistics-Arbeit auf Sidekiq?
Ja, wahrscheinlich. Aber ich werde mir genau ansehen, wie aufwendig es wäre, den gesamten Prozess in einen Sidekiq-Job zu verlagern und die Benutzeroberfläche warten zu lassen, bis er abgeschlossen ist. Wir spielen hier gewissermaßen immer wieder ‘Whac-A-Mole’, indem wir ständig einzelne Teile in Jobs auslagern.
Vielen Dank für deine harte Arbeit!
Ich erhalte beim Zusammenführen von Themen ebenfalls diesen 502-Fehler. Nicht jedes Mal, aber sehr häufig.
Ich tue dies, wenn jemand ein Thema zu einem bereits bestehenden Thema erstellt hat, also versuche ich in der Regel, nur eine sehr kleine Anzahl von Beiträgen zu verschieben (nicht mehr als fünf).
Ich habe dieses gesamte Thema noch nicht vollständig gelesen, aber ich verstehe, dass dies ein bekanntes Problem ist, an dem ihr arbeitet, und dass ich selbst nichts tun kann?
Ich habe das Problem auf unserem Forum ebenfalls festgestellt. Einige von uns können keine Beiträge bearbeiten und/oder neue Beiträge erstellen. Wir erhalten folgende Fehlermeldung:
Wir haben auch 502er, wenn wir Beiträge verschieben.
Früher trat dies nur gelegentlich auf und Beharrlichkeit funktionierte normalerweise. Aber jetzt haben wir einen Fall, in dem es beim Versuch, einen einzelnen Beitrag in ein relativ langes Thema (2.000 Beiträge) zu verschieben, durchweg fehlschlägt und nach etwa 30 Sekunden abbricht.
Der Server ist zu diesem Zeitpunkt nicht besonders ausgelastet und bewältigt die restliche Aktivität problemlos. Der Versuch, den Beitrag bei geringer Aktivität zu verschieben, führt zum gleichen Ergebnis. Kein Unterschied im abgesicherten Modus.
Gibt es außer der Stärkung der Instanz (angenommen, das ist eine Lösung dafür?) noch etwas, das wir versuchen könnten? Gerne stellen wir weitere Informationen zur Verfügung, falls diese nützlich sind. Erwähnenswert ist, dass ich auf der neuesten stabilen Version bin – ich würde auf die neueste Betaversion wechseln, wenn es dafür kürzliche Änderungen gibt.
Am Wochenende (unsere langsamste Periode) haben wir unseren maximalen Speicher-IOPS vorübergehend verdreifacht und dann auch den maximalen Durchsatz verdreifacht und können trotzdem keinen einzigen Beitrag in das bestehende Thema mit 2.000 Beiträgen verschieben.
Das Hinterlassen einer neuen Antwort im Thema selbst scheint kein Problem zu sein, daher vermute ich, dass beim Verschieben eines Beitrags von irgendwoher, anstatt ihn neu zu erstellen, viel mehr zusätzliche Arbeit erforderlich ist. Wenn es nicht unter 30 Sekunden erledigt werden kann, sollte es vielleicht über einen Hintergrundauftrag erledigt werden, anstatt mit der Meldung „502 Fehler“ fehlzuschlagen?
Ja, das passiert mir auch bei alten und langen Themen mit über 3000 Beiträgen.
Es ist immer noch schmerzhaft.
Hallo
Ich habe ein ähnliches Problem, bei dem ich ein Thema mit all seinen Antworten nicht in einen anderen Thema-Beitrag zusammenführen kann. Das Thema, zu dem ich zusammenführe, hat 23 Beiträge und das Thema, das ich verschiebe, hat nur 4 Beiträge.
|
Fehlerprotokoll
Message (4 copies reported)
Failed to process hijacked response correctly : PG::UniqueViolation : ERROR: duplicate key value violates unique constraint "post_timings_unique"
DETAIL: Key (topic_id, post_number, user_id)=(62975, 19, 538) already exists.
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/patches/db/pg.rb:110:in `exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/patches/db/pg.rb:110:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/postgres/connection.rb:217:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `block in run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `block in with_lock'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `with_lock'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `run'
/var/www/discourse/lib/mini_sql_multisite_connection.rb:109:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/postgres/connection.rb:196:in `exec'
/var/www/discourse/app/models/post_mover.rb:517:in `move_post_timings'
/var/www/discourse/app/models/post_mover.rb:142:in `handle_moved_references'
/var/www/discourse/app/models/post_mover.rb:112:in `move_posts_to'
/var/www/discourse/app/models/post_mover.rb:35:in `block in to_topic'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/transaction.rb:616:in `block in within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/transaction.rb:613:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:361:in `transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/transactions.rb:234:in `block in transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:415:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_handling.rb:296:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/transactions.rb:233:in `transaction'
/var/www/discourse/app/models/post_mover.rb:35:in `to_topic'
/var/www/discourse/app/models/topic.rb:1308:in `move_posts'
/var/www/discourse/app/controllers/topics_controller.rb:883:in `block in merge_topic'
/var/www/discourse/lib/hijack.rb:64:in `instance_eval'
/var/www/discourse/lib/hijack.rb:64:in `block in hijack'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:911:in `callback_on_resolution'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:797:in `call_callback'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:803:in `call_callbacks'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:692:in `resolve_with'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:1325:in `resolve'
/var/www/discourse/lib/scheduler/defer.rb:125:in `block in do_work'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/lib/scheduler/defer.rb:119:in `do_work'
/var/www/discourse/lib/scheduler/defer.rb:105:in `block (2 levels) in start_thread'
Hinweis: Mir ist aufgefallen, dass im Fehler steht bereits vorhanden, aber es handelt sich tatsächlich um separate Themen. Ich weiß nicht, ob es damit zusammenhängt, aber bevor dieser Fehler auftrat, habe ich mehrere Themen und ihre Beiträge in das Thema mit den 23 Beiträgen verschoben, in das ich dieses hier zusammenführen möchte (wie ich es auch bei anderen Themen getan habe).
Danke!
Haben Sie in den letzten Tagen ein Update durchgeführt? Es gab kürzlich eine Korrektur bezüglich des Verschiebens von Beiträgen