tick?ں?Դ??

       本文深入解析鸿蒙轻内核的时间管理机制，关注其在任务调度与时间服务中的分析关键作用。时间管理模块的内核核心在于处理系统时钟的Tick中断，为应用程序提供时间转换、源码源码统计等服务。分析新疆到哈尔滨源码

       基于OpenHarmony LiteOS-M内核的内核源码，我们首先从系统时钟的源码源码生成机制讲起，它是分析通过定时器/计数器产生的Tick，作为操作系统的内核基本时间单位。Tick的源码源码周期和数量可以根据用户配置进行调整，如1ms等于个Tick。分析此外，内核Cycle作为最小计时单位，源码源码与主时钟频率紧密相关。分析

       在代码实现上，时间管理的初始化和启动过程涉及关键配置，如系统时钟和Tick频率，以及可能的定制中断处理函数。在main函数中，通过调用一系列函数逐步启动和配置时间管理模块。

       Tick中断处理函数OsTickHandler负责实时更新Tick计数，检查任务状态和定时器，确保时间服务的准确执行。同时，内核提供了实用工具，如将毫秒、Tick和Cycle互相转换，以及统计自系统启动以来的时间量。

       总的来说，鸿蒙轻内核的mlt剪辑shotcut源码时间管理模块是任务调度和应用程序之间时间协调的关键桥梁，其源码提供了深入了解和定制操作的基础。对于开发者来说，这是一项重要的技术基础，有助于优化系统性能和用户体验。

如何学习 nucleus os

       å†…容：

       ä¸€ã€nucleus plus特点：

           1.内核采用微内核的设计，方便移植，资料写着更reliable，但是我不这么认为，与linux相比，以ARM平台为例，NU只用到了SVC mode，内核与用户任务都运行在同一个状态下，也就是说所有的task都拥有访问任何资源的权限，这样很reliable么？

           2.real-time OS，NU是一个软实时操作系统（VxWorks是硬实时），thread control component支持多任务以及任务的抢占，对于中断的处理定义了两种服务方式，LISR和HISR，这个与linux中的上、下半部机制类似，linux中的下半部是通过软中断来实现的，NU的HISR只是作为一种优先级总是高于task的任务出现。

           3.NU是以library的方式应用的，通过写自己的app task与裁剪后的NU内核及组件链接起来，NU并没有CLI

       äºŒã€ç»„件

       1.IN component

           初始化组件由三个部分组成，硬件在reset后首先进入INT_initialize()，进行板级的相关初始化，首先设置SVC mode，关中断，然后将内核从rom中拷贝至ram中，建立bss段，依次建立sys stack, irq stack和fiq stack，最后初始化timer，建立timer HISR的栈空间，看了一下平台的代码，一个tick大概是.8ms，完成板级的初始化后就进入了INC_initialize，初始化各个组件，其中包括Application initialize，create task和HISR，最后将控制权交给schedule，主要看了一下RAM中地址空间的安排

       |timer HISR stack = |

       |FIQ stack = |

       |IRQ stack = |

       |SVC stack = |

       |.bss|

       |.data|

       |.text|

       å…¶ä¸­SVC stack的大小与中断源的个数相关，nested irq发生时，irq_context保存在SVC stack中，IRQ的stack只是做了临时栈的作用。

       2.thread control component

           TC组件是NU内核的最重要组成部分，主要涵盖了调度、中断、任务的相关操作、锁、时钟几个方面，下面分别介绍。

       è°ƒåº¦ï¼ˆschedule）

           NU中的线程类型（在同一个地址空间内）有两种，HISR和task，HISR可以理解为一种优先级较高的task，但又不是task，HISR优先级高于task的实现方式就是schdule时，先去查看当前是否有active的HISR，再去查看task。task有suspend、ready、finished和terminated四种状态，而HISR只有executing和no-active这两种状态。

           每一个task都有一个线程控制的数据结构（TCB thread control block）,其中包括了task的优先级、状态、时间片、task栈、protect信息、signal操作的标志位和signal_handler等，task在创建时初始化这些信息，将task挂到一个create_list上，初始设定task为pure_suspend，如果设定auto start，调用resume_task（）唤醒task，这里有个细节，如果在application initialize中create_task()，则task不会自动运行，因为初始化还未完成，控制权还没有交给schedule，无法调度task。task被唤醒后状态改变为ready，并挂在一个TCD_Priority_List[]上，数组的每个元素是一个指向TCB环形双向链表的指针，根据task的tc_priority找到对应优先级的TCB head pointer。

           每一个HISR都有一个HISR控制的数据结构（HCB HISR control block）,其中只有优先级，HISR栈和HISR entry信息，因此HISR是不可以suspend，同时也没有time slice以及signal的相关操作，一般情况下当发生了中断后，HISR被activate，schedule就会调度HISR运行，期间如果不发生中断，HISR的执行是不会被打断的，HISR的优先级只有0、1、2，timer的HISR优先级为2，也就是说由外部中断激活的HISR很难被抢占的，只有更高优先级的中断HISR才可以。与task不同，被激活的HISR使用head_list和tail_list将HCB挂在一个单项的链表上，因为相同优先级的HISR不会抢占对方，因此不需要双向链表，使用两个指针目的是加快HISR执行的速度。

           一个实时操作系统的核心就是对于任务的调度，NU的调度策略是time slice和round robin的算法，

       è°ƒåº¦çš„部分主要有三个函数control_to_system()用于保存上下文，建立solicited stack，关中断，关system time slice，并重置task的time slice为预设值，将sp更新为system_stack_pointer，调用schedule()，调度的过程是非常简单的查询，就是查看两个全局的变量，TCD_Execute_HISR和TCD_Execute_Task，schedule部分的关键是打开了中断，不然如果当前没有ready的task或是被激活的HISR，则shedule死循环下去，查询到下一个应该执行的线程后跳转至control_to_thread(),在这里重新开启system time slice，然后将线程的tc_stack_ptr加入到sp中，切换至线程的栈中，依次pop出来，即完成了任务调度。

           任务的切换主要是上下文的切换，也就是task栈的切换，函数的调用会保存部分regs和返回地址，这些动作都是编译器来完成的，而OS中的任务切换是运行时（runtime）的一种状态变化，因此编译器也无能为力，所以对于上下文的保存需要代码来实现。

           任务的抢占是异步的因此必须要通过中断来实现，一般每次timer的中断决定当前的task的slice time是否expired，然后设置TCT_Set_Execute_Task为相同优先级的其他task或更高优先级的task；高优先级的task抢占低优先级的task，一般是外部中断触发，在HISR中resume_task()唤醒高优先级的task，然后schedule到高优先级的task中，因为timer的HISR是在系统初始化就已经注册的，只是执行timeout和time slice超时后的操作，并没有执行resume_task的动作。

           NU中的stack有两种solicited stack和interrupt stack，solicited stack是一种minmum stack，而interrupt stack是对当前所有寄存器全部保存，TCB中的minimum stack size = 申请得到stack size - solicited stack（在arm mode下占字节，thumb mode下占字节），thumb标志用来记录上下文保存时的ARM的工作模式，c代码编译为thumb模式，这样可以减小code size，提高代码密度，assembly代码编译为arm模式提升代码的效率，NU中内核的代码不多，主要是assembly代码。stack的类型与其中PC指向的shell无关，interrupt stack保存的是task或是HISR在执行的过程中被中断时的现场，solicited stack建立的地方包括 control_to_system()、schedule_protect()和send_signals()发送给占有protect资源的task的情况，HISR_Shell()执行完后会建立solicited stack，再跳转至schedule。

       (Lower Address) Stack Top -> 1 (Interrupt stack type)

       CPSR Saved CPSR

       r0 Saved r0

       r1 Saved r1

       r2 Saved r2

       r3 Saved r3

       r4 Saved r4

       r5 Saved r5

       r6 Saved r6

       r7 Saved r7

       r8 Saved r8

       r9 Saved r9

       r Saved r

       r Saved r

       r Saved r

       sp Saved sp

       lr Saved lr

       (Higher Address) Stack Bottom-> pc Saved pc

       (Lower Address) Stack Top -> 0 (Solicited stack type)

       !!FOR THUMB ONLY!! 0/0x Saved state mask

       r4 Saved r4

       r5 Saved r5

       r6 Saved r6

       r7 Saved r7

       r8 Saved r8

       r9 Saved r9

       r Saved r

       r Saved r

       r Saved r

       (Higher Address) Stack Bottom-> pc Saved pc

       ä¸€ä¸ªç®€å•çš„例子说明stack的情况，首先是一个task在ready(executing)的状态下，而且time slice超时了，timer中断发生后，保存task上下文interrupt_contex_save()，在task的tc_stack_ptr指向的地方建立中断栈

       taskA    |interrupt stack|___tc_stack_ptr 栈顶端是pc=lr-4

       ARM对于中断的判定发生在当前指令完成execute时，同时pipeline的原因pc=pc+8，入栈时就把lr-4首先放在stack的最高端（high）。

       timer的LISR完成后激活了HISR，执行TCC_Time_slice()将当前task移到相同优先级的尾端，并且设置下一个要执行的task，HISR在栈顶端保存的是这个HISR_shell的入口地址，因为task的执行完就finished，HISR是可重入的

       HISR     |solicited stack|  æ ˆé¡¶ç«¯æ˜¯HISR_shell_entry

       ä¸­æ–­ï¼ˆinterrupt）

       å‰é¢å·²ç»æåŠäº†ä¸­æ–­çš„基本操作，这里就写一些代码路径的细节，中断的执行主要是两个部分LISR和HISR，分成两个部分的目的就是将关中断的时间最小化，并且在LISR中开中断允许中断的嵌套，以及建立中断优先级，都可以减少中断的延迟，保证OS的实时性。

       NU的中断模式是可重入的中断处理方式，也就是基于中断优先级和嵌套的模式，中断的嵌套在处理的过程中应对lr_irq_mode寄存器进行保存，因为高优先级的中断发生时会覆盖掉低优先级中断的r和spsr，因此要利用系统的栈来保存中断栈。

       NU对于中断上下文的保存具体操作如下：

       ï¼ˆ1）在中断发生后执行的入口函数INT_IRQ()中，将r0-r4保存至irq的栈中

       ï¼ˆ2）查找到对应的interrupt_shell()，clear中断源，更新全局的中断计数器，然后进行interrupt_contex_save

       ï¼ˆ3）首先利用r1,r2,r3保存irq模式下的sp,lr,spsr，这里sp是用来切换至系统栈后拷贝lr和spsr的,这里保存lr和spsr是目的是task被抢占后，当再次schedule时可以返回task之前的状态。

       ï¼ˆ4）切换至SVC模式，如果是非嵌套的中断则保存上下文至task stack中，将irq模式下的lr作为顶端PC的返回值入栈，将SVC模式下的r6-r入栈，将irq模式下的sp保存至r4中入栈，最后将保存在irq_stack中的r0-r4入栈

       ï¼ˆ5）如果是嵌套中断，中断的嵌套发生在LISR中，在执行LISR时已经切换至system stack，因此嵌套中断要将中断的上下文保存至system stack中，与task stack中interrupt stack相比只是少了栈顶用来标记嵌套的标志（1 not nested）

       ï¼ˆ6）有一个分支判断，就是如果当前线程是空，即TCD_Current_Thread == NULL，表明当前是schedule中，因为初始化线程是关中断的，这样就不为schedule线程建立栈帧，因为schedule不需要保存上下文，在restore中断上下文时直接跳转至schedule。

       ä¸­æ–­ä¸Šä¸‹æ–‡çš„恢复

       å…¨å±€çš„中断计数器INT_Count是否为0来判定当前出栈的信息，如果是嵌套则返回LISR中，否则切换至system stack执行schedule

       timer

       timer与中断紧密相关，其实timer也是中断的一种，只是发生中断的频率较高，且作用重大，一个实时操作系统，时间是非常重要的一部分，NU中的timer主要有四个作用：

       ï¼ˆ1）维护系统时钟 TMD_system_clock

       ï¼ˆ2）task的time slice

       ï¼ˆ3）task的suspend timeout timer

       ï¼ˆ4）application timer

       å…¶ä¸­ï¼ˆ3）（4）共用一种机制，一个全局的时间轴TMD_timer，timeout timer和app timer都建立在一个TM_TCB的数据结构上，通过tm_remaining_time来表征当前timer的剩余时间，例如当前有timer_list上有三个TM_TCB，依次是Ta = 5，Tb = 7, Tc = ,那么建立的链表上剩余时间依次是5，2，8，如果现在要加入一个新的timer根据timer值插入至合适的位置，如果插入的timer为，则安排在Tb后面，剩余时间为1，后面的8改为7，当发生了timer expired，则触发timer_HISR，如果是app timer则执行timer callback，如果是task timeout timer，则执行TCC_Task_Timeout唤醒task。

       ï¼ˆ2）的实现也是依赖于全局的time slice时间轴，每一个task在执行时都会将自己的时间片信息更新至全局的时间轴上，当一个task的time slice执行完在timer HISR中调用TCC_task_Timeout将当前的task放在相同优先级list的最尾端，并设置下一个最高优先级的任务。task在执行的过程中只有被中断后time slice会保存下来，其他让出处理器的情况都会将time slice更新为预设值。

       protect

       protect与linux的锁机制类似，互斥访问，利用开关中断来实现，并且拥有protect的task是不可以suspend的，必须要将protect释放后才可以挂起，当一个优先级较低的task占有protect资源，如果被抢占，一个高优先级的task或HISR在请求protect资源时会执行TCC_schedule_protect()让出处理器给低优先级的task执行，直到低优先级的task执行unprotect()为止，此时task或HISR建立的是solicited stack，同时在control_to_thread前开关中断一次，这样可以减少一次上下文的切换。NU中常用到的是system_protect，它就是一把大锁，保护内核中所有全局数据结构的顺序访问，粒度很大。

       LISR中不可以请求protect资源，因为LISR是中断task后执行，如果task占有protect资源，这时LISR又去请求protect资源，会发生死锁，因为LISR让出处理器后，schedule没办法再次调度到LISR执行，则发生死锁错误，因此在LISR中除了activate_HISR（）以外不可以使用system call，例如resume_task等等，这写系统调用都会请求protect资源。

       å¯¹äºŽprotect的请求按照一定的顺序可以防止死锁，NU的源码中一般将system_protect资源的请求放在后面，其他如DM_protect先请求。

SpringBoot定时任务 - 经典定时任务设计：时间轮(Timing Wheel)案例和原理

       在探讨经典定时任务设计时，时间轮（Timing Wheel）无疑是一个引人注目的概念。时间轮是一种环形数据结构，由George Varghese和Tony Lauck在年提出，被广泛应用于Linux内核中，并构成了Linux定时器的基础之一。时间轮的结构类似于一个时钟，分为多个格子（Tick），每个格子代表固定的时间间隔，指向存储在其中的任务链表。

       具体而言，任务的添加与执行遵循时间轮的规则：假设任务在秒后执行，它将转两轮，最终加入Tick=1位置的链表。当时钟转至两轮后到达Tick=1的位置时，会启动该链表中的任务。这使得时间轮成为非准实时、延迟短平快任务的理想选择，比如心跳检测。

       Netty的HashedWheelTimer正是基于时间轮的原理设计，旨在解决延迟任务和低时效性问题。在Netty中，HashedWheelTimer特别适用于优化I/O超时调度，例如在长连接场景中判断连接是否idle。通过使用时间轮，Netty能够高效地管理数百万级别的手机捕捞季节源码长连接，减少资源占用，提升系统性能。

       HashedWheelTimer的使用方式主要包括构造函数参数的设置，其中关键参数包括轮数、tick数等。通过合理配置，开发者可以针对特定需求定制时间轮的运行逻辑。例如，可以设置轮数为多级，形成层次化的结构，进一步优化任务调度。

       通过示例代码展示，HashedWheelTimer可以实现5秒后执行任务的逻辑，并提供任务失效后的cancel机制，使其重新在3秒后执行。这些功能使得HashedWheelTimer在处理I/O超时等延迟任务时展现出强大优势。

       对于HashedWheelTimer的内部实现，它主要包括构造函数、创建轮、任务添加、执行方法和停止方法等关键部分。这些内部机制协同工作，确保了时间轮高效稳定地运行。

       理解多级时间轮的概念时，可以将其类比为时间的多级分层，如小时、分钟、秒的层级结构。在这种结构中，每层的bias划线指标源码轮转代表更长的时间间隔，实现了一种层次化的任务调度机制。

       为了深入了解HashedWheelTimer的实现细节，开发者可以查阅相关源码，如在github上找到的示例代码。通过系统学习后端开发的全栈知识体系，可以进一步巩固对时间轮及其应用的理解。

       告别碎片化的学习方式，采用一站式、体系化的学习路径，是提升后端开发技能的有效方法。通过精进Java全栈知识体系，开发者能够全面掌握关键概念和技术，为职业生涯发展打下坚实基础。

nodejs原理&源码赏析（7）Node.js中的事件循环，定时器和process.nextTick

       事件循环是Node.js的核心机制，确保了其非阻塞I/O模型的实现。尽管JavaScript在Node.js中是单线程运行的，它却能利用系统内核的多线程特性处理并发任务。Node.js在开始执行时初始化事件循环，处理脚本文件或REPL环境中的异步调用。事件循环通过检查异步I/O、定时器和process.nextTick调用，然后进入各个阶段，处理回调函数。每个阶段维护一个先进先出的回调队列，处理与阶段相关操作后执行队列中的回调，直至队列为空或达到最大函数执行数量。系统操作回调、定时器和处理关闭回调的阶段各有功能。setImmediate()与setTimeout()相似，京东小破车源码但执行顺序受调用上下文影响，setImmediate()在I/O周期中通常优先执行。process.nextTick()则在当前操作执行后立即执行回调，不受事件循环阶段限制，但需谨慎使用以防阻塞事件循环。

浅析linux 内核 高精度定时器（hrtimer）实现机制（二）

       分析linux内核高精度定时器(hrtimer)的实现机制时，首先介绍的是定时器的迁移过程switch_hrtimer_base。该函数会尝试选择一个新的hrtimer_cpu_base结构体，用于定时器的激活。get_target_base函数被用于挑选新的迁移位置，这个函数的代码与分析低分辨率定时器层时的定时器迁移概念相似。timers_migration_enabled变量在切换到NO_HZ模式时变为True，退出NO_HZ模式时变为False，用于判断是否可以进行迁移。只有在切换到NO_HZ模式且定时器未绑定到特定CPU的情况下，才会进行迁移选择。get_nohz_timer_target函数会判断当前CPU是否处于空闲状态，如果不是，则返回当前CPU编号，如果是空闲，则会找到最近一个忙碌的处理器并返回其编号。所有条件不满足时，会直接返回传入的hrtimer_cpu_base结构体指针。

       接下来分析hrtimer_callback_running函数，用于检查要迁移的定时器是否正是当前正在处理的定时器。hrtimer_check_target函数则用于检查定时器的到期时间是否早于要迁移到的CPU上即将到期的时间。如果高分辨率定时器的到期时间比目标CPU上的所有定时器到期时间还要早，并且目标CPU不是当前CPU，那么激活目标CPU会涉及到通知该CPU重新编程定时器，这通常不如直接在当前CPU上激活定时器来得简单。因此，如果迁移操作与实际激活操作没有关系，即使从get_target_base函数获得的base与定时器中指定的base相同，迁移操作也会进行。

       在迁移过程中，内核会临时将定时器的hrtimer_clock_base结构体变量设置为全局变量migration_base的指针。这个全局变量仅用于在获得定时器所属CPU的hrtimer_cpu_base结构体变量时，通过判断base变量是否等于migration_base的指针来判断定时器是否正在迁移。这样的设计可以在未正式加锁之前过滤掉很多情况，从而提高速度。

       文章福利提供Linux内核技术交流群，包含学习书籍、视频资料，前名可额外获得价值的内核资料包（含视频教程、电子书、实战项目及代码）。

       内核资料直通车：Linux内核源码技术学习路线+视频教程代码资料

       学习直通车：Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈-学习视频教程-腾讯课堂

       在低精度模式下，高分辨率定时器层通过普通（低分辨率）定时器层驱动。当Tick到来时，其处理函数会调用hrtimer_run_queues函数通知高分辨率定时器层。每次调用该函数时，都会判断是否可以切换到高精度模式。如果可以切换，会调用hrtimer_switch_to_hres完成切换并退出。如果不需要切换，则从时间维护层获得当前时间和各种偏移值，并设置到所有的hrtimer_clock_base结构体中。如果当前时间不早于softirq_expires_next变量的值，表示“软”定时器已到期，需要激活软中断处理程序。在软中断处理程序中，首先调用hrtimer_update_base函数更新当前时间，并在适当时候执行，处理到期的“软”定时器。该处理程序会遍历所有指定类型（“软”或“硬”）的到期定时器，判断定时器的“软”到期时间是否已到，处理到期定时器，并循环取下一个要到期的定时器。最后，会调用hrtimer_reprogram函数对底层定时事件设备进行重编程。

       在高精度模式下，周期处理函数hrtimer_interrupt在定时事件设备到期后调用。处理过程包括激活HRTIMER_SOFTIRQ软中断处理程序，处理所有“软”定时器，并对底层定时事件设备进行重编程。重编程确保设备在到期后能正确触发中断，同时避免在一次中断中处理过多定时器，以防止超时。通过查找和设置到期时间时使用“硬”到期时间，而在处理定时器时使用“软”到期时间，内核能尽量减少中断调用，提高性能。

       低精度模式切换到高精度模式的hrtimer_switch_to_hres函数通过调用tick_init_highres函数实现切换，将定时事件设备切换到单次触发模式，并设置中断处理函数为hrtimer_interrupt。一旦完成切换，底层定时事件设备将始终工作在单次触发模式。切换成功后，必须找到最近到期的定时器，并用其到期事件对定时事件设备进行重编程，确保设备能正确响应到期。

       在高精度模式下，中断处理程序通过直接调用__hrtimer_run_queues函数处理所有“硬”定时器，并激活HRTIMER_SOFTIRQ软中断处理程序来处理所有“软”定时器。在高精度模式下，底层定时事件设备始终处于单次触发模式，因此在到期后必须进行重编程。如果编程失败，重试三次后，适当延迟到期事件后再次尝试编程，并强制执行。

       使用实例展示了高精度定时器在实际应用中的精度，时间戳显示其定时精度可达到ms级别。

iowait 到底是什么？

       在理解Linux中的CPU使用率时，iowait是经常被提及的一个指标。本文旨在探究iowait的定义、计算方式以及它在系统分析中的应用。通常，当iowait值较高时，人们会直观地认为系统可能遇到了IO瓶颈。然而，深入研究后，我们发现iowait实际上是CPU处于等待I/O操作完成的状态时间。这一定义可能并不直观，但通过查阅系统手册，我们找到了更详细的解释。

       iowait的来源可以从系统状态文件中寻得线索，如/proc/stat。通过阅读proc手册，我们了解到各列的定义，从而清晰地理解iowait的计算方式。进一步地，通过反向追踪Linux内核的实现，我们发现iowait状态的记录实际上是基于空闲CPU时间与I/O任务的结合。这种记录方式表明，当CPU处于iowait状态时，仍可能被调度执行其他进程，这与直观理解可能有所不同。

       为了验证上述分析，我们以Linux内核版本v6.5.1为例，通过系统文件和内核源码进行了深入研究。在stat系统文件中，我们发现了实现细节，如get_iowait_time的调用。在tick_sched计时结构体中，我们找到了iowait时间的计算方法。通过判断CPU调度器runqueue信息，我们得知当idle_sleeptime和iowait_sleeptime被计算时，意味着CPU核心在空闲状态下可能处于iowait状态。

       通过实验，我们尝试让系统中的iowait值接近%，并通过启动多个重度IO任务来实现。在该实验中，我们使用了一块机械硬盘作为测试对象，成功地使系统iowait达到了%，而idle状态基本不存在。尽管如此，系统响应并未感受到卡顿，这表明高iowait值实际上意味着系统中有大量CPU空闲时间等待IO操作完成。这一发现提示我们，iowait值高并不一定意味着系统不健康，而是可能表明系统具备处理额外计算密集型任务的能力，或者提示我们优化高iowait的应用程序。

       进一步的实验显示，即使在引入计算密集型任务后，系统的iowait值并未显著增加，而主要集中在计算密集型任务上。这进一步表明了在分析系统IO压力时，需要综合考虑多种指标，如iostat和iotop，以全面评估系统的性能状况。通过结合这些工具的使用，我们可以更准确地判断系统是否存在IO瓶颈，而不仅仅是依赖于单一的iowait值。

       综上所述，理解iowait的含义和其在系统分析中的应用，需要从多个角度出发。通过深入研究内核源码和系统状态文件，以及实际实验验证，我们可以更准确地判断系统性能，避免因单一指标的解读偏差导致的误解。在实际排查IO瓶颈时，综合使用多种工具和方法，将有助于我们更全面、准确地评估系统的运行状况，从而进行有效的性能优化。