GW2Wiki:Fehlermeldungen/Archiv1
Dieses Archiv enthält Diskussionen, die im folgenden Zeitraum abgeschlossen wurden: bis Februar 2013 |
Aktuelle 502/503-Fehlermeldungen[Bearbeiten]
Bitte schreibt hier immer, mit möglichst genauer Uhrzeit, wenn ihr mitbekommt, dass das Wiki nicht funktioniert hat. Auch wenn es bereits einen Eintrag zur ungefähren Uhrzeit gibt, tragt euch hier ein, damit wir sehen können, ob es möglicherweise auf einige Benutzer beschränkt ist.
Feb 3, 2013 | 12:05 - 12:15 | 13:03 - 13:12 | ~16:15 | 17:04 - 17:08 | 20:24 - 20:40 | 20:58 - 21:00 | 21:21 - 21:26 | 22:05-22:27 |
---|
3. Februar 2013[Bearbeiten]
- 12:05-12:15h
- --Think 12:21, 3. Feb. 2013 (CET)
- ebenso --Tancred 12:36, 3. Feb. 2013 (CET)
- Das könnte von mir durch purgen der laufenden Diskussionen ausgelöst worden sein. Bisher hat das zwar nicht den ganzen Server mitgerissen, sondern konnte dann nur die Seite selbst nicht anzeigen, zeitlich würde es aber passen. --Hraun 12:46, 3. Feb. 2013 (CET)
- Denke, da hatte ich es auch. -- 12:52, 3. Feb. 2013 (CET)
- Ich hab noch ein paar andere Zeitangaben: Samstag gegen 17 Uhr, Freitag gegen 23 Uhr. Wenn da auch jemand die Liste aktualisiert hat, könnte man zumindest mal wissen, dass man damit einen Absturz provozieren kann. Theoretisch dürfte das aber auch nicht immer passieren. --Think 12:55, 3. Feb. 2013 (CET)
- Gestern im Laufe des Tages auch 3-4 mal. Das mit dem purgen der Diskussionsseite ist mir auch schon aufgefallen. Habe das seit Dezember ca. 6 mal gemacht und jedes Mal schmierte der Server ab. Am Anfang hielt ich es für einen Zufall, bis ich den Zusammenhang erkannte (was ich dir damals auch mitteilte) --Grinhorn 12:57, 3. Feb. 2013 (CET)
- Jep, ich hatte das damals auch schonmal weitergegeben zur weiteren Untersuchung, aber da ist nichts großes bei rausgekommen. Jetzt will ich das bisschen ausführlicher machen, weil es doch sehr gehäuft mittlerweile jeden Tag auftritt... --Think 12:59, 3. Feb. 2013 (CET)
- Ich würde vorerst den Link zum manuellen Purgen erstmal rausnehmen. Vielleicht schafft das ja schon Abhilfe. --Grinhorn 13:00, 3. Feb. 2013 (CET)
- Hm ja. Davon stürzt das Wiki tatsächlich ab. Was für ein Spaß, DPL ist wahrscheinlich brutal schlecht auf größere Datenbanken ausgelegt. --Think 13:12, 3. Feb. 2013 (CET)
- Wiki1 cached das allerdings nicht mal, und trotzdem gab es damit dort noch nie Probleme, egal was im Wiki gerade los war. --Hraun 16:47, 3. Feb. 2013 (CET)
- Genau das hab ich auch vorhin überlegt. Eigentlich sollten diese Abfragen immer noch absolut kein Problem für das Wiki sein, wir haben in der Summe grade mal ~100k Versionen in der DB, und darüber wird noch nicht mal abgefragt. Ich habe mal gefragt, ob man mir nicht ein SQL-Dump geben kann, um mal selbst ein paar Tests zu machen. --Think 16:53, 3. Feb. 2013 (CET)
- Ich habe mittlerweile notlastmodifiedby im Verdacht, was auch gut auch erklären würde, warum es nur hier Probleme gibt (hoffe Wiki1 erholt sich schnell wieder vom Test *hust*). Vermutlich können wir die Liste also wieder in Betrieb nehmen, wenn wir den Willkommensbot bei den Benutzerdiskussionen einfach nicht ausblenden. --Hraun 13:02, 20. Feb. 2013 (CET)
- Was genau hast du gemacht? Nachdem ich ja dort Adminzugang hab, könnte man das Wiki als Livetestobjekt benutzen. Da hing eine Db-Abfrage bei "Sending data" seit 2200 Sekunden. --Think 13:29, 20. Feb. 2013 (CET)
- Komplette Seite zum Bearbeiten geöffnet, beim oberen Abschnitt „notlastmodifiedby = Hraun“ eingefügt und auf Vorschau gegangen. Es hat ewig gedauert, er hat es aber irgendwann angezeigt. Weitere Seitenaufrufe waren danach aber nicht mehr möglich, es kam nur noch ein 504. --Hraun 18:49, 20. Feb. 2013 (CET)
- Hab mir grade mal einen EXPLAIN auf diese Abfrage anzeigen lassen. Da wird eine ziemlich schrottige Unterabfrage für den Autor der letzten Version der Seite gemacht, die einen kompletten Indexscan der Versionstabelle (aktuell 100k Einträge) für jeden einzelnen Artikel durchführt. Die Abfrage ohne notlastmodifedby hat diesen Indexscan nicht... könnte also tatsächlich ein Grund sein. --Think 18:58, 20. Feb. 2013 (CET)
- Komplette Seite zum Bearbeiten geöffnet, beim oberen Abschnitt „notlastmodifiedby = Hraun“ eingefügt und auf Vorschau gegangen. Es hat ewig gedauert, er hat es aber irgendwann angezeigt. Weitere Seitenaufrufe waren danach aber nicht mehr möglich, es kam nur noch ein 504. --Hraun 18:49, 20. Feb. 2013 (CET)
- Was genau hast du gemacht? Nachdem ich ja dort Adminzugang hab, könnte man das Wiki als Livetestobjekt benutzen. Da hing eine Db-Abfrage bei "Sending data" seit 2200 Sekunden. --Think 13:29, 20. Feb. 2013 (CET)
- Ich habe mittlerweile notlastmodifiedby im Verdacht, was auch gut auch erklären würde, warum es nur hier Probleme gibt (hoffe Wiki1 erholt sich schnell wieder vom Test *hust*). Vermutlich können wir die Liste also wieder in Betrieb nehmen, wenn wir den Willkommensbot bei den Benutzerdiskussionen einfach nicht ausblenden. --Hraun 13:02, 20. Feb. 2013 (CET)
- Genau das hab ich auch vorhin überlegt. Eigentlich sollten diese Abfragen immer noch absolut kein Problem für das Wiki sein, wir haben in der Summe grade mal ~100k Versionen in der DB, und darüber wird noch nicht mal abgefragt. Ich habe mal gefragt, ob man mir nicht ein SQL-Dump geben kann, um mal selbst ein paar Tests zu machen. --Think 16:53, 3. Feb. 2013 (CET)
- Wiki1 cached das allerdings nicht mal, und trotzdem gab es damit dort noch nie Probleme, egal was im Wiki gerade los war. --Hraun 16:47, 3. Feb. 2013 (CET)
- Hm ja. Davon stürzt das Wiki tatsächlich ab. Was für ein Spaß, DPL ist wahrscheinlich brutal schlecht auf größere Datenbanken ausgelegt. --Think 13:12, 3. Feb. 2013 (CET)
- Ich würde vorerst den Link zum manuellen Purgen erstmal rausnehmen. Vielleicht schafft das ja schon Abhilfe. --Grinhorn 13:00, 3. Feb. 2013 (CET)
- Jep, ich hatte das damals auch schonmal weitergegeben zur weiteren Untersuchung, aber da ist nichts großes bei rausgekommen. Jetzt will ich das bisschen ausführlicher machen, weil es doch sehr gehäuft mittlerweile jeden Tag auftritt... --Think 12:59, 3. Feb. 2013 (CET)
- Gestern im Laufe des Tages auch 3-4 mal. Das mit dem purgen der Diskussionsseite ist mir auch schon aufgefallen. Habe das seit Dezember ca. 6 mal gemacht und jedes Mal schmierte der Server ab. Am Anfang hielt ich es für einen Zufall, bis ich den Zusammenhang erkannte (was ich dir damals auch mitteilte) --Grinhorn 12:57, 3. Feb. 2013 (CET)
- Ich hab noch ein paar andere Zeitangaben: Samstag gegen 17 Uhr, Freitag gegen 23 Uhr. Wenn da auch jemand die Liste aktualisiert hat, könnte man zumindest mal wissen, dass man damit einen Absturz provozieren kann. Theoretisch dürfte das aber auch nicht immer passieren. --Think 12:55, 3. Feb. 2013 (CET)
- Denke, da hatte ich es auch. -- 12:52, 3. Feb. 2013 (CET)
- Das könnte von mir durch purgen der laufenden Diskussionen ausgelöst worden sein. Bisher hat das zwar nicht den ganzen Server mitgerissen, sondern konnte dann nur die Seite selbst nicht anzeigen, zeitlich würde es aber passen. --Hraun 12:46, 3. Feb. 2013 (CET)
- ebenso --Tancred 12:36, 3. Feb. 2013 (CET)
- Neue Downtime 13:03 - 13:12 - Laufende Diskussionen wurden wieder von jemandem gepurged --Grinhorn 13:13, 3. Feb. 2013 (CET)
- Ich wars (schäm), hab gerade nochmal getestet. Habe 12:05 und gerade eben die Gegend neu geladen.-- 13:15, 3. Feb. 2013 (CET)
- Na großartig. Also führt sowohl größere DPL-Abfrage als auch größere SMW-Abfragen zu Serverabstürzen. Bei DPL kann man ja das SQL schnell anzeigen, was da ausgeführt wird, sieht schonmal sehr unschön aus, bei SMW hab ich allerdings keine Ahnung. --Think 13:18, 3. Feb. 2013 (CET)
- Wie gesagt, ich würde als akute Zwischenlösung erstmal vorschlagen, den Link zu entfernen, bevor noch mehr auf die Idee kommen zu "testen", ob das wirklich das Wiki zum Abstürzen bringt ;) Vielleicht sogar die Versions-History löschen. --Grinhorn 13:27, 3. Feb. 2013 (CET)
- Löschen des Links reicht denke ich. --Think 13:38, 3. Feb. 2013 (CET)
- Wie gesagt, ich würde als akute Zwischenlösung erstmal vorschlagen, den Link zu entfernen, bevor noch mehr auf die Idee kommen zu "testen", ob das wirklich das Wiki zum Abstürzen bringt ;) Vielleicht sogar die Versions-History löschen. --Grinhorn 13:27, 3. Feb. 2013 (CET)
- Na großartig. Also führt sowohl größere DPL-Abfrage als auch größere SMW-Abfragen zu Serverabstürzen. Bei DPL kann man ja das SQL schnell anzeigen, was da ausgeführt wird, sieht schonmal sehr unschön aus, bei SMW hab ich allerdings keine Ahnung. --Think 13:18, 3. Feb. 2013 (CET)
- Neue Downtime 13:22 - 13:27 - diesmal andere Ursache - kein Purge der letzten Diskussionen - gleichzeitig waren auch andere Wikis betroffen. Vielleicht führt jemand grade massiv SMW-Sabotage-Abfragen durch --Grinhorn 13:29, 3. Feb. 2013 (CET)
- Hatte das heute noch nicht, aber immer wenn ich Seiten purge die da ein bisschen länger brauchen, lege ich das Wiki lahm, und das schon seit Monaten. Mein Bot, den ich häufig auf einem anderen Rechner laufen lasse, bekam dann genauso wie mein Rechner auch immer nur 502 Fehler. 503 Fehler hatte ich aber gestern zum ersten mal. --Darthmaim (Diskussion • Beiträge) 15:39, 3. Feb. 2013 (CET)
- Neue Downtime: ~16:15 Uhr und drumherum - Diskussions-Purge --Grinhorn 16:20, 3. Feb. 2013 (CET)
- Neue Downtime: 17:04 - 17:08 Es war nicht die "laufende Diskussionsliste" -- 17:08, 3. Feb. 2013 (CET)
- Neue Downtime: 20:24 - 20:40 Diesmal wieder die Diskussionen... schienen mehrere Abfragen gewesen zu sein - zwischenzeitlich war die Seite für einige Sekunden erreichbar und 502 und 503 wechselten sich ab. --Grinhorn 20:41, 3. Feb. 2013 (CET)
- Ich schmeiß den Link raus und ändere auch mal eine Kleinigkeit bei der Abfrage. -- 20:44, 3. Feb. 2013 (CET)
- Korrigiere: Man kann die Seite nicht vernünftig abändern, weil sie bei der Änderung abschmiert. Das Wiki wird zwar nicht komplett mitgerissen, aber die Änderung kommt nicht durch. Ich schau mal nachher, ob man das mit Löschungen oder sowas umgehen kann, aber dafür eignet sich die Nacht mit weniger Aktivität mehr. -- 20:54, 3. Feb. 2013 (CET)
- Korrigiere erneut: Der Änderungsversuch von vorhin ist nach einer Ewigkeit doch durchgesickert. -- 21:02, 3. Feb. 2013 (CET)
- dito - wollte mir gerade beobachtete Diskussionen ansehen bzw. diese Fehlermeldungsseite... --Pinewood 21:06, 3. Feb. 2013 (CET)
- Neue Downtime: 21:21 - 21:26 langsam fängts an zu nerven...und die Diskussionsliste hat wieder jemand neu generiert...--Grinhorn 21:27, 3. Feb. 2013 (CET)
- Und direkt nochmal von 21:27-21:32 - ich fürchte da macht sich jemand nen Spaß draus --Grinhorn 21:32, 3. Feb. 2013 (CET)
- Ich war höchstwahrscheinlich das erste Mal. Die These die sich dadurch bestätigt hat, war, dass die limit-Begrenzungen überhaupt nichts bringen. Technischer Hintergrund: LIMIT wird in DB-Abfragen meist erst am Ende ausgeführt, wenn die DB-Abfrage ohne LIMIT schon im Speicher geladen ist. Das Limit selbst trägt also nichts zur Performance bei, wenn es ganz außen ist. Wer sich mit SQL auskennt, kann mal
debug = 6
in die DPL-Abfragen schreiben und sich das SQL ansehen, was die unterschiedlichen limit-Einträge ändert. Dann sieht man das nahezu alles gleich bleibt. --Think 21:36, 3. Feb. 2013 (CET)- kann ich bestätigen (die Downtime) - ging bei mir danach weiter nicht von 21:28 - 21:30 und 21:32 - 21:36 - wollte nur diesen Kommentar verfassen... --Pinewood 21:38, 3. Feb. 2013 (CET)
- Ich war höchstwahrscheinlich das erste Mal. Die These die sich dadurch bestätigt hat, war, dass die limit-Begrenzungen überhaupt nichts bringen. Technischer Hintergrund: LIMIT wird in DB-Abfragen meist erst am Ende ausgeführt, wenn die DB-Abfrage ohne LIMIT schon im Speicher geladen ist. Das Limit selbst trägt also nichts zur Performance bei, wenn es ganz außen ist. Wer sich mit SQL auskennt, kann mal
- Neue Downtime: 21:48-21:59 - Falls das auf irgendwelche Tests zurückzuführen sein sollte, würde ich vorschlagen, diese doch auf eine spätere Stunde zu verlegen--Grinhorn 21:59, 3. Feb. 2013 (CET)
- Also ich habe keine Tests gemacht. Zwischendurch um 21:50 konnte ich einmal die Seite neu laden, dann gings weiter bis grad eben. --Darthmaim (Diskussion • Beiträge) 22:02, 3. Feb. 2013 (CET)
- Neue Downtime: 22:19-22:26 - So in etwa oder etwas früher. --Dusk 22:28, 3. Feb. 2013 (CET)
- Neue Downtime: 22:05-22:27 - Eventuell hat sie das Dingen selber aktulisiert. Alle Wikis (en,fr,es,de) waren Down. Ich weiß allerdings nicht, ob die ganze Zeit auch die anderen Wiki down waren. -- 22:29, 3. Feb. 2013 (CET)
- Jederzeit reproduzierbar - Siehe: Waidmann -> edit -> preview (oder jede andere Seite, die viele Queries verursacht). Habe ich dort auch schon vor knapp 4 Monaten vermerkt ;) --Smiley™ 08:45, 4. Feb. 2013 (CET)
- Ich gebe das heute mal weiter, das kann es ja eigentlich nicht sein, dass jedes mal der Server abstürzt, bei dieser Art von Anfragen... --Think 09:28, 4. Feb. 2013 (CET)
- Naja, ist die Frage, ob es ein Fehler oder möglicherweise ein Schutz gegen DoS ist... Ein Fehler sollte ja (theoretisch) einen 503 liefern. Hier übrigens der aktuelle Link zu der Meldung im englischen Wiki: en:Guild Wars 2 Wiki:Reporting wiki bugs/archive 2#502 error only with select pages €: Ist natürlich möglich, dass intern eine nicht verwertbare Antwort vom Webserver kommt, und das so zum 502 auf dem Proxy führt... --Smiley™ 12:55, 4. Feb. 2013 (CET)
- Ein Schutz vor DoS, durch den der Server nach so einer Anfrage erst mal allen den Dienst verweigert? Das erinnert stark an die Piraten bei Asterix. --Hraun 13:20, 4. Feb. 2013 (CET)
- Bei der Informationspolitik von Anet kann man ja nur Mutmaßen... Fakt ist: der 502 betrifft nicht nur die Wikis, sondern auch die Website/Foren und ist schon seit (mindestens) einem halben Jahr bekannt - und bis heute wurde weder etwas dazu gesagt, noch getan. --Smiley™ 13:41, 4. Feb. 2013 (CET)
- Der 502 ist einfach nur der Fehler, der auftritt, wenn denen ihr Application Server abgestürzt ist. Das kommt meist bei Überlastung vor, was wir ja auch relativ eindeutig über DPL auslösen können. Warum genau der Server dabei abstürzt (es ist eigentlich keine sehr teure Anfrage), kann nur die Technik von ArenaNet sagen. Wir habe einen direkten Ansprechpartner (Benutzer:Stéphane Lo Presti), der unsere Anfragen auch bearbeitet und sie an den Serveradmin weitergibt (das ist jemand anderes, um genau zu sein Benutzer:Justin Lloyd). Das Wiki läuft nun mal nicht auf einem kleinen Homeserver, sondern auf einer etwas größeren Serverarchitektur. Ich mache da schon Druck, weil es mich auch mehr als nur nervt, und sehr wundert, warum das Wiki bei solchen Dingen abstürzt. Achso: 503 kommt vom Varnish-Cacheserver, der einfach nur vor dem Appserver hängt, und entsprechend den gateway timeout wirft, wenn der ihm nicht antwortet.--Think 13:46, 4. Feb. 2013 (CET)
- Bei der Informationspolitik von Anet kann man ja nur Mutmaßen... Fakt ist: der 502 betrifft nicht nur die Wikis, sondern auch die Website/Foren und ist schon seit (mindestens) einem halben Jahr bekannt - und bis heute wurde weder etwas dazu gesagt, noch getan. --Smiley™ 13:41, 4. Feb. 2013 (CET)
- Ein Schutz vor DoS, durch den der Server nach so einer Anfrage erst mal allen den Dienst verweigert? Das erinnert stark an die Piraten bei Asterix. --Hraun 13:20, 4. Feb. 2013 (CET)
- Naja, ist die Frage, ob es ein Fehler oder möglicherweise ein Schutz gegen DoS ist... Ein Fehler sollte ja (theoretisch) einen 503 liefern. Hier übrigens der aktuelle Link zu der Meldung im englischen Wiki: en:Guild Wars 2 Wiki:Reporting wiki bugs/archive 2#502 error only with select pages €: Ist natürlich möglich, dass intern eine nicht verwertbare Antwort vom Webserver kommt, und das so zum 502 auf dem Proxy führt... --Smiley™ 12:55, 4. Feb. 2013 (CET)
7. Februar 2013[Bearbeiten]
- New Downtime: 07:15-07:21 --Grinhorn 07:29, 7. Feb. 2013 (CET)
- 07:38 Falls das in diesen Abschnitt nicht passt mal verschieben. Jedenfalls soweit funktioniert das Wiki im Moment, aber reproduzierbar beim angucken der Änderungen an der Laufenden Diskussionsseite gibts bei dieser Änderung von Think einen 502 Fehler. Alles davor und danach und drumrum geht derweil, nur diese Änderung ist nicht ansehbar ohne Fehlermeldung.--Dusk 07:49, 7. Feb. 2013 (CET)
- 07:53 kurze downtime --Grinhorn 07:56, 7. Feb. 2013 (CET)
- '07:57-08:02 und mit Absenden des letzten Beitrags direkt eine längere. --Grinhorn
- Downtime 07:50-08:02 und 08:04-08:10 Bei mir die 502 Downtime etwas länger. Mein Submit kam gar nicht durch, auch beim Speichern hier gleich ne neue Downtime...--Dusk 08:10, 7. Feb. 2013 (CET)
- Bitte vermerkt auf welchen Seiten sowas passiert - "kleine" Seiten sollten theoretisch nicht oder nur sporadisch betroffen sein. Problematisch ist es scheinbar vor allem bei Seiten, welche größere SMW- oder DPL-Queries nutzen. --Smiley™ 08:35, 7. Feb. 2013 (CET)
- Hab ich doch beschrieben oO. Oben der Fehler kommt beim betrachten dieser einen Änderung und die anderen beiden Downtimes als ich hier nen Kommentar auf dieser Seite speichern wollte, keine Ahnung was da während der Zeit noch so gemacht wurde von anderen--Dusk 08:56, 7. Feb. 2013 (CET)
- Ah, hab das im falschen Kontext gelesen^^ das Problem hab ich auch schon weiter unten beschrieben ;) --Smiley™ 09:01, 7. Feb. 2013 (CET)
- Hab ich doch beschrieben oO. Oben der Fehler kommt beim betrachten dieser einen Änderung und die anderen beiden Downtimes als ich hier nen Kommentar auf dieser Seite speichern wollte, keine Ahnung was da während der Zeit noch so gemacht wurde von anderen--Dusk 08:56, 7. Feb. 2013 (CET)
8. Februar 2013[Bearbeiten]
11:55 - ca 12:10 Erst 502 dann 503 --Nerankar 12:17, 8. Feb. 2013 (CET)
- Ja, ebenso. Auch die Wikis der anderen Sprachen zeitweise in dem Zeitraum betroffen.--Dusk 12:43, 8. Feb. 2013 (CET)
9. Februar 2013[Bearbeiten]
- Ich hatte grade wieder einen 502. Wann genau das angefangen hat weiß ich leider nicht. Hab das Wiki geöffnet und kurz afk gegangen. Kann es daher nicht eingrenzen, ob es länger war oder nicht. -- 15:54, 9. Feb. 2013 (CET)
- Neue Downtime: 17:19 - 17:29 (Kann auch früher angefangen haben) -- 17:30, 9. Feb. 2013 (CET)
13. Februar 2013[Bearbeiten]
- Bin mir nicht sicher ob das dazugehört, aber mir wurde gerade eben um 21:45 CET ein 502 Fehler im Fenster der Schwarzlöwen-Handelsgesellschaft angezeigt. Der Text der Fehlermeldung lautet: "Web server received an invalid response while acting as a gateway or proxy server. - There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server."
- Hatte jetzt einen 503 kurz vor 22 Uhr. (XID: 879721065 - kA ob das was hilft) --Nachtmahr 22:03, 13. Feb. 2013 (CET)
- Der Handelsposten hat mit diesem Problem vermutlich weniger zu tun. Aber gerade gab es von 21:57 bis 22:02 Uhr eine Downtime mit 502 und 503.--Grinhorn 22:04, 13. Feb. 2013 (CET)
14. Februar 2013[Bearbeiten]
- Downtime von 0:00 (oder auch schon früher) bis mindestens 0:12 --90.136.45.128 01:14, 14. Feb. 2013 (CET)
- Die war extrem lang, oder es waren mehrere kurz nacheinander. Ich würde schätzen bis grob 1:00 gabs 502 und 503 im Wechsel. -- 01:16, 14. Feb. 2013 (CET)
20. Februar 2013[Bearbeiten]
- 18:58~19:03h --Think 19:04, 20. Feb. 2013 (CET)
- Laut Zeitangabe ist diese Downtime wohl wieder auf eine Aktualisierung der letzten Diskussionen zurückzuführen--Grinhorn 19:19, 20. Feb. 2013 (CET)
- Nein, das kann nicht sein, denn das habe ich erst danach gemacht. Vermutlich hat mal wieder jemand gleich testen müssen, was ich oben angegeben hatte. --Hraun 19:21, 20. Feb. 2013 (CET)
- Achso okay. Die Zeit der letzten Aktualisierung wird mit 19:03:02 Uhr angegeben. Beim von Think angegebenen Downtime-Zeitraum bis 19:04 Uhr bin ich davon ausgegangen, dass das dann die Ursache war. --Grinhorn 19:30, 20. Feb. 2013 (CET)
- Gut möglich dass mein Zeitraum um eine Minute falsch war ;) Ich hatte extra mehrfach die Vorschau getestet, als ich die Diskussionsliste wieder reingepackt habe, und es hat problemlos schnell geladen. --Think 20:00, 20. Feb. 2013 (CET)
- Achso okay. Die Zeit der letzten Aktualisierung wird mit 19:03:02 Uhr angegeben. Beim von Think angegebenen Downtime-Zeitraum bis 19:04 Uhr bin ich davon ausgegangen, dass das dann die Ursache war. --Grinhorn 19:30, 20. Feb. 2013 (CET)
- Nein, das kann nicht sein, denn das habe ich erst danach gemacht. Vermutlich hat mal wieder jemand gleich testen müssen, was ich oben angegeben hatte. --Hraun 19:21, 20. Feb. 2013 (CET)
- Laut Zeitangabe ist diese Downtime wohl wieder auf eine Aktualisierung der letzten Diskussionen zurückzuführen--Grinhorn 19:19, 20. Feb. 2013 (CET)
Discussion[Bearbeiten]
- Hi everyone, I just wanted to drop a note here that we're aware of these reports and are investigating. The more information you can provide, the better for our investigation: what page were you editing? Did clearing your browser cache or changing browser solve the issue? How long did the error last? etc. Thanks a lot for your patience and feedback. --Stephane Lo Presti talk 20:23, 5. Feb. 2013 (CET)
- Hey Stephane, thanks for stopping by ;D You can reproduce a 502 any time on pages with multiple large tables like those containing reciepes, see Waidmann -> edit -> preview -> 502. The 502 on the website/forums happened now and then, haven't seen it there for a while now. --Smiley™ 21:16, 5. Feb. 2013 (CET)
- Hi Smiley, thanks for this piece of feedback, I'm forwarding it right away as it's going to be very useful in tracking this behavior. --Stephane Lo Presti talk 21:25, 5. Feb. 2013 (CET)
- Thanks for passing the info. I forgot to say that only uncached pages seem to produce a 502, which means when you preview or purge complex pages with a lot of queries (e.g. automated lists as the example above) --Smiley™ 22:05, 5. Feb. 2013 (CET)
- Hi Smiley, thanks for this piece of feedback, I'm forwarding it right away as it's going to be very useful in tracking this behavior. --Stephane Lo Presti talk 21:25, 5. Feb. 2013 (CET)
- Hey Stephane, thanks for stopping by ;D You can reproduce a 502 any time on pages with multiple large tables like those containing reciepes, see Waidmann -> edit -> preview -> 502. The 502 on the website/forums happened now and then, haven't seen it there for a while now. --Smiley™ 21:16, 5. Feb. 2013 (CET)
- A quick update from me. It's going to be tricky for us to nail down the issue. Nothing in our logs currently points to a systemic error and we can see from our servers what could be causing this behavior. So please keep reporting whenever you experience a 502 or 503 with the maximum amount of information.
Whenever your experience this issue in chrome, please open the "Developer tool" if you're familiar with it and look for any information that would show where the error could be coming from. You can also provide us with the IP address of the web server that sent you the page (in case the issue is one of the webservers). ~SL
- According to the error message it's an internal problem, so we can't provide much information i guess. What i can do is to tell you the request and response headers, so you can crawl your logs on the proxy (ip:64.25.40.16) which answers with a 502 and maybe then find the associated response from your internal webserver (which possibly delivers a truncated response to the proxy).
- So the request headers are:
POST /index.php?title=Waidmann&action=submit HTTP/1.1 Host: wiki-de.guildwars2.com Connection: keep-alive Content-Length: 3453 Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Origin: http://wiki-de.guildwars2.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.45 Safari/537.22 Content-Type: multipart/form-data; boundary=----WebKitFormBoundarymkje1nQYsxzYcvep DNT: 1 Referer: http://wiki-de.guildwars2.com/index.php?title=Waidmann&action=edit Accept-Encoding: gzip,deflate,sdch Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: de_wikidb_gw2_session=f28880120fe858947fdeb809b32289b5;
- (i've cut most the cookie part, but left my session-id from the wiki to help finding that request. No worries, i logged out and back in after that ;)
- The response headers:
HTTP/1.1 502 Bad Gateway Content-Type: text/html Server: Microsoft-IIS/7.5 Date: Wed, 06 Feb 2013 20:30:52 GMT Content-Length: 1477
- Oh, you may want to hide the server type in the response ;) --Smiley™ 21:46, 6. Feb. 2013 (CET)
- Thanks Smiley. Just to confirm: this is what you see when you get a 502 or a 503?--Stephane Lo Presti talk 22:59, 6. Feb. 2013 (CET)
- This is the 502 you get the way i described above. (Waidmann -> edit -> preview/submit) --Smiley™ 23:17, 6. Feb. 2013 (CET)
- I just found out that you'll get also a 502 in the version history when you try to view Think's recent changes (try to go one version back from there) on the page for running discussions - maybe there's a (hidden) hint. I also checked if it's possibly depending on SMW or DPL, but it seems that doesn't matter - AFAIK some of the pages use a mix of both. --Smiley™ 03:09, 7. Feb. 2013 (CET)
- I think most of the problems cased by the running discussions-Page. Everytime it was edited or purged manually (or automaticly) it caused a downtime for about 5 to 10 minutes (examine the listed downtimes above, wich mainly caused by purging this site). Think temporary disabled the DPL request for this site. Since this, we definitively experienced less downtimes and 502s or 503s --Grinhorn 07:29, 7. Feb. 2013 (CET)
- Thanks Smiley. Just to confirm: this is what you see when you get a 502 or a 503?--Stephane Lo Presti talk 22:59, 6. Feb. 2013 (CET)
- Ok, i did some further investigations with my HTTP4e client (see screen) and found something quite interesting, which confims my earlier statement. I took the raw request from chrome which gave me the 502 on submit and put it into the client. This time the server was so kind not to throw a 502 but to reveal the original webserver response which possibly causes the 502 on the proxy because it's content is garbage.
- These were the response headers this time, followed by an 8kb block of gzipped HTML which was completely messed up and incomplete. (btw. your PHP version is quite old, hope that header is just faked ;)
HTTP/1.1 200 OK Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Via: 1.1 varnish Content-Length: 7487 Content-Type: text/html; charset=utf-8 Content-Encoding: gzip Content-Language: de Expires: Thu, 01 Jan 1970 00:00:00 GMT Accept-Ranges: bytes Age: 0 Vary: Accept-Encoding,Cookie Server: Microsoft-IIS/7.5 X-Powered-By: PHP/5.3.10-1ubuntu3.2 X-Varnish: 689164764 X-Powered-By: ARR/2.5 Date: Thu, 07 Feb 2013 08:45:14 GMT
- --Smiley™ 10:30, 7. Feb. 2013 (CET)
- What happens to the server response if you leave out Accept-Encoding in your request to force a clear text reply? --Think 10:55, 7. Feb. 2013 (CET)
- With
Accept-Encoding: identity
i just get the clean response. Btw. scrap that with the original webserver response - the above response is the main page. Anyway, the HTML got somehow messed up and i can also reproduce the 502 on my client now, but i still think that 502 is caused by an encoding error on webserver side. --Smiley™ 11:34, 7. Feb. 2013 (CET)
- With
- What happens to the server response if you leave out Accept-Encoding in your request to force a clear text reply? --Think 10:55, 7. Feb. 2013 (CET)
- --Smiley™ 10:30, 7. Feb. 2013 (CET)
- Thanks for your feedback guys. I'm forwarding this to our technician. We have a discussion about it tomorrow, but I want you to be aware of the fact that one possibility is that we'll have to wait until we update the software stack (MediaWiki, extensions, etc.), just to be sure we don't reintroduce the issue after the updates. Please keep sharing informations about the situation here. Thanks. --Stephane Lo Presti talk 18:50, 7. Feb. 2013 (CET)
- For about when is that software stack planned? -- 18:51, 7. Feb. 2013 (CET)
- We're going to start this month and will hopefully finish next month. I'm not giving hard dates because the schedule may slip, depending on a number of factors.--Stephane Lo Presti talk 18:53, 7. Feb. 2013 (CET)
- For about when is that software stack planned? -- 18:51, 7. Feb. 2013 (CET)
- We're going very soon to make a few changes to test a hypothesis about where the issue is exactly coming from. I'll come back here when we're live with this change (which should be relatively invisible to you, no downtime). Please report any new issue or if the problem seems to be gone. Thanks. --Stephane Lo Presti talk 23:21, 8. Feb. 2013 (CET)
- It's me again :) We've made the changes and can already see that the problem is gone on our side, and we've successfully tested that on reproducable examples we had. Please let us know if it's working for you too. Thanks. --Stephane Lo Presti talk 23:56, 8. Feb. 2013 (CET)
- Doesn't seem to be fixed. I tried this Link: http://wiki-de.guildwars2.com/index.php?title=GW2Wiki:Laufende_Diskussionen&oldid=94398 and got a few 502 and 503 errors.
- It's me again :) We've made the changes and can already see that the problem is gone on our side, and we've successfully tested that on reproducable examples we had. Please let us know if it's working for you too. Thanks. --Stephane Lo Presti talk 23:56, 8. Feb. 2013 (CET)
502
GET /index.php?title=GW2Wiki:Laufende_Diskussionen&oldid=94398 HTTP/1.1 Host: wiki-de.guildwars2.com Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17 Referer: http://wiki-de.guildwars2.com/index.php?title=GW2Wiki:Laufende_Diskussionen&diff=94400&oldid=94398 Accept-Encoding: gzip,deflate,sdch Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: [...] HTTP/1.1 502 Bad Gateway Content-Type: text/html Server: Microsoft-IIS/7.5 Date: Fri, 08 Feb 2013 23:32:06 GMT Content-Length: 1477
503 (on recent changes, while the other page was loading)
GET /wiki/Spezial:Letzte_%C3%84nderungen HTTP/1.1 Host: wiki-de.guildwars2.com Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17 Accept-Encoding: gzip,deflate,sdch Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: [...] HTTP/1.1 503 Service Unavailable Via: 1.1 varnish Content-Length: 418 Content-Type: text/html; charset=utf-8 Accept-Ranges: bytes Age: 1 Retry-After: 5 Server: Microsoft-IIS/7.5 X-Varnish: 700203047 X-Powered-By: ARR/2.5 Date: Fri, 08 Feb 2013 23:35:38 GMT
- --Darthmaim (Diskussion • Beiträge) 00:36, 9. Feb. 2013 (CET)
- Thanks for the feedback! Now that our current hypothesis is proven wrong, we've assessed our options and decided that our best route of action was to monitor the situation and examine the situation after we've update MediaWiki to version 1.20. Once the update is done, this will be the first thing we'll do (unless something more important shows up). Please keep accumulating data about this issue, so that I can assess the level of collective inconvenience it causes. If I see that it's disrupting a high amount of work, we'll consider looking into it again (before completing the update). Thanks. --Stephane Lo Presti talk 01:54, 9. Feb. 2013 (CET)
- I can confirm that the version tracking still gives a 502 but the funny thing is that Waidmann -> edit -> preview/submit works now. (and i got a 502 while updating this page...) --Smiley™ 02:05, 9. Feb. 2013 (CET)
- In case only our few heavy problem candidates remain, I think we can leave those lists disabled for a while. If necessary we can even hide the critical versions, so people don't produce 502/503s, whether by accident or intentional. -- 02:17, 9. Feb. 2013 (CET)
- Just btw: as far as i can see, the page Waidmann is a pure SMW query, while the version tracking shows a pure DPL query which causes an error? Just sayin... --Smiley™ 02:48, 9. Feb. 2013 (CET)
- It's the DPL query from the page history. If you view a diff, it will render that old version (with the DPL query) and cause the wiki to crash. --Think 10:18, 9. Feb. 2013 (CET)
- Corrected the nonsense i posted before. Note to self: don't drink and post. --Smiley™ 19:19, 9. Feb. 2013 (CET)
- Please don't! Bad things could happen ;) --Stephane Lo Presti talk 00:00, 13. Feb. 2013 (CET)
- Corrected the nonsense i posted before. Note to self: don't drink and post. --Smiley™ 19:19, 9. Feb. 2013 (CET)
- It's the DPL query from the page history. If you view a diff, it will render that old version (with the DPL query) and cause the wiki to crash. --Think 10:18, 9. Feb. 2013 (CET)
- Just btw: as far as i can see, the page Waidmann is a pure SMW query, while the version tracking shows a pure DPL query which causes an error? Just sayin... --Smiley™ 02:48, 9. Feb. 2013 (CET)
- In case only our few heavy problem candidates remain, I think we can leave those lists disabled for a while. If necessary we can even hide the critical versions, so people don't produce 502/503s, whether by accident or intentional. -- 02:17, 9. Feb. 2013 (CET)
- I can confirm that the version tracking still gives a 502 but the funny thing is that Waidmann -> edit -> preview/submit works now. (and i got a 502 while updating this page...) --Smiley™ 02:05, 9. Feb. 2013 (CET)
- Thanks for the feedback! Now that our current hypothesis is proven wrong, we've assessed our options and decided that our best route of action was to monitor the situation and examine the situation after we've update MediaWiki to version 1.20. Once the update is done, this will be the first thing we'll do (unless something more important shows up). Please keep accumulating data about this issue, so that I can assess the level of collective inconvenience it causes. If I see that it's disrupting a high amount of work, we'll consider looking into it again (before completing the update). Thanks. --Stephane Lo Presti talk 01:54, 9. Feb. 2013 (CET)
Fehlermeldungen[Bearbeiten]
Der Reiter Beobachten[Bearbeiten]
Ich kann zwar eine Seite beobachten, indem ich ohne etwas zu ändern den Haken beim Abspeichern setze, aber der Reiter bringt mich zu dieser Seite: http://wiki-de.guildwars2.com/wiki/Undefined
Verschieben von Seiten[Bearbeiten]
Laut der Mediawiki-Hilfe, die hier ja auch verlinkt ist, kann jeder angemeldete Benutzer Seiten verschieben (Umbenennen), aber scheinbar ist das eben nicht für alle angemeldeten Benutzer möglich. Das macht es sehr umständlich, die Regions-Artikel auf Vordermann zu bringen, weil sich offensichtlich seit der Beta die Namen einiger Aufgaben geändert haben. Zum Beispiel hießt Dem Schamanen Vigmarr helfen jetzt Ehrt den Geist des Wolfes. Gibt es hier wirklich keine einfachere Möglichkeit, als den gesamten Text zu kopieren, einen neuen Artikel anzulegen und den alten auf einen Redirect zu ändern? --Friedenspanzer 02:20, 30. Aug. 2012 (CEST)
- Das müsste jedem Benutzer zur Verfügung stehen, sobald er die Emailadresse bestätigt hat. -- 03:00, 30. Aug. 2012 (CEST)
- Vollkommen richtig und natürlich mein Fehler, auch wenn ich geschworen hätte, dass ich das habe. --Friedenspanzer 03:46, 30. Aug. 2012 (CEST)
nicht aktuelle Letzte Änderungen[Bearbeiten]
Ich habe gerade gemerkt, dass teilweise unterschiedliche Daten auf der Seite Letzte Änderungen sichtbar sind - ohne irgendwelche Einschränkungen bekomme ich einmal Daten bis 5.2., dann bis 6.2. - damit kann man nicht wirklich gut die aktuellsten Änderungen ansehen. (Der Link "nur Änderungen seit" zeigt dann auf entsprechend veraltete Zeitpunkte: [1] - nach mehrfachem Probieren kommt jetzt der aktuellste Zeitpunkt, ist mir aber in den letzten Tagen immer mal wieder aufgefallen. Hier scheint irgendein Server die Anfrage zu cachen und eine alte Seite auszuliefern. -- User:Pinewood 12:46, 7. Feb. 2013 (CET) (gerade nicht eingeloggt)
- Guck mal hier: en:Guild Wars 2 Wiki:Reporting wiki bugs#Recent changes are 12 hrs out-of-date and getting worse. Vielleicht solltest du einfach mal an der Stelle im Englischen Wiki nochmal von deinem Fehler berichten. --Darthmaim (Diskussion • Beiträge) 13:42, 7. Feb. 2013 (CET)
- Danke für den Hinweis, habe ich dort nochmal geschrieben --Pinewood 19:33, 7. Feb. 2013 (CET)
Benutzung von DIVs in Vorlagen[Bearbeiten]
Die Eigenschaft Vergeltungsschlag des Unterbewusstseins müsste eigentlich folgenden Parameter haben, jedoch entstellt das Markup den Skin.
<div class="infobox-effektliste"> *[[Bild:Kombofeld Icon.png|20px]] Kombofeld: Licht </div>
--Redeemer 19:44, 12. Aug. 2012 (CEST)
- Du meinst, dass in SMW-Attributen die noinclude/includeonly - Tags nicht korrekt interpretiert werden? Oder ein anderes Problem? --Think 21:10, 12. Aug. 2012 (CEST)