> If in a virtualized instance... > https://www.youtube.com/watch?v=__n5Bgxx-68
[4]Very well played, Sir! remarkably funny and one of my favorites, too. DJ [4] --- DAVID JONES | MANAGING DIRECTOR FOR ZSYSTEMS SERVICES | z/VM, Linux, and Cloud 703.237.7370 (Office) | 281.578.7544 (CELL) INFORMATION TECHNOLOGY COMPANY [1] On 04.18.2018 7:10 AM, John Campbell wrote: > Buy a clue? That can be expensive depending upon how many vowels are > necessary. :-) > > Look, the sleep call is awkward to begin with... and that's within a C > program! (Since perl uses sleep() it can work more-or-less the same way.) > A sleep(1) call will vary, for instance. Depending upon the system using a > nap(ms) call has its own complications. > > A "sleep 1m" (or, the way I code the command, "sleep 60" since the default > granularity is in seconds) includes a fork()+exec() call and then passing, > on completion, notifying the parent process it can now proceed. > > In a very busy system, the fork()/exec() to LAUNCH the sleep command may be > delayed. (Personally, when working within a system that is loaded down, I > prefer to code a perl script, just to cut down on the fork()/exec() rate.) > So, the need to execute fork() to get a child process launched-- which > starts out as a copy of the existing shell-- can require resources that are > in short supply EVEN WHEN the sleep command renders a teeny process, > memory-wise, so, when the system is loaded down, forking can be impacted > (RAM, CPU, etc) while the exec() call, itself, starts a process with a very > minimal page set and lets page faults load the rest of it. (And, just as a > reminder, the fork() call means the impure "data" and "stack" segments have > to be allocated and copied.) > > So the system is loaded down. > > If this is a virtual instance, however, you may want to investigate whether > the instance is being impacted by OTHER instances where resources are > over-committed. Other instances can't be seen, howsomever, so finding out > if some other instance is stealing your cycles (or putting your instance > into paging space) can be harder to detect. The usual performance > monitoring tools don't work "well" when CPU and RAM are overcommitted. > > YMMV. > > If you are resident in an LPAR you can use internal performance tools: Look > at the top command's output. Run vmstat or even sar. Consider what your > system is doing. > > If in a virtualized instance... > https://www.youtube.com/watch?v=__n5Bgxx-68 [4] > > Finally, while a process is sleeping, it can be pushed out of RAM and then > waking up means you'll have a whole buncha page faults as it tries to get > running again. A virtual instance can have DOUBLE page faults both within > the instance which cause a page fault the hypervisor has to address. > > If you are running an "important" set of processes within a virtual > instance (shakes head). > > -soup > > On Wed, Apr 18, 2018 at 9:36 AM, Dave Jones <[email protected]> wrote: > >> Hello, gang. I have a very simple bash script that runs a trivial data >> collection task, and then does a Linux "sleep im" to wait a minute before >> running the data collection task again. Under very high CPU loads (> 90%) I >> have noticed that the "sleep" command does not seem to wake up after one >> minute but instead wakes up 15 to 20 minutes later. This is on a Red Hat 6.9 >> guest running under z/VM 6.4 on a z12 box. I would like to buy a clue here >> if I could. Thanks. DJ -- DAVID JONES | MANAGING DIRECTOR FOR ZSYSTEMS >> SERVICES | z/VM, Linux, and Cloud 703.237.7370 (Office) | 281.578.7544 >> (CELL) INFORMATION TECHNOLOGY COMPANY [1 [1]] Links: ------ [1] >> http://www.itconline.com/ [1] >> ---------------------------------------------------------------------- For >> LINUX-390 subscribe / signoff / archive access instructions, send email to >> [email protected] with the message: INFO LINUX-390 or visit >> http://www.marist.edu/htbin/wlvindex?LINUX-390 [2] ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ [3] > > -- > John R. Campbell Speaker to Machines souperb at gmail dot > com > MacOS X proved it was easier to make Unix user-friendly than to fix Windows > "It doesn't matter how well-crafted a system is to eliminate errors; > Regardless > of any and all checks and balances in place, all systems will fail because, > somewhere, there is meat in the loop." - me > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 [2] > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ [3] Links: ------ [1] http://www.itconline.com/ [2] http://www.marist.edu/htbin/wlvindex?LINUX-390 [3] http://wiki.linuxvm.org/ [4] https://www.youtube.com/watch?v=__n5Bgxx-68 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
