精华内容
下载资源
问答
  • Linux 进程状态D Disk Sleep

    千次阅读 2020-07-10 22:15:10
    不可中断状态的进程则是正处于内核态关键流程中的进程,并且这些流程是不可打断的,比如最常见的是等待硬件设备的I/O响应,也就是我们在ps命令中看到的D状态(Uninterruptible Sleep,也称为Disk Sleep)的进程。...

     

    Linux进程状态:S (TASK_INTERRUPTIBLE),可中断的睡眠状态


    处于这个状态的进程因为等待某某事件的发生(比如等待socket连接、等待信号量),而被挂起。这些进程的task_struct结构被放入对应事件的等待队列中。当这些事件发生时(由外部中断触发、或由其他进程触发),对应的等待队列中的一个或多个进程将被唤醒。

    通过ps命令我们会看到,一般情况下,进程列表中的绝大多数进程都处于TASK_INTERRUPTIBLE状态(除非机器的负载很高)。毕竟CPU就这么一两个,进程动辄几十上百个,如果不是绝大多数进程都在睡眠,CPU又怎么响应得过来。

     

    Linux进程状态:D (TASK_UNINTERRUPTIBLE),不可中断的睡眠状态


    与TASK_INTERRUPTIBLE状态类似,进程处于睡眠状态,但是此刻进程是不可中断的。不可中断,指的并不是CPU不响应外部硬件的中断,而是指进程不响应异步信号。

    绝大多数情况下,进程处在睡眠状态时,总是应该能够响应异步信号的。否则你将惊奇的发现,kill -9竟然杀不死一个正在睡眠的进程了!于是我们也很好理解,为什么ps命令看到的进程几乎不会出现TASK_UNINTERRUPTIBLE状态,而总是TASK_INTERRUPTIBLE状态。

    而TASK_UNINTERRUPTIBLE状态存在的意义就在于,内核的某些处理流程是不能被打断的。如果响应异步信号,程序的执行流程中就会被插入一段用于处理异步信号的流程(这个插入的流程可能只存在于内核态,也可能延伸到用户态),于是原有的流程就被中断了。

    在进程对某些硬件进行操作时(比如进程调用read系统调用对某个设备文件进行读操作,而read系统调用最终执行到对应设备驱动的代码,并与对应的物理设备进行交互),可能需要使用TASK_UNINTERRUPTIBLE状态对进程进行保护,以避免进程与设备交互的过程被打断,造成设备陷入不可控的状态。这种情况下的TASK_UNINTERRUPTIBLE状态总是非常短暂的,通过ps命令基本上不可能捕捉到。

    不可中断状态的进程则是正处于内核态关键流程中的进程,并且这些流程是不可打断的,比如最常见的是等待硬件设备的I/O响应,也就是我们在ps命令中看到的D状态(Uninterruptible Sleep,也称为Disk Sleep)的进程。

    比如,当一个进程向磁盘读写数据时,为了保证数据的一致性,在得到磁盘回复前,它是不能被其他进程或者中断打断的,这个时候的进程就处于不可中断状态。如果此时的进程被打断了,就容易出现磁盘数据与进程数据不一致的问题。

    所以,不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
     

    linux系统中也存在容易捕捉的TASK_UNINTERRUPTIBLE状态。执行vfork系统调用后,父进程将进TASK_UNINTERRUPTIBLE状态,直到子进程调用exit或exec 通过下面的代码就能得到处于TASK_UNINTERRUPTIBLE状态的进程:

    [root@localhost ~]# cat test.c 
    void main() {  
    if (!vfork()) sleep(100);  
    } 
    
    [root@localhost ~]# gcc -o test  test.c
    
    [root@localhost ~]# ./test 
    
    [root@localhost ~]# ps -aux | grep test
    root      19454  0.0  0.0   4212   352 pts/6    D+   10:02   0:00 ./test
    root      19455  0.0  0.0   4212   352 pts/6    S+   10:02   0:00 ./test

     

    进程为什么会被置于uninterruptible sleep状态呢?


    处于uninterruptiblesleep状态的进程通常是在等待IO,比如磁盘IO,网络IO,其他外设IO,如果进程正在等待的IO在较长的时间内都没有响应,那么就很会不幸地被ps看到了,同时也就意味着很有可能有IO出了问题,可能是外设本身出了故障,也可能是比如挂载的远程文件系统已经不可访问了(由down掉的NFS服务器引起的D状态)。

    正是因为得不到IO的相应,进程才进入了uninterruptible sleep状态,所以要想使进程从uninterruptible sleep状态恢复,就得使进程等待的IO恢复,比如如果是因为从远程挂载的NFS卷不可访问导致进程进入uninterruptible sleep状态的,那么可以通过恢复该NFS卷的连接来使进程的IO请求得到满足。

     

    D状态,往往是由于 I/O 资源得不到满足,而引发等待


    在内核源码 fs/proc/array.c 里,其文字定义为“ "D (disk sleep)", /* 2 */ ”(由此可知 D 原是Disk的打头字母),对应着 include/linux/sched.h 里的“ #define TASK_UNINTERRUPTIBLE 2 ”。举个例子,当 NFS 服务端关闭之时,若未事先 umount 相关目录,在 NFS 客户端执行 df 就会挂住整个登录会话,按 Ctrl+C 、Ctrl+Z 都无济于事。断开连接再登录,执行 ps axf 则看到刚才的 df 进程状态位已变成了 D ,kill -9 无法杀灭。正确的处理方式,是马上恢复 NFS 服务端,再度提供服务,刚才挂起的 df 进程发现了其苦苦等待的资源,便完成任务,自动消亡。若 NFS 服务端无法恢复服务,在 reboot 之前也应将 /etc/mtab 里的相关 NFS mount 项删除,以免 reboot 过程例行调用 netfs stop 时再次发生等待资源,导致系统重启过程挂起。

     

    Nginx举例一则,只是举个例子大概看看就行


    第二客户端机器我们将运行另一个副本的wrk,但是这个脚本我们使用50的并发连接来请求相同的文件。因为这个文件被经常访问的,它将保持在内存中。在正常情况下,NGINX很快的处理这些请求,但是工作线程如果被其他的请求阻塞性能将会下降。所以我们暂且叫它“加载恒定负载”。

    性能将由服务器上ifstat监测的吞吐率(throughput)和从第二台客户端获取的wrk结果来度量。

    现在,没有线程池的第一次运行不会给我们带来非常令人兴奋的结果:

    % ifstat -bi eth2
    eth2
    Kbps in  Kbps out
    5531.24  1.03e+06
    4855.23  812922.7
    5994.66  1.07e+06
    5476.27  981529.3
    6353.62  1.12e+06
    5166.17  892770.3
    5522.81  978540.8
    6208.10  985466.7
    6370.79  1.12e+06
    6123.33  1.07e+06

    如你所见,上述的配置可以产生一共1G的流量,从top命令上我们可以看到所有的工作线程在阻塞io上花费了大量的时间(下图D状态):

    top - 10:40:47 up 11 days,  1:32,  1 user,  load average: 49.61, 45.77 62.89
    Tasks: 375 total,  2 running, 373 sleeping,  0 stopped,  0 zombie
    %Cpu(s):  0.0 us,  0.3 sy,  0.0 ni, 67.7 id, 31.9 wa,  0.0 hi,  0.0 si,  0.0 st
    KiB Mem:  49453440 total, 49149308 used,   304132 free,    98780 buffers
    KiB Swap: 10474236 total,    20124 used, 10454112 free, 46903412 cached Mem
    
      PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME+ COMMAND
     4639 vbart    20   0   47180  28152     496 D   0.7  0.1  0:00.17 nginx
     4632 vbart    20   0   47180  28196     536 D   0.3  0.1  0:00.11 nginx
     4633 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.11 nginx
     4635 vbart    20   0   47180  28136     480 D   0.3  0.1  0:00.12 nginx
     4636 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.14 nginx
     4637 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.10 nginx
     4638 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx
     4640 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx
     4641 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx
     4642 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.11 nginx
     4643 vbart    20   0   47180  28276     536 D   0.3  0.1  0:00.29 nginx
     4644 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.11 nginx
     4645 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.17 nginx
     4646 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx
     4647 vbart    20   0   47180  28208     532 D   0.3  0.1  0:00.17 nginx
     4631 vbart    20   0   47180    756     252 S   0.0  0.1  0:00.00 nginx
     4634 vbart    20   0   47180  28208     536 D   0.0  0.1  0:00.11 nginx<
     4648 vbart    20   0   25232   1956    1160 R   0.0  0.0  0:00.08 top
    25921 vbart    20   0  121956   2232    1056 S   0.0  0.0  0:01.97 sshd
    25923 vbart    20   0   40304   4160    2208 S   0.0  0.0  0:00.53 zsh

    在这种情况下,吞吐率受限于磁盘子系统,而CPU在大部分时间里是空转状态的。从wrk获得的结果来看也非常低:

    Running 1m test @ http://192.0.2.1:8000/1/1/1
      12 threads and 50 connections
      Thread Stats   Avg    Stdev     Max  +/- Stdev
        Latency     7.42s  5.31s   24.41s   74.73%
        Req/Sec     0.15    0.36     1.00    84.62%
      488 requests in 1.01m, 2.01GB read
    Requests/sec:      8.08
    Transfer/sec:     34.07MB

    请记住,文件是从内存送达的!第一个客户端的200个连接创建的随机负载,使服务器端的全部的工作进程忙于从磁盘读取文件,因此产生了过大的延迟,并且无法在合适的时间内处理我们的请求。

     

    展开全文
  • Linux进程睡眠状态disk sleep

    千次阅读 2020-09-21 14:37:15
    Linux进程睡眠状态disk sleep 《Linux-进程管理》 1. Linux进程状态 Running(R):运行或将要运行 Interruptible(S):被阻断而等待一个事件,可能会被一个信号激活 Uninterruptible(D):被阻断而等待一个事件,不会...


    Linux进程睡眠状态disk sleep

    Linux-进程管理

    1. Linux进程状态

    • Running(R):运行或将要运行
    • Interruptible(S):被阻断而等待一个事件,可能会被一个信号激活
    • Uninterruptible(D):被阻断而等待一个事件,不会被信号激活
    • Stopped(T):由于任务的控制或者外部的追踪而被终止,比如:strace
    • Zombie(Z):僵死,但是它的父进程尚未调用wait函数.
    • Deal(X):这个永远看不见

    2. 睡眠状态disk sleep

    Linux进程有两种睡眠状态,一种interruptible sleep,处在这种睡眠状态的进程是可以通过给它发信号来唤醒的,也是可以kill的,进程状态如下

    #cat /proc/[pid]/status
    Name:   sysmgt
    State:  S (sleeping)
    

    另外一种睡眠状态是uninterruptible sleep,处在这种状态的进程不接受外来的任何信号,这也是为什么之前我无法用kill杀掉这些处于D状态的进程,无论是”kill”, “kill -9″还是”kill -15″,因为它们压根儿就不受这些信号的支配。

    #cat /proc/[pid]/status
    Name:   sysmgt
    State:  D (disk sleeping)
    

    进程为什么会被置于uninterruptible sleep状态呢?处于uninterruptible sleep状态的进程通常是在等待IO,比如磁盘IO,网络IO,其他外设IO,如果进程正在等待的IO在较长的时间内都没有响应,那么就很会不幸地被 ps看到了,同时也就意味着很有可能有IO出了问题,可能是外设本身出了故障,也可能是比如挂载的远程文件系统已经不可访问了,我这里遇到的问题就是由互斥锁引起的,比如说我开了8个进程同时访问一个io,访问的时候势必会加锁来保护资源,那么,当一个进程正在访问的时候,其他进程如果在等待锁,那么就会进入disk sleep,当你执行kill,它不会立即响应,当锁满足条件的时候才可能响应信号。https://blog.csdn.net/davion_zhang/article/details/48268319

    3. 场景重现

    # ps -ef | grep vpp
    root     252610      1  0 11:37 ?        00:00:00 vpp -c startup-iperf3.conf
    root     252913      1  0 11:39 ?        00:00:00 vpp
    root     271022 252936  0 14:15 pts/8    00:00:00 grep --color=auto vpp
    
    # cd /proc/252610/task/252610/
    # cat status 
    Name:	vpp
    Umask:	0022
    State:	D (disk sleep)
    Tgid:	252610
    Ngid:	0
    Pid:	252610
    PPid:	1
    ...
    

    以上内容由RToax编写,或翻译、整理自网络。
    展开全文
  • 进程的disk sleep状态与僵尸进程

    万次阅读 2015-09-08 09:25:03
    Linux进程有两种睡眠状态,一种interruptible sleep,处在这种睡眠状态的进程是可以通过给它发信号来唤醒的,也是可以kill的,进程状态如下 [root@lmxe:/home]#cat /proc/949/status Name: sysmgt State: S ...

    先说一下进程的状态

    1.1)Running(R),运行或将要运行
    1.2)Interruptible(S),被阻断而等待一个事件,可能会被一个信号激活
    1.3)Uninterruptible(D),被阻断而等待一个事件,不会被信号激活
    1.4)Stopped(T),由于任务的控制或者外部的追踪而被终止,比如:strace
    1.5)Zombie(Z),僵死,但是它的父进程尚未调用wait函数.
    1.6)Deal(X),这个永远看不见

    睡眠状态

    Linux进程有两种睡眠状态,一种interruptible sleep,处在这种睡眠状态的进程是可以通过给它发信号来唤醒的,也是可以kill的,进程状态如下

    [root@lmxe:/home]#cat /proc/949/status
    Name:   sysmgt
    State:  S (sleeping)

    另外一种睡眠状态是uninterruptible sleep,处在这种状态的进程不接受外来的任何信号,这也是为什么之前我无法用kill杀掉这些处于D状态的进程,无论是”kill”, “kill -9″还是”kill -15″,因为它们压根儿就不受这些信号的支配。

    [root@lmxe:/home]#cat /proc/949/status
    Name:   sysmgt
    State:  D (disk sleeping)

    进程为什么会被置于uninterruptible sleep状态呢?处于uninterruptible sleep状态的进程通常是在等待IO,比如磁盘IO,网络IO,其他外设IO,如果进程正在等待的IO在较长的时间内都没有响应,那么就很会不幸地被 ps看到了,同时也就意味着很有可能有IO出了问题,可能是外设本身出了故障,也可能是比如挂载的远程文件系统已经不可访问了,我这里遇到的问题就是由互斥锁引起的,比如说我开了8个进程同时访问一个io,访问的时候势必会加锁来保护资源,那么,当一个进程正在访问的时候,其他进程如果在等待锁,那么就会进入disk sleep,当你执行kill,它不会立即响应,当锁满足条件的时候才可能响应信号。

    僵尸进程

    当我杀死一个子进程,而父进程又处于disk sleep时,那么子进程就会变为无人收尸的僵尸进程。子进程从运行直至其终止,从内存中移除,但进程描述符仍然保留在内存中(进程描述符占有极少的内存空间)。子进程的状态变成EXIT_ZOMBIE,并且向父进程发送SIGCHLD 信号,父进程此时应该调用 wait() 系统调用来获取子进程的退出状态以及其它的信息。在 wait 调用之后,僵尸进程就完全从内存中移除。因此一个僵尸存在于其终止到父进程调用 wait 等函数这个时间的间隙,一般很快就消失,但如果编程不合理,父进程从不调用 wait 等系统调用来收集僵尸进程,那么这些进程会一直存在内存中。

    根据上面的描述,我们很容易去写一个程序来产生僵尸进程,如下代码:

    #include <stdio.h>
    #include <sys/types.h>
    
    int main()
    {
        //fork a child process
        pid_t pid = fork();
    
        if (pid > 0)   //parent process
        {
            printf("in parent process, sleep for one miniute...zZ...\n");
            sleep(60);
            printf("after sleeping, and exit!\n");
        }
        else if (pid == 0)  
        {
            //child process exit, and to be a zombie process
            printf("in child process, and exit!\n");
            exit(0);
        }
    
        return 0;
    }
    系统中多了一个僵尸进程。但如果等父进程睡眠醒来退出之后,我们再次查看系统进程信息,发现刚才的僵尸进程不见了。

    怎样避免僵尸进程的产生

    不能使用 kill 后接 SIGKILL 信号这样的命令像杀死普通进程一样杀死僵尸进程,因为僵尸进程是已经死掉的进程,它不能再接收任何信号。事实上,如果系统中僵尸进程并不多的话,我们也无需去消除它们,少数的僵尸进程并不会对系统的性能有什么影响。

    那么在编程时,如果能避免系统中大量产生僵尸进程呢?根据上面描述的,子进程在终止时会向父进程发 SIGCHLD 信号,Linux 默认是忽略该信号的,我们可以显示安装该信号,在信号处理函数中调用 wait 等函数来为其收尸,这样就能避免僵尸进程长期存在于系统中了。示例代码如下:

    #include <stdio.h>
    #include <signal.h>
    #include <string.h>
    #include <sys/types.h>
    #include <sys/wait.h>
    
    sig_atomic_t child_exit_status;
    
    void clean_up_child_process(int signal_num)
    {
        /* clean up child process */
        int status;
        wait (&status);
    
        /* store its exit status in a global variable */
        child_exit_status = status;
    }
    
    int main()
    {
        /* handle SIGCHLD by calling clean_up_child_process  */
        struct sigaction sigchild_action;
        memset(&sigchild_action, 0, sizeof(sigchild_action));
        sigchild_action.sa_handler = &clean_up_child_process;
        sigaction(SIGCHLD, &sigchild_action, NULL);
    
        /* fork a child, and let the child process dies before parent */
        pid_t c_pid;
        c_pid = fork();
        if (c_pid > 0)
        {
            printf("in parent process, and sleep for on mininute...zZ...\n");
            sleep(60);
        }
        else if(c_pid == 0)
        {
            printf("in child process, and exit now\n");
            exit(0);
        }
        else
        {
            printf("fork failed!\n");
        }
    
        return 0;
    }   





    展开全文
  • 有些博主,dmesg和/proc/pid/stack信息看不懂就别瞎几把往外贴 贴了你倒是分析一下啊 for example: 我写这篇帖子时我并没有找到合适的解决方案,而是搜索很多内容后发现网上一堆复制粘贴的内容,并没有实质性...

     

    有些博主,dmesg和/proc/pid/stack信息看不懂就别瞎几把往外贴

    贴了你倒是分析一下啊

    for example:

    我写这篇帖子时我并没有找到合适的解决方案,而是搜索很多内容后发现网上一堆复制粘贴的内容,并没有实质性的分析与探讨,反而国外的论坛里这类讨论更多些。

    先说下我的分析,背景是:

    nfs服务端(1台) 内存buff/cache 90%,available 90%,top命令中wa为15左右;存在一定的io负载。

    iotop磁盘总写速率为50M每秒(目前nfs的瓶颈了,我的优化空间可能还不够)

    nfs 客户端(一共15台,即上图错误所在的服务器是其中一台 )  内存信息同服务端,top 命令中wa 30~50左右,cpu利用率很低,load avge 1000+(没看错,就是这么高),客户端上Iotop中读和写总速率才200KB左右

    分析正文:

    客户端iotop读写速率和iowait不成比例,正常情况下读写速率很大才会伴有iowait的发生,此现象说明瓶颈并不是在磁盘io中,应该在网络存储nfs,nfs客户端速率为什么这么低呢,我认为是nfs server端采用了sync模式传输数据,在nfs 的sync模式中出于数据安全性,会依次排队处理客户端的请求,此时nfs客户端多线程程序对nfs目录触发的请求得不到满足,不断增加io负载,造成nfs内存缓冲页数据交换失败(你们就听我扯吧,技术不行,目前只是分析)。

    内存缓冲页数据交换:

    目前对这个名词不怎么了解,感觉和这两个有关(有理解的可以分享一下):

    # sysctl -a | grep dirty | grep ratio
    vm.dirty_background_ratio = 10
    vm.dirty_ratio = 30
    

    这次问题的发生,我并没有修改上图两个值,而是将nfs sync模式改为async模式,因为我觉得这是nfs server端引起的,客户端资源io阻塞,以此来加快传输速度。并且增客户端的timeo项,延长nfs客户端等待时间。

    其实主要问题还是在于nfs-server文件存储数据传输的速率,目前我这边最大写速率为50M/s。如果有更高的配置方式,请留下一些及建议。

    目前我的配置形式:

    Nfs server端配置:
    
    rw,fsid=0,async,no_subtree_check,no_auth_nlm,insecure,no_root_squash
    
    Nfs client端配置:
    
    -o rsize=1048576,wsize=1048576,hard,intr,timeo=5,retry=10

     

    展开全文
  • linux内核模块的强制删除-结束rmmod这类disk sleep进程
  • 线程进入disk sleep状态,gdb 无法attach

    千次阅读 2014-12-05 22:20:04
    设备偶现多个线程在ioctl 的时候,进入disk sleep 状态,暂时无法知道原因
  • Prevent Disk Sleep是一款非常实用的驱动防休眠工具。这款工具主要防止用户的主二级或外部硬盘驱动器或USB在Windows电脑上休眠,可以保证您的数据正常传输。 软件功能 1、Prevent Disk Sleep可以让你的磁盘处于...
  • Uninterruptible Sleep 译文 Uninterruptible Sleep Nov 16, 2015 One of the curious features of Unix systems (including Linux) is the “uninterruptible sleep” state. This is a state that a process ...
  • Disk

    2017-11-23 21:35:00
    一、简介二、其他1)Disk I/O
  • linux下如何杀掉D状态进程

    万次阅读 2017-05-22 12:56:08
    D状态(disk sleep)进程用kill -9命令是不管用的,最简单的方法就是reboot, 除此还可以修改内核,将其进程状态转化为别的状态,然后kill掉。 新建文件夹, cd进去,新建killd.c 文件,代码如下:#include ...
  • 基于树莓派人脸识别智能门禁

    千次阅读 多人点赞 2019-06-29 19:01:11
    3、运行Win32DiskImager、在软件中选择系统镜像(img文件)、然后device(设备)下选择TF卡盘符;4、连接显示器、也可远程桌面控制、给树莓派供电至系统完全装好。 连接树莓派专用摄像头 电器正负极连接树莓派...
  • “D (disk sleep)”磁盘睡眠状态、 “T (stopped)”停止进程、 “X (dead)”死亡状态、 “Z (zombie)”僵死状态等等。 僵死状态是一个比较特殊的状态:当进程退出并且父进程(使用wait()系统调用)没有读取到...
  • 绘图之前先要安装turtle模块 python 2: pip install turtle python 3: pip3 install turtle 1.小猪佩奇: #!/usr/bin/env python2 # coding=utf-8 import turtle as t t.pensize(4) ...t.color((255...
  • Linux电源管理_Hibernate和Sleep功能介绍

    千次阅读 2016-02-15 17:17:11
    Hibernate和Sleep两个功能是Linux Generic PM的核心功能,它们的目的是类似的:暂停使用——>保存上下文——>关闭系统以节电········>恢复系统——>恢复上下文——>继续使用。 本文以内核向用户空间提供...
  • Spark persist MEMORY_AND_DISK & DISK_ONLY

    千次阅读 2019-06-19 11:24:22
    Thread.sleep(1000 * 60 * 10) } } 测试思路,3T 的模型,如果要 cache 住,50G 的 Executor,至少需要 3T * 1024G/T / 50G * 2 = 125个左右。(乘以2是因为 Executor 的 JVM 默认大概会用 50% 的 Host 内存)...
  • linux进程有两种sleep状态,一种是interruptible sleep,处在这种状态的进程是可以接收外部信号的, cat /proc/xxx/status Name: sysmgt State: S (sleeping) 另一种是uninterruptible sleep,处在这种状态的进程不...
  • disk-burnin.sh是我编写的POSIX兼容外壳程序脚本,用于简化磁盘刻录过程。 它仅适用于不包含数据的磁盘,例如新磁盘或正在测试或重新使用的磁盘。 我受到FreeNAS论坛上主题的启发,我想向为该主题做出贡献的优秀人们...
  • <p>My expected behavior would be that I allow it to sleep, and the go routine should run in the background for that duration saving to the disk. <p>Here is the function in question that is being run ...
  • gc cr disk read

    千次阅读 2015-10-12 11:05:13
    You might encounter RAC wait event ‘gc cr disk read’ in 11.2 while tuning your applications in RAC environment. Let’s probe this wait event to understand why a session would wait for this wait ...
  • System Sleep States

    2019-09-03 11:26:34
    System Sleep States是整个系统全局的低功耗模式,用户空间代码无法执行,系统整体活动显著减少。 2 支持哪些Sleep States 总共支持4中睡眠状态,按睡眠深度由低到高依次是: freeze,standby,mem 和 disk。 ...
  • 如何设置/禁用Mac Sleep

    2019-05-15 17:33:47
    # 查看当前系统的sleep状态 $ sudo systemsetup -getsleep Sleep: Computer sleeps Never Sleep: Display sleeps...Sleep: Disk sleeps Never # 禁用计算机的Sleep。 $ sudo systemsetup -setcomputersleep Off # ...
  • 关于might_sleep的一点说明

    千次阅读 2016-03-10 11:21:04
    关于might_sleep的一点说明 这个函数我在看代码时基本上是直接忽略的(因为我知道它实际上不干什么事),不过因为内核中很多函数一开始就会用一下它,为了方便那些正在学习内核源码的网友,本帖专门讨论一下该函数...
  • 最近刚刚做了一份关于电源管理中android系统suspend to disk的实现研究学习报告,最近比较清闲就简单做了整理。 我是基于北京君正jz4780grus开发板做的探究,我将要在这几天按照下面做一个学习报告,其内容如下所示...
  • [20190228]Backup Restore Throttle sleep.txt --//别人的系统提供awr报表,看一下发现Backup Restore Throttle s...
  • 从S0状态进入sleep状态的过程

    千次阅读 2014-02-18 17:07:41
    从S0状态进入sleep状态的过程 ...3、OSPM开始准备系统各个部分进入shutdown状态,包括flush disk cache。 4、OSPM写入sleep type值到PM1x_CNT的SLP_TYPx中。并使能SLP_EN位。 5、系统开始进入Soft off状态。
  • System Power Management Sleep States (C) 2014 Intel Corp., Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt; The kernel supports up to four system sleep states generically(一般), ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 25,607
精华内容 10,242
热门标签
关键字:

disksleep