Debugging/de
From OpenSimulator
(→Internal tools) |
(→Threadpool Activity) |
||
| (3 intermediate revisions by one user not shown) | |||
| Line 29: | Line 29: | ||
* Util.PrintCallStack() - Damit wird der Call-Stack zum Zeitpunkt druckt das Verfahren vor der Fortsetzung des Ablaufs ausgeführt wird. Leider kann aufgrund Mono Einschränkungen nur für den aktuellen Thread arbeiten. | * Util.PrintCallStack() - Damit wird der Call-Stack zum Zeitpunkt druckt das Verfahren vor der Fortsetzung des Ablaufs ausgeführt wird. Leider kann aufgrund Mono Einschränkungen nur für den aktuellen Thread arbeiten. | ||
| − | = | + | =Spezifische Bereiche= |
| − | + | Allerdings gibt es ein paar Dinge, die wir sagen, über bestimmte Themen Open debuggen. In diesem Abschnitt wird erweitert, wie die Zeit vergeht. | |
| + | == Die erstmalige Verbindung == | ||
| + | Dies stellt die Menschen viel, weil das komplexe Zusammenspiel zwischen den verschiedenen Server-Prozessen in Rastermodus und zwischen Simulator und Betrachter, mit den Zuschauern sowohl auf dem lokalen LAN und über das Internet. Die Probleme sind hier in der Regel aufgrund der Konfiguration statt Open Code Fragen. Siehe [[Troubleshooting]] für weitere Details. | ||
| − | == | + | == Probleme nach der Verbindung == |
| − | + | Hier sind einige Befehle, die Ihnen helfen werden, weitere Informationen zu erhalten, wenn Sie Probleme haben und wenn bereits eine Verbindung hergestellt wurde (zB Avatare an Ort und Stelle zu stoppen), usw. können Sie weitere Hilfe auf einen dieser Befehle erhalten, indem sie "help <command-name>" in der Simulator-Konsole eingeben. | |
| − | + | * debug packet <0-256> [<first-name>] [<last-name>] - dieser Befehl protokolliert verschiedene eingehende und ausgehende Pakete abhängig vom Paketlevel (0-256). Dies kann helfen festzustellen, ob überhaupt ein Paketfluss zwischen Simulator und Client stattfindet. | |
| − | + | ||
| − | * | + | * show queues [<full>] - dieser Befehl zeigt die Statistik der eingehenden, ausgehenden und erneut gesendeten Pakete für bestimmte Clients sowie die in der Warteschlange befindlichen Pakete an. Die Überwachung der Anzahl der eingehenden und ausgehenden Pakete zeigt, ob Pakete zwischen Simulator und Viewer durchkommen. Wenn die Anzahl der erneut gesendeten Pakete schnell ansteigt, deutet dies wahrscheinlich auf Verbindungsprobleme hin, da der Simulator viele Pakete erneut senden muss, die vom Viewer nicht bestätigt werden. Wenn die Q-Zahlen steigen, ohne wieder zu sinken, könnten die Clients extrem geringe Bandbreitenbeschränkungen haben oder die ausgehende Netzwerkverbindung des Simulators könnte überlastet sein. |
| − | * show | + | * show users - zeigt aktive Benutzer auf dem Simulator an |
| − | * show | + | * show connections - zeigt Informationen über einzelne Client-Verbindungen an, einschließlich ihrer IP-Adresse und ob sie aktiv sind (nur im OpenSimulator 0.7.4 Entwicklercode). |
| − | + | == Threadpool-Aktivität == | |
| − | + | Ein Großteil der Arbeit in OpenSim erfolgt in Aufgaben, die auf einem allgemeinen Threadpool ausgeführt werden. Sie können [[General-Purpose Threadpool|Protokollierung aktivieren, die die Aktivität in diesem Threadpool zeigt]]. | |
| − | + | ||
| − | + | ||
== HTTP Activity == | == HTTP Activity == | ||
| − | + | Verwenden Sie diese Konsole Befehl zum Aktivieren der Protokollierung von HTTP-Anfragen und Antworten in OpenSim oder Robust: | |
debug http in|out|all [<level>] | debug http in|out|all [<level>] | ||
| Line 59: | Line 58: | ||
<pre> | <pre> | ||
If in or all and | If in or all and | ||
| − | level <= 0 | + | level <= 0 keine zusätzliche Protokollierung. |
| − | level >= 1 | + | level >= 1 kurze Warnungen protokolliert werden, wenn schlechte Eingangsdaten. |
| − | level >= 2 | + | level >= 2 lange Warnungen protokolliert werden, wenn schlechte Eingangsdaten. |
| − | level >= 3 | + | level >= 3 kurze Hinweise über alle eingehenden nicht-Umfrage HTTP-Anfragen werden protokolliert. |
| − | level >= 4 | + | level >= 4 die Zeit, die Anforderung zu erfüllen protokolliert. |
| − | level >= 5 | + | level >= 5 eine Probe aus dem Anfang der Daten wird protokolliert. |
| − | level >= 6 | + | level >= 6 dann werden die gesamten Daten protokolliert. |
| − | no level | + | no level angegeben wird, dann wird das aktuelle Niveau zurückgeführt. |
If out or all and | If out or all and | ||
| − | level >= 3 | + | level >= 3 kurze Hinweise über alle ausgehenden Anfragen durch WebUtil gehen werden protokolliert. |
| − | level >= 4 | + | level >= 4 die Zeit, die Anforderung zu erfüllen protokolliert. |
| − | level >= 5 | + | level >= 5 eine Probe aus dem Anfang der Daten wird protokolliert. |
| − | level >= 6 | + | level >= 6 dann werden die gesamten Daten protokolliert. |
</pre> | </pre> | ||
| − | + | Insbesondere eine gute Vorstellung von den Kommunikationsfluss wiederum auf Debug-Level 5 sowohl auf dem Simulator zu bekommen und robuste kurze Ausschnitte aus jeder Anforderung und Antwort zu sehen. Dies wird auch HTTP-Anfragen zwischen dem Betrachter und dem Simulator zeigen. | |
| + | |||
[[Category:German Translations]] | [[Category:German Translations]] | ||
Latest revision as of 04:16, 19 July 2024
 |
Languages: |
|
Contents |
[edit] General
Im Allgemeinen ist Open ein schwieriges System aufgrund seiner hohen Parallelität zu debuggen, die Komplexität und der Mangel an guten Werkzeugen für Mono auf der Linux / Mac-Seite. Wir werden nicht durch allgemeine Informationen gehen über Debugger hier verwenden, können Sie es an anderer Stelle im Netz finden können. Allerdings ist eine Sache, zu beachten ist, dass der Debugger ignorieren die SelfDeleteException fähig sein müssen - das derzeit von der xengine Skript-Engine verwendet wird, Skripte über das llDie () LSL-Befehl abgebrochen zu killen.
[edit] Thread Dumps
Wenn der Simulator oder ein Aspekt davon scheint eingefroren zu sein, eine Möglichkeit ist, dass Themen in einer Sackgasse, aus irgendeinem Grund. In diesem Fall kann ein Dump aller Threads nützliche Informationen liefern.
In Mono können Sie diesen Dump erhalten durch das SIGQUIT Unix Signal an den Mono-Prozess sendet. Sie können dies entweder mit STRG + \ auf der Konsole oder durch einen Befehl wie
kill -SIGQUIT <pid>
Dieser Dump kann sehr groß sein. Wenn Sie diese Spur für Debug-Zwecke gemeldet werden, ist es wichtig, dass es genau erfasst und gemeldet wird.
Wenn möglich, bitte Mono mit der debug-Schalter starten, so dass Zeilennummern Spuren hinzugefügt werden (es gibt keine großen Leistungseinbußen über die Verwendung dieser Schalter). Dies ist manchmal der einzige Weg, zu fassen, welche Teile der Code Threads Deadlock auf sein können.
Senden SIGQUIT auf Mono kann es instabil machen. Wenn Sie dies tun, sollten Sie den Prozess in Frage neu zu starten, nachdem alle nützlichen Debug-Informationen erfasst wurde.
Nicht sicher , wie das gleiche Ergebnis auf Windows zu erreichen, wenn dies überhaupt möglich ist . Wenn jemand wäre toll , weiß in diesem Abschnitt gefüllt zu bekommen.
[edit] Interne Tools
Es gibt auch die Anmeldung Aussagen über den Opensimulator-Code, von denen einige auf Kommentar. Im Allgemeinen können diese unkommentiert werden, um zusätzliche nützliche Informationen zur Verfügung zu stellen, wenn Sie das Hinzufügen neuer Protokollanweisungen müssen zurückgreifen kann.
Es gibt auch einige interne Methoden, die nützlich sein könnten.
- Util.PrintCallStack() - Damit wird der Call-Stack zum Zeitpunkt druckt das Verfahren vor der Fortsetzung des Ablaufs ausgeführt wird. Leider kann aufgrund Mono Einschränkungen nur für den aktuellen Thread arbeiten.
[edit] Spezifische Bereiche
Allerdings gibt es ein paar Dinge, die wir sagen, über bestimmte Themen Open debuggen. In diesem Abschnitt wird erweitert, wie die Zeit vergeht.
[edit] Die erstmalige Verbindung
Dies stellt die Menschen viel, weil das komplexe Zusammenspiel zwischen den verschiedenen Server-Prozessen in Rastermodus und zwischen Simulator und Betrachter, mit den Zuschauern sowohl auf dem lokalen LAN und über das Internet. Die Probleme sind hier in der Regel aufgrund der Konfiguration statt Open Code Fragen. Siehe Troubleshooting für weitere Details.
[edit] Probleme nach der Verbindung
Hier sind einige Befehle, die Ihnen helfen werden, weitere Informationen zu erhalten, wenn Sie Probleme haben und wenn bereits eine Verbindung hergestellt wurde (zB Avatare an Ort und Stelle zu stoppen), usw. können Sie weitere Hilfe auf einen dieser Befehle erhalten, indem sie "help <command-name>" in der Simulator-Konsole eingeben.
- debug packet <0-256> [<first-name>] [<last-name>] - dieser Befehl protokolliert verschiedene eingehende und ausgehende Pakete abhängig vom Paketlevel (0-256). Dies kann helfen festzustellen, ob überhaupt ein Paketfluss zwischen Simulator und Client stattfindet.
- show queues [<full>] - dieser Befehl zeigt die Statistik der eingehenden, ausgehenden und erneut gesendeten Pakete für bestimmte Clients sowie die in der Warteschlange befindlichen Pakete an. Die Überwachung der Anzahl der eingehenden und ausgehenden Pakete zeigt, ob Pakete zwischen Simulator und Viewer durchkommen. Wenn die Anzahl der erneut gesendeten Pakete schnell ansteigt, deutet dies wahrscheinlich auf Verbindungsprobleme hin, da der Simulator viele Pakete erneut senden muss, die vom Viewer nicht bestätigt werden. Wenn die Q-Zahlen steigen, ohne wieder zu sinken, könnten die Clients extrem geringe Bandbreitenbeschränkungen haben oder die ausgehende Netzwerkverbindung des Simulators könnte überlastet sein.
- show users - zeigt aktive Benutzer auf dem Simulator an
- show connections - zeigt Informationen über einzelne Client-Verbindungen an, einschließlich ihrer IP-Adresse und ob sie aktiv sind (nur im OpenSimulator 0.7.4 Entwicklercode).
[edit] Threadpool-Aktivität
Ein Großteil der Arbeit in OpenSim erfolgt in Aufgaben, die auf einem allgemeinen Threadpool ausgeführt werden. Sie können Protokollierung aktivieren, die die Aktivität in diesem Threadpool zeigt.
[edit] HTTP Activity
Verwenden Sie diese Konsole Befehl zum Aktivieren der Protokollierung von HTTP-Anfragen und Antworten in OpenSim oder Robust:
debug http in|out|all [<level>]
Options:
If in or all and level <= 0 keine zusätzliche Protokollierung. level >= 1 kurze Warnungen protokolliert werden, wenn schlechte Eingangsdaten. level >= 2 lange Warnungen protokolliert werden, wenn schlechte Eingangsdaten. level >= 3 kurze Hinweise über alle eingehenden nicht-Umfrage HTTP-Anfragen werden protokolliert. level >= 4 die Zeit, die Anforderung zu erfüllen protokolliert. level >= 5 eine Probe aus dem Anfang der Daten wird protokolliert. level >= 6 dann werden die gesamten Daten protokolliert. no level angegeben wird, dann wird das aktuelle Niveau zurückgeführt. If out or all and level >= 3 kurze Hinweise über alle ausgehenden Anfragen durch WebUtil gehen werden protokolliert. level >= 4 die Zeit, die Anforderung zu erfüllen protokolliert. level >= 5 eine Probe aus dem Anfang der Daten wird protokolliert. level >= 6 dann werden die gesamten Daten protokolliert.
Insbesondere eine gute Vorstellung von den Kommunikationsfluss wiederum auf Debug-Level 5 sowohl auf dem Simulator zu bekommen und robuste kurze Ausschnitte aus jeder Anforderung und Antwort zu sehen. Dies wird auch HTTP-Anfragen zwischen dem Betrachter und dem Simulator zeigen.
