精华内容
下载资源
问答
  • 系统生成的Trace文件保存在data/anr,可以用过命令adb pull data/anr/取出 traces.txt只保留最后一次ANR的信息,Android系统有个DropBox功能功能,它能记录系统出现的crash错误.因此保留有发生过的ANR的信息.(log...
    • 什么是ANR?

      ANR:Application Not Responding,即应用无响应

    • ANR日志Trace文件获取

      系统生成的Trace文件保存在data/anr,可以用过命令adb pull data/anr/取出

      traces.txt只保留最后一次ANR的信息,Android系统有个DropBox功能功能,它能记录系统出现的crash错误.因此保留有发生过的ANR的信息.(log路径:/data/system/dropbox)

      获取系统crash log: adb shell dumpsys dropbox --print >>log.txt

    1.  

      Trace文件怎么生成的?

    2.  

      当APP(包括系统APP和用户APP)进程出现ANR、应用响应慢或WatchDog的监视没有得到回馈时,

    3.  

      系统会dump此时的top进程,进程中Thread的运行状态就都dump到这个Trace文件中了.

    • 导致ANR的常见几种情况:

      1:Input dispatching timed out(5 seconds) 按键或触摸事件处理超时(一般是UI主线程做了耗时的操作,这类ANR最常见)

      2:BroadcastTimeout(10 seconds) 广播的分发和处理超时(一般是onReceiver执行时间过长)

      3:ServiceTimeout(20 seconds) Service的启动和执行超时

      另外还有ProviderTimeout和WatchDog等导致的ANR.还有当系统内存或CPU资源不足时容易出现ANR,一般这种情况会有lowmemorykill的log打印.

      应用ANR产生的时候,ActivityManagerService的appNotResponding方法就会被调用,然后在/data/anr/traces.txt文件中写入ANR相关信息.

    1.  

      final void appNotResponding(ProcessRecord app, ActivityRecord activity,

    2.  

      ActivityRecord parent, boolean aboveSystem, final String annotation) {

    3.  

      // ... ...

    4.  

      if (MONITOR_CPU_USAGE) {

    5.  

      updateCpuStatsNow(); // 更新CPU使用率

    6.  

      }

    7.  

      // ... ...

    8.  

      final ProcessCpuTracker processCpuTracker = new ProcessCpuTracker(true);

    9.  

      // dumpStackTraces是输出traces文件的函数

    10.  

      File tracesFile = dumpStackTraces(true, firstPids, processCpuTracker, lastPids,

    11.  

      NATIVE_STACKS_OF_INTEREST);

    12.  

       

    13.  

      String cpuInfo = null;

    14.  

      if (MONITOR_CPU_USAGE) {

    15.  

      updateCpuStatsNow(); // 再次更新CPU信息

    16.  

      synchronized (mProcessCpuTracker) {

    17.  

      // 输出ANR发生前一段时间内的CPU使用率

    18.  

      cpuInfo = mProcessCpuTracker.printCurrentState(anrTime);

    19.  

      }

    20.  

      info.append(processCpuTracker.printCurrentLoad());

    21.  

      info.append(cpuInfo);

    22.  

      }

    23.  

      // 输出ANR发生后一段时间内的CPU使用率

    24.  

      info.append(processCpuTracker.printCurrentState(anrTime));

    25.  

       

    26.  

      Slog.e(TAG, info.toString());

    27.  

      if (tracesFile == null) {

    28.  

      // There is no trace file, so dump (only) the alleged culprit's threads to the log

    29.  

      Process.sendSignal(app.pid, Process.SIGNAL_QUIT);

    30.  

      }

    31.  

      // 将ANR信息同时输出到DropBox中

    32.  

      addErrorToDropBox("anr", app, app.processName, activity, parent, annotation,

    33.  

      cpuInfo, tracesFile, null);

    34.  

      // ... ...

    35.  

      synchronized (this) {

    36.  

      // 显示ANR提示对话框

    37.  

      // Bring up the infamous App Not Responding dialog

    38.  

      Message msg = Message.obtain();

    39.  

      HashMap<String, Object> map = new HashMap<String, Object>();

    40.  

      msg.what = SHOW_NOT_RESPONDING_MSG;

    41.  

      msg.obj = map;

    42.  

      msg.arg1 = aboveSystem ? 1 : 0;

    43.  

      map.put("app", app);

    44.  

      if (activity != null) {

    45.  

      map.put("activity", activity);

    46.  

      }

    47.  

      mUiHandler.sendMessage(msg);

    48.  

      }

    49.  

      }

    避免ANR?

    1. UI线程尽量只做跟UI相关的工作

    2. 耗时的工作(比如数据库操作,I/O,连接网络或者别的有可能阻碍UI线程的操作)把它放入单独的线程处理

    3. 尽量用Handler来处理UIthread和别的thread之间的交互

    分析ANR的Log:

    出现ANR的log如下:

    1.  

      06-22 10:37:46.204 3547 3604 E ActivityManager: ANR in org.code:MessengerService // ANR出现的进程包名

    2.  

       

    3.  

      E ActivityManager: PID: 17027 // ANR进程ID

    4.  

       

    5.  

      E ActivityManager: Reason: executing service org.code/.ipc.MessengerService //导致ANR的原因

    6.  

       

    7.  

      E ActivityManager: Load: 8.31 / 8.12 / 8.47

    8.  

       

    9.  

      E ActivityManager: CPU usage from 0ms to 6462ms later: //CPU在ANR发生后的使用情况

    10.  

       

    11.  

      E ActivityManager: 61% 3547/system_server: 21% user + 39% kernel / faults: 13302 minor 2 major

    12.  

       

    13.  

      E ActivityManager: 0.2% 475/debuggerd: 0% user + 0.1% kernel / faults: 6086 minor 1 major

    14.  

       

    15.  

      E ActivityManager: 10% 5742/com.android.phone: 5.1% user + 5.1% kernel / faults: 7597 minor

    16.  

       

    17.  

      E ActivityManager: 6.9% 5342/com.android.systemui: 2.1% user + 4.8% kernel / faults: 4158 minor

    18.  

       

    19.  

      E ActivityManager: 0.1% 477/debuggerd64: 0% user + 0.1% kernel / faults: 4013 minor

    20.  

       

    21.  

      E ActivityManager: 5.7% 16313/org.code: 3.2% user + 2.4% kernel / faults: 2412 minor

    22.  

       

    23.  

      E ActivityManager: 3.7% 17027/org.code:MessengerService: 1.7% user + 2% kernel / faults: 2571 minor 6 major

    24.  

       

    25.  

      E ActivityManager: 2.6% 306/cfinteractive: 0% user + 2.6% kernel

    26.  

      ... ...

    27.  

      E ActivityManager: +0% 17168/kworker/0:1: 0% user + 0% kernel

    28.  

       

    29.  

      E ActivityManager: 0% TOTAL: 0% user + 0% kernel + 0% softirq // CUP占用情况

    30.  

       

    31.  

      E ActivityManager: CPU usage from 5628ms to 6183ms later:

    32.  

       

    33.  

      E ActivityManager: 42% 3547/system_server: 17% user + 24% kernel / faults: 11 minor

    34.  

       

    35.  

      E ActivityManager: 12% 3604/ActivityManager: 1.7% user + 10% kernel

    36.  

       

    37.  

      E ActivityManager: 12% 3609/android.display: 8.7% user + 3.5% kernel

    38.  

       

    39.  

      E ActivityManager: 3.5% 5304/Binder_6: 1.7% user + 1.7% kernel

    40.  

       

    41.  

      E ActivityManager: 3.5% 5721/Binder_A: 1.7% user + 1.7% kernel

    42.  

       

    43.  

      E ActivityManager: 3.5% 5746/Binder_C: 3.5% user + 0% kernel

    44.  

       

    45.  

      E ActivityManager: 1.7% 3599/Binder_1: 0% user + 1.7% kernel

    46.  

       

    47.  

      E ActivityManager: 1.7% 3600/Binder_2: 0% user + 1.7% kernel

    48.  

       

    49.  

      I ActivityManager: Killing 17027:org.code:MessengerService/u0a85 (adj 1): bg anr

    50.  

       

    51.  

      I art : Wrote stack traces to '/data/anr/traces.txt' //art这个TAG打印对traces操作的信息

    52.  

       

    53.  

      D GraphicsStats: Buffer count: 9

    54.  

       

    55.  

      W ActivityManager: Scheduling restart of crashed service org.code/.ipc.MessengerService in 1000ms

    56.  

       

    log打印了ANR的基本信息,我们可以分析CPU使用率推测ANR发生的时候设备在做什么工作;如果CPU使用率很高,接近100%,可能是在进行大规模的计算更可能是陷入死循环;如果CUP使用率很低,说明主线程被阻塞了,并且当IOwait很高,可能是主线程在等待I/O操作的完成.

    对于ANR只是分析Log很难知道问题所在,我们还需要通过Trace文件分析stack调用情况.

    1.  

       

    2.  

      ----- pid 17027 at 2017-06-22 10:37:39 ----- // ANR出现的进程pid和时间(和上述log中pid一致)

    3.  

      Cmd line: org.code:MessengerService // ANR出现的进程名

    4.  

      Build fingerprint: 'Homecare/qucii8976v3_64:6.0.1/pansen06141150:eng/test-keys' // 下面记录系统版本,内存等状态信息

    5.  

      ABI: 'arm64'

    6.  

      Build type: optimized

    7.  

      Zygote loaded classes=6576 post zygote classes=13

    8.  

      Intern table: 13780 strong; 17 weak

    9.  

      JNI: CheckJNI is on; globals=283 (plus 158 weak)

    10.  

      Libraries: /system/lib64/libandroid.so /system/lib64/libcompiler_rt.so /system/lib64/libjavacrypto.so /system/lib64/libjnigraphics.so /system/lib64/libmedia_jni.so /system/lib64/libwebviewchromium_loader.so libjavacore.so (7)

    11.  

      Heap: 29% free, 8MB/12MB; 75731 objects

    12.  

      Dumping cumulative Gc timings

    13.  

      Total number of allocations 75731

    14.  

      Total bytes allocated 8MB

    15.  

      Total bytes freed 0B

    16.  

      Free memory 3MB

    17.  

      Free memory until GC 3MB

    18.  

      Free memory until OOME 183MB

    19.  

      Total memory 12MB

    20.  

      Max memory 192MB

    21.  

      Zygote space size 3MB

    22.  

      Total mutator paused time: 0

    23.  

      Total time waiting for GC to complete: 0

    24.  

      Total GC count: 0

    25.  

      Total GC time: 0

    26.  

      Total blocking GC count: 0

    27.  

      Total blocking GC time: 0

    28.  

       

    29.  

      suspend all histogram: Sum: 76us 99% C.I. 0.100us-28us Avg: 7.600us Max: 28us

    30.  

      DALVIK THREADS (15):

    31.  

      // Signal Catcher是记录traces信息的线程

    32.  

      // Signal Catche(线程名)、(daemon)表示守护进程、prio(线程优先级,默认是5)、tid(线程唯一标识ID)、Runnable(线程当前状态)

    33.  

      "Signal Catcher" daemon prio=5 tid=3 Runnable

    34.  

      //线程组名称、suspendCount、debugSuspendCount、线程的Java对象地址、线程的Native对象地址

    35.  

      | group="system" sCount=0 dsCount=0 obj=0x12d8f0a0 self=0x5598ae55d0

    36.  

      //sysTid是线程号(主线程的线程号和进程号相同)

    37.  

      | sysTid=17033 nice=0 cgrp=default sched=0/0 handle=0x7fb2350450

    38.  

      | state=R schedstat=( 4348125 172343 3 ) utm=0 stm=0 core=1 HZ=100

    39.  

      | stack=0x7fb2254000-0x7fb2256000 stackSize=1013KB

    40.  

      | held mutexes= "mutator lock"(shared held)

    41.  

      native: #00 pc 0000000000489e28 /system/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, int, char const*, art::ArtMethod*, void*)+236)

    42.  

      native: #01 pc 0000000000458fe8 /system/lib64/libart.so (art::Thread::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) const+220)

    43.  

      native: #02 pc 0000000000465bc8 /system/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread*)+688)

    44.  

      native: #03 pc 0000000000466ae0 /system/lib64/libart.so (art::ThreadList::RunCheckpoint(art::Closure*)+276)

    45.  

      native: #04 pc 000000000046719c /system/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+188)

    46.  

      native: #05 pc 0000000000467a84 /system/lib64/libart.so (art::ThreadList::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+492)

    47.  

      native: #06 pc 0000000000431194 /system/lib64/libart.so (art::Runtime::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+96)

    48.  

      native: #07 pc 000000000043e604 /system/lib64/libart.so (art::SignalCatcher::HandleSigQuit()+1256)

    49.  

      native: #08 pc 000000000043f214 /system/lib64/libart.so (art::SignalCatcher::Run(void*)+452)

    50.  

      native: #09 pc 0000000000068714 /system/lib64/libc.so (__pthread_start(void*)+52)

    51.  

      native: #10 pc 000000000001c604 /system/lib64/libc.so (__start_thread+16)

    52.  

      (no managed stack frames)

    53.  

       

    54.  

      //main(线程名)、prio(线程优先级,默认是5)、tid(线程唯一标识ID)、Sleeping(线程当前状态)

    55.  

      "main" prio=5 tid=1 Sleeping

    56.  

      | group="main" sCount=1 dsCount=0 obj=0x73132d10 self=0x5598a5f5e0

    57.  

      //sysTid是线程号(主线程的线程号和进程号相同)

    58.  

      | sysTid=17027 nice=0 cgrp=default sched=0/0 handle=0x7fb6db6fe8

    59.  

      | state=S schedstat=( 420582038 5862546 143 ) utm=24 stm=18 core=6 HZ=100

    60.  

      | stack=0x7fefba3000-0x7fefba5000 stackSize=8MB

    61.  

      | held mutexes=

    62.  

      // java 堆栈调用信息(这里可查看导致ANR的代码调用流程)(分析ANR最重要的信息)

    63.  

      at java.lang.Thread.sleep!(Native method)

    64.  

      - sleeping on <0x0c60f3c7> (a java.lang.Object)

    65.  

      at java.lang.Thread.sleep(Thread.java:1031)

    66.  

      - locked <0x0c60f3c7> (a java.lang.Object) // 锁住对象0x0c60f3c7

    67.  

      at java.lang.Thread.sleep(Thread.java:985)

    68.  

      at android.os.SystemClock.sleep(SystemClock.java:120)

    69.  

      at org.code.ipc.MessengerService.onCreate(MessengerService.java:63) //导致ANR的代码

    70.  

      at android.app.ActivityThread.handleCreateService(ActivityThread.java:2877)

    71.  

      at android.app.ActivityThread.access$1900(ActivityThread.java:150)

    72.  

      at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1427)

    73.  

      at android.os.Handler.dispatchMessage(Handler.java:102)

    74.  

      at android.os.Looper.loop(Looper.java:148)

    75.  

      at android.app.ActivityThread.main(ActivityThread.java:5417)

    76.  

      at java.lang.reflect.Method.invoke!(Native method)

    77.  

      at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)

    78.  

      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

    在log中显示的pid在traces文件中与之对应,trace log中会打印当前所有线程的堆栈信息,一般我们主要关注main线程的堆栈(也有分析其他线程的情况,通过分析ANR发生时系统状态推测出设备正在进行操作)

    而这里然后通过查看堆栈调用信息分析ANR的代码.上述ANR实际上在org.code.ipc.MessengerService.onCreate中63行调用SystemClock.sleep(10000)代码导致的;这是比较简单ANR示例.

    以上仅为解决ANR问题提供一个思路,具体问题还需要根据实际情况具体分析


    线程状态的分类: java中定义的线程状态:

    1.  

      // libcore/libart/src/main/java/java/lang/Thread.java

    2.  

      /**

    3.  

      * A representation of a thread's state. A given thread may only be in one

    4.  

      * state at a time.

    5.  

      */

    6.  

      public enum State {

    7.  

      /**

    8.  

      * The thread has been created, but has never been started.

    9.  

      */

    10.  

      NEW,

    11.  

      /**

    12.  

      * The thread may be run.

    13.  

      */

    14.  

      RUNNABLE,

    15.  

      /**

    16.  

      * The thread is blocked and waiting for a lock.

    17.  

      */

    18.  

      BLOCKED,

    19.  

      /**

    20.  

      * The thread is waiting.

    21.  

      */

    22.  

      WAITING,

    23.  

      /**

    24.  

      * The thread is waiting for a specified amount of time.

    25.  

      */

    26.  

      TIMED_WAITING,

    27.  

      /**

    28.  

      * The thread has been terminated.

    29.  

      */

    30.  

      TERMINATED

    31.  

      }

    C代码中定义的线程状态:

    1.  

      // /art/runtime/thread_state.h

    2.  

      enum ThreadState {

    3.  

      // Thread.State JDWP state

    4.  

      kTerminated = 66, // TERMINATED TS_ZOMBIE Thread.run has returned, but Thread* still around

    5.  

      kRunnable, // RUNNABLE TS_RUNNING runnable

    6.  

      kTimedWaiting, // TIMED_WAITING TS_WAIT in Object.wait() with a timeout

    7.  

      kSleeping, // TIMED_WAITING TS_SLEEPING in Thread.sleep()

    8.  

      kBlocked, // BLOCKED TS_MONITOR blocked on a monitor

    9.  

      kWaiting, // WAITING TS_WAIT in Object.wait()

    10.  

      kWaitingForGcToComplete, // WAITING TS_WAIT blocked waiting for GC

    11.  

      kWaitingForCheckPointsToRun, // WAITING TS_WAIT GC waiting for checkpoints to run

    12.  

      kWaitingPerformingGc, // WAITING TS_WAIT performing GC

    13.  

      kWaitingForDebuggerSend, // WAITING TS_WAIT blocked waiting for events to be sent

    14.  

      kWaitingForDebuggerToAttach, // WAITING TS_WAIT blocked waiting for debugger to attach

    15.  

      kWaitingInMainDebuggerLoop, // WAITING TS_WAIT blocking/reading/processing debugger events

    16.  

      kWaitingForDebuggerSuspension, // WAITING TS_WAIT waiting for debugger suspend all

    17.  

      kWaitingForJniOnLoad, // WAITING TS_WAIT waiting for execution of dlopen and JNI on load code

    18.  

      kWaitingForSignalCatcherOutput, // WAITING TS_WAIT waiting for signal catcher IO to complete

    19.  

      kWaitingInMainSignalCatcherLoop, // WAITING TS_WAIT blocking/reading/processing signals

    20.  

      kWaitingForDeoptimization, // WAITING TS_WAIT waiting for deoptimization suspend all

    21.  

      kWaitingForMethodTracingStart, // WAITING TS_WAIT waiting for method tracing to start

    22.  

      kWaitingForVisitObjects, // WAITING TS_WAIT waiting for visiting objects

    23.  

      kWaitingForGetObjectsAllocated, // WAITING TS_WAIT waiting for getting the number of allocated objects

    24.  

      kStarting, // NEW TS_WAIT native thread started, not yet ready to run managed code

    25.  

      kNative, // RUNNABLE TS_RUNNING running in a JNI native method

    26.  

      kSuspended, // RUNNABLE TS_RUNNING suspended by GC or debugger

    27.  

      };

    两者可以看出在C代码中定义更为详细,Traces中显示的线程状态都是C代码定义的.我们可以通过查看线程状态对应的信息分析ANR问题.

    如: TimedWaiting对应的线程状态是TIMED_WAITING

    kTimedWaiting, // TIMED_WAITING TS_WAIT in Object.wait() with a timeout 执行了无超时参数的wait函数

    kSleeping, // TIMED_WAITING TS_SLEEPING in Thread.sleep() 执行了带有超时参数的sleep函数

    1.  

      ZOMBIE 线程死亡,终止运行

    2.  

      RUNNING/RUNNABLE 线程可运行或正在运行

    3.  

      TIMED_WAIT 执行了带有超时参数的wait、sleep或join函数

    4.  

      MONITOR 线程阻塞,等待获取对象锁

    5.  

      WAIT 执行了无超时参数的wait函数

    6.  

      INITIALIZING 新建,正在初始化,为其分配资源

    7.  

      STARTING 新建,正在启动

    8.  

      NATIVE 正在执行JNI本地函数

    9.  

      VMWAIT 正在等待VM资源

    10.  

      SUSPENDED 线程暂停,通常是由于GC或debug被暂停

    展开全文
  • Oracle diag目录下面的大量trace trc文件

    万次阅读 2017-02-03 10:55:30
    Oracle tarce文件是oracle数据库在运行时产生的日志,该trace文件是可以删除的,对系统没有什么影响。 在删除前,先查看trace的参数配置  SQL> show parameter trace_en NAME TYPE VALUE -----------------...

    Oracle tarce文件是oracle数据库在运行时产生的日志,该trace文件是可以删除的,对系统没有什么影响。

    在删除前,先查看trace的参数配置

      SQL> show parameter trace_en
    NAME                                TYPE        VALUE
    ------------------------------------ ----------- ------------------------------
    trace_enabled                        boolean    TRUE
    SQL>

      通过find命令查找30天以前创建的文件,通过xargs管道和rm-rf命令,可以直接删除
    [oracle@HBCADB001 hbcadb1]$ find trace -ctime +30|more
    trace/hbcadb1_j000_25349.trc
    trace/hbcadb1_j000_28514.trm
    trace/hbcadb1_ora_12171.trm
    trace/hbcadb1_ora_4595.trm
    trace/hbcadb1_j000_3029.trm
    trace/hbcadb1_ora_14967.trm
    trace/hbcadb1_j000_2237.trm
    trace/hbcadb1_j000_13278.trc
    trace/hbcadb1_ora_13051.trm

      find trace -ctime +30 |xargs rm -f

    展开全文
  • ; margin-right:0pt">Trace...及通过什么条件可以关联到哪些trace是同一个业务sql执行生成的。开启trace日志后,在gnode发现有大量的trace日志文件,如何知道哪个日志文件是对应我刚执行的sql?</p>
  • oracle tarce文件是oracle数据库在运行时产生的日志,该trace文件是可以删除的,对系统没有什么影响。 在删除前,先查看trace的参数配置 SQL> show parameter trace_en ...
    oracle tarce文件是oracle数据库在运行时产生的日志,该trace文件是可以删除的,对系统没有什么影响。
    在删除前,先查看trace的参数配置
    SQL> show parameter trace_en
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------------------------
    trace_enabled                        boolean     TRUE
    SQL>
    通过find命令查找30天以前创建的文件,通过xargs管道和rm-rf命令,可以直接删除
    [oracle@HBCADB001 hbcadb1]$ find trace -ctime +30|more
    trace/hbcadb1_j000_25349.trc
    trace/hbcadb1_j000_28514.trm
    trace/hbcadb1_ora_12171.trm
    trace/hbcadb1_ora_4595.trm
    trace/hbcadb1_j000_3029.trm
    trace/hbcadb1_ora_14967.trm
    trace/hbcadb1_j000_2237.trm
    trace/hbcadb1_j000_13278.trc
    trace/hbcadb1_ora_13051.trm
    find trace -ctime +30 |xargs rm -f
     
     
     

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8541492/viewspace-747818/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/8541492/viewspace-747818/

    展开全文
  • trace文件不断在写入

    2016-05-16 12:10:36
    具体是什么问题等下再研究,但是得先解决空间问题。 System State dumped to trace file /oracle/app/admin/HADB/bdump/hadb1_diag_7293.trc 系统不断写入trc文件,已经写了40g 把它删除还不释放空间,反而...
    发现oralce目录空间不足,看了下还是日志记录太多的问题。看到有个trace不断写入。具体是什么问题等下再研究,但是得先解决空间问题。
    
    
    System State dumped to trace file /oracle/app/admin/HADB/bdump/hadb1_diag_7293.trc
    系统不断写入trc文件,已经写了40g
    把它删除还不释放空间,反而占用空间不断增长。
    ps -ef|grep 7293
    发现diag进程
    diag进程是可以kill的,并且会释放trc文件占用的空间。kill之后会自动restart
    kill了之后问题解决,释放空间
    展开全文
  • 大部分情况下,我们可以利用tkprof工具格式化trace文件,让trace文件便于阅读,但trkprof产生的是trace文件的汇总结果,如果需要知道sql每一步确切执行了什么,我们也只能直接阅读trace============================...
  • 后来有一天发现磁盘空间不足,经过查询后发现如下路径下有几千个文件,占用了上G的空间:/u01/app/oracle/11.2.0.4/diag/clients/user_oracle/host_1347578259_80/trace这些文件什么?打开一个,发
  • 什么是ANR,造成ANR的原因有哪些?网上很多,这里我就不介绍了。 下面我就以一个实战例子直奔主题: 一:首先当我们手机里运行的某个APP发生了ANR,系统会将当前APP的运行日志写入到sd卡的 data/anr 目录中。 比如...
  • 快速找到oradebug hanganalyze产生的trace文件   当数据库hang住时,我们DBA经常会...我们都知道产生的trace文件是存放在bdump目录下,但产生的trc文件名称是什么呢,不知道文件名称,我们就很难找到trc文件。下面
  • app如何获取ANR时产生的trace文件

    千次阅读 2018-01-11 17:23:14
    跑了个Demo程序,想把/data/anr/trace.txt文件拿到,然而普通app是无法获取该文件的,就算把手机root也不行。...先通过adb,进入app的外部存储路径看看有什么文件: 以ecmsLogger(java).log文件为例,
  • android trace文件分析ANR

    2017-07-24 12:20:00
    什么80%的码农都做不了架构师?>>> ...
  • Trace文件是个什么鬼?App的进程发生ANR时,系统让活跃的Top进程都进行了一下dump,进程中的各种Thread就都dump到这个trace文件里了,所以trace文件中包含了每一条线程的运行时状态。下面给大家详细介绍Thread Dump...
  • ns2中程序未执行完无trace文件探究

    千次阅读 2015-04-21 15:57:30
    最近几天在做仿真的过程中,程序执行了一点点就出错了,想分析一下trace文件发现还没有内容,这是为什么呢?不是MAC层的downtarget就是trace吗?明明已经从MAC层几进几出了为什么还是没有内容呢?带着这个疑问我查看...
  • 有时内存泄漏无法定位, 只有一大串内存使用情况的log这时候就可以分析trace文件.使用adb输入adb pull /data/anr/traces.txt导出文件到下面出现的地址中主要分析文件中与项目相关的关键字如果adb无法使用, 显示非内部...
  • 大部分情况下,我们可以利用tkprof工具格式化trace文件,让trace文件便于阅读,但trkprof产生的是trace文件的汇总结果,如果需要知道sql每一步确切执行了什么,我们也只能直接阅读trace ==========================...
  • 大部分情况下,我们可以利用tkprof工具格式化trace文件,让trace文件便于阅读,但trkprof产生的是trace文件的汇总结果,如果需要知道sql每一步确切执行了什么,我们也只能直接阅读trace ==========================...
  •  我们在查看一条SQL的执行计划的时候,只能看到CBO 最终告诉我们的执行计划结果,但是不知道CBO 是根据什么来做的。 如果遇到了执行计划失真,如:一个SQL语句,很明显oracle应该使用索引,但是执行计划却没有使用...
  • 但是在trace目录下的sicsdb_ora_spid.trc(spid为系统进程id)文件中 找不到DEADLOCK DETECTED ( ORA-00060 )的信息 根据SQL_ID查到的日志也没有报错,如下图,请问我是不是少设置了什么东西么,怎样可以看到死锁...
  • mysql trace_MySQL SQL trace

    2021-01-25 16:17:57
    MySQL SQL trace从 MySQL 5.6 开始,...通过trace文件能够进一步了解为什么优化器选择A计划, 而不是选择B计划。打开trace,并设置格式为jsonSET optimizer_trace="enabled=on",end_markers_in_json=on;设置trace使...
  • 今天突然发现,本地测试的数据库的TRACE文件夹下的跟踪文件生成的很频繁。已经这样持续了一个月了,生成的日志总量达到了70多G。看了看这样开始的日期,自己记得当时好像在做跟踪日志的测试,想着应该是无意打开了...
  • 用Visual Studio 2010后发现我的c盘变得越来越小了,刚开始通过优化工具清理c盘,但是无论怎么做都不能将c的内存有效提升,之后一个...从网上查了查知道这是什么了(具体信息从推荐Visual Studio 2010新功能-Intel
  • 啊!!!终于成功了,经过无数次调试,...自己模仿ping协议写了一个myping协议,为什么总是会调用到原来的ping协议?头疼。。。。。 下面贴上自己的代码,最简单,但五脏俱全: 头文件如下: #ifndef ns_lwb2_h #de
  • 通过trace文件能够进一步了解为什么优化器选择A计划, 而不是选择B计划。打开trace,并设置格式为jsonSET optimizer_trace="enabled=on",end_markers_in_json=on;设置trace使用的内存大小,避免解析过程内存...
  • Centos7的/tmp文件夹下有一个叫trace.***.xt的文件竟然有24G(见图),我抓数据的时候文件不停的运行,然后这个文件就增大,大概一天可以变得有十几个G大,请问这到底是这个什么文件? 这个问题困扰了我很久,是我不停的抓...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 442
精华内容 176
关键字:

trace什么文件