Beispiel dafür, wie btrace Produktionsfehler lokalisiert

In diesem Artikel werden hauptsächlich Beispiele für die Methode zur Lokalisierung von Produktionsfehlern vorgestellt. Ich glaube, dass sie für jeden, der sie benötigt, einen gewissen Referenzwert hat.

Vorwort

Oft müssen wir mehr Details über die Ausführung des Programms wissen, aber es ist unmöglich, während der Entwicklung alle Ausführungsdetails im Programm auszudrucken . Normalerweise können Sie zu diesem Zeitpunkt den Code ändern, erneut bereitstellen und ihn dann erneut beobachten. Wenn Sie jedoch auf Code stoßen, ist dies nicht der Fall B. andere referenzierte externe Pakete usw. sind sehr problematisch. BTrace ist ein Tool, das Programmlaufdetails dynamisch anzeigen kann, ohne den Code zu ändern oder die Anwendung neu zu starten. Der folgende Artikel stellt die Methode von BTrace vor, um Produktionsfehler zu lokalisieren. Freunde in Not können darauf verweisen.

Phänomene

Einige Anfragen durchlaufen die Datenzugriffsschicht sehr langsam und führen dazu, dass der Verarbeitungsthread blockiert wird und die Ausnahme bei der Überwachung nicht erkannt werden kann.

Btrace-Skript schreiben

@BTrace
public class DBProxyTrace {

 @OnMethod(clazz = "xxx.xxx.QueryHandler", method = "query",
  location = @Location(Kind.RETURN))
 public static void trace2(String sql, @Duration long duration) {
 if (duration/1000000 > 10 * 1000) {
  com.sun.btrace.BTraceUtils.println(duration/1000000 + "ms");
  com.sun.btrace.BTraceUtils.println("this task executes more than 10s. the sql is : "
   + sql);
  com.sun.btrace.BTraceUtils.println("jstack is : ");
  com.sun.btrace.BTraceUtils.jstack();
 }
 }
}

Beurteilen Sie die SQL- und Stack-Informationen, die länger als 10 Sekunden ausgeführt werden .

Kompilieren Sie das Skript DBProxyTrace.Java und bestätigen Sie, dass kein Problem mit dem Skript vorliegt.

./bin/btracec -cp build/ java/DBProxyTrace.java

Führen Sie das Skript DBProxyTrace.class aus

./bin/btrace -cp build/ 17342 DBProxyTrace.class

Nachricht

10468ms
this task executes more than 10s. the sql is : rollback
jstack is :
xxx.QueryHandler.query(QueryHandler.java:106)
xxx.net.AbstractConnection.onReadData(AbstractConnection.java:245)
xxx.net.NIOReactor$RW.run(NIOReactor.java:77)
java.lang.Thread.run(Thread.java:745)

Positionierung

ist beim Transaktions-Rollback blockiert.

Verwenden Sie jstack zur weiteren Positionierung.

JVM-Stack drucken

"$_NIOREACTOR-7-RW" prio=10 tid=0x00007f069856f000 nid=0xde1 waiting for monitor entry [0x00007f0677011000]
 java.lang.Thread.State: BLOCKED (on object monitor)
 at Oracle.jdbc.driver.PhysicalConnection.rollback(PhysicalConnection.java:1167)
 - waiting to lock <0x000000068086fbc0> (a oracle.jdbc.driver.T4CConnection)

Fazit

Blockierung Bei der Rollback-Aktion des Oracle-Treibers liegt dies tatsächlich daran, dass der Oracle-Treiber auf der unteren Ebene eine Sperre hinzufügt, um die Antwort auf die serielle Anforderung sicherzustellen, und dieser Kanal durch langsame Anweisungen blockiert wird, sodass das Rollback blockiert wird.

Zusammenfassung

Das Obige ist der Inhalt des Beispiels der Btrace-Methode zur Lokalisierung von Produktionsfehlern. Weitere verwandte Inhalte finden Sie hier die chinesische PHP-Website (www.php.cn)!