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 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] > > > Links: > ------ > [1] http://www.itconline.com/ > > ---------------------------------------------------------------------- > 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/ > -- 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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
