Re: Init process consuming CPU
Thanks Rob and Barton. I'm betting that I can attribute this then to the process "t" which is started by cron often. It seems to grow bit by bit until the next recycle and then starts over. It's being phased out, so I'm not going to sweat it :) Let us know if you need some pathological cases. We're good at that.. Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Monday, August 28, 2006 10:45 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Init process consuming CPU The totals is a sum of all processes - the ESALNXP report shows processes above the threshold of .1%. So quite possibly, there are many http servers or java servers using less than .1%. You would NOT want a report that showed all the processes. The other report is the ESALNXA report. This report shows CPU by application. So, for example in this report, all the processes started by process 17860 or 15625 (the parents that spawned these httpd servers) would be accumulated and reportedcu - but a lot of that doesn't show up when you just look at processes using more than .1%. There is soon also to be a ESALNXU report that shows useage by logon userid - in answer to many requests. To further Rob's response. Any process that dies during an interval has their current interval CPU added to their parent. If the parent happens to be init, then "init" cpu grows in the "children". This shows up here. For example, cron starts up, uses some CPU, stops. This cpu gets allocated to init children. Applications don't usually have this scenario. I expect capture ratio currently of processes to be real close to 100%. I expect the '*totals' to be very accurate as well. Rob and others have been providing pathalogical cases to test this - and still rarely find a way to show room for improvement >Date: Mon, 28 Aug 2006 18:20:07 -0500 >Reply-To: Linux on 390 Port >From: Marcy Cortes <[EMAIL PROTECTED]> > >It's consistently 6 and 7% of an IFL on 1 http server. On it's twin on >the other LPAR, it's consistently about 1.5%. So, is there that much >"leftover" because of the httpd processes? We were wondering about the >differences - and also why the velocity numbers don't add up - is that >a >bug?: > >Here's the "twin" ><-Process Ident-> <-CPU Percents->=20 >Time Node Name IDPPID GRP Tot sys user syst usrt=20 > - - - - =20 >18:18:00 LNXC9136 httpd 17876 17860 2454 0.1 0.1 0.0 0.0 0.0=20 > httpd 17872 17860 2454 0.1 0.1 0.0 0.0 0.0=20 > httpd 15651 15625 2454 0.1 0.1 0.0 0.0 0.0=20 > httpd 15650 15625 2454 0.1 0.0 0.0 0.0 0.0=20 > httpd 8063 8057 2454 0.1 0.0 0.0 0.0 0.0=20 > httpd 7926 7916 2454 0.1 0.1 0.0 0.0 0.0=20 > t 2642 2637 2624 0.1 0.0 0.1 0.0 0.0=20 > t 2632 2625 2624 0.2 0.0 0.2 0.0 0.0=20 > rotatelo 2457 2454 2454 0.2 0.2 0.0 0.0 0.0=20 > snmpd 2323 1 2322 0.7 0.5 0.2 0.0 0.0=20 > init 1 0 0 1.6 0.0 0.0 1.2 0.4=20 > *Totals* 0 0 0 5.9 2.1 2.0 1.2 0.5=20 > > > > >Marcy Cortes "If you can't measure it, I'm Just NOT interested!"(tm) // Barton Robinson - CBW Internet: [EMAIL PROTECTED] Velocity Software, IncMailing Address: 196-D Castro Street P.O. Box 390640 Mountain View, CA 94041 Mountain View, CA 94039-0640 VM Performance Hotline: 650-964-8867 Fax: 650-964-9012 Web Page: WWW.VELOCITY-SOFTWARE.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 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
Re: Init process consuming CPU
The totals is a sum of all processes - the ESALNXP report shows processes above the threshold of .1%. So quite possibly, there are many http servers or java servers using less than .1%. You would NOT want a report that showed all the processes. The other report is the ESALNXA report. This report shows CPU by application. So, for example in this report, all the processes started by process 17860 or 15625 (the parents that spawned these httpd servers) would be accumulated and reportedcu - but a lot of that doesn't show up when you just look at processes using more than .1%. There is soon also to be a ESALNXU report that shows useage by logon userid - in answer to many requests. To further Rob's response. Any process that dies during an interval has their current interval CPU added to their parent. If the parent happens to be init, then "init" cpu grows in the "children". This shows up here. For example, cron starts up, uses some CPU, stops. This cpu gets allocated to init children. Applications don't usually have this scenario. I expect capture ratio currently of processes to be real close to 100%. I expect the '*totals' to be very accurate as well. Rob and others have been providing pathalogical cases to test this - and still rarely find a way to show room for improvement >Date: Mon, 28 Aug 2006 18:20:07 -0500 >Reply-To: Linux on 390 Port >From: Marcy Cortes <[EMAIL PROTECTED]> > >It's consistently 6 and 7% of an IFL on 1 http server. On it's twin on >the other LPAR, it's consistently about 1.5%. So, is there that much >"leftover" because of the httpd processes? We were wondering about the >differences - and also why the velocity numbers don't add up - is that a >bug?: > >Here's the "twin" ><-Process Ident-> <-CPU Percents->=20 >Time Node Name IDPPID GRP Tot sys user syst usrt=20 > - - - - =20 >18:18:00 LNXC9136 httpd 17876 17860 2454 0.1 0.1 0.0 0.0 0.0=20 > httpd 17872 17860 2454 0.1 0.1 0.0 0.0 0.0=20 > httpd 15651 15625 2454 0.1 0.1 0.0 0.0 0.0=20 > httpd 15650 15625 2454 0.1 0.0 0.0 0.0 0.0=20 > httpd 8063 8057 2454 0.1 0.0 0.0 0.0 0.0=20 > httpd 7926 7916 2454 0.1 0.1 0.0 0.0 0.0=20 > t 2642 2637 2624 0.1 0.0 0.1 0.0 0.0=20 > t 2632 2625 2624 0.2 0.0 0.2 0.0 0.0=20 > rotatelo 2457 2454 2454 0.2 0.2 0.0 0.0 0.0=20 > snmpd 2323 1 2322 0.7 0.5 0.2 0.0 0.0=20 > init 1 0 0 1.6 0.0 0.0 1.2 0.4=20 > *Totals* 0 0 0 5.9 2.1 2.0 1.2 0.5=20 > > > > >Marcy Cortes "If you can't measure it, I'm Just NOT interested!"(tm) // Barton Robinson - CBW Internet: [EMAIL PROTECTED] Velocity Software, IncMailing Address: 196-D Castro Street P.O. Box 390640 Mountain View, CA 94041 Mountain View, CA 94039-0640 VM Performance Hotline: 650-964-8867 Fax: 650-964-9012 Web Page: WWW.VELOCITY-SOFTWARE.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
Re: Init process consuming CPU
It's consistently 6 and 7% of an IFL on 1 http server. On it's twin on the other LPAR, it's consistently about 1.5%. So, is there that much "leftover" because of the httpd processes? We were wondering about the differences - and also why the velocity numbers don't add up - is that a bug?: Here's the "twin" <-Process Ident-> <-CPU Percents-> Time Node Name IDPPID GRP Tot sys user syst usrt - - - - 18:18:00 LNXC9136 httpd 17876 17860 2454 0.1 0.1 0.0 0.0 0.0 httpd 17872 17860 2454 0.1 0.1 0.0 0.0 0.0 httpd 15651 15625 2454 0.1 0.1 0.0 0.0 0.0 httpd 15650 15625 2454 0.1 0.0 0.0 0.0 0.0 httpd 8063 8057 2454 0.1 0.0 0.0 0.0 0.0 httpd 7926 7916 2454 0.1 0.1 0.0 0.0 0.0 t 2642 2637 2624 0.1 0.0 0.1 0.0 0.0 t 2632 2625 2624 0.2 0.0 0.2 0.0 0.0 rotatelo 2457 2454 2454 0.2 0.2 0.0 0.0 0.0 snmpd 2323 1 2322 0.7 0.5 0.2 0.0 0.0 init 1 0 0 1.6 0.0 0.0 1.2 0.4 *Totals* 0 0 0 5.9 2.1 2.0 1.2 0.5 Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Monday, August 28, 2006 15:44 To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Init process consuming CPU On 8/28/06, Marcy Cortes <[EMAIL PROTECTED]> wrote: > Anyone know why the init process on a server (sles8 IHS 6.0.2 ) would > be consuming this much CPU (or any for that matter)? It's not really the init process itself consuming CPU. The numbers reported are for the children of init. Normally when a process terminates, the consumed resources get accumulated into the parent of the process. When the parent terminates before the child, init becomes the parent of the process and accumulates the resource data. Basically what you see reported against init is the left-over of the last minute. The resource usage of this child process in the previous minutes was reported for the process itself. You might see this happen for example when you stop some daemon process (part of the startup of those services detaches it from the process that started it). So it is just normal. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.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 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
Re: Init process consuming CPU
On 8/28/06, Marcy Cortes <[EMAIL PROTECTED]> wrote: Anyone know why the init process on a server (sles8 IHS 6.0.2 ) would be consuming this much CPU (or any for that matter)? It's not really the init process itself consuming CPU. The numbers reported are for the children of init. Normally when a process terminates, the consumed resources get accumulated into the parent of the process. When the parent terminates before the child, init becomes the parent of the process and accumulates the resource data. Basically what you see reported against init is the left-over of the last minute. The resource usage of this child process in the previous minutes was reported for the process itself. You might see this happen for example when you stop some daemon process (part of the startup of those services detaches it from the process that started it). So it is just normal. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.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
Init process consuming CPU
Anyone know why the init process on a server (sles8 IHS 6.0.2 ) would be consuming this much CPU (or any for that matter)? Screen: ESALNXP Wells Fargo Bank - ME8VM z/VM ESAMON V3.6 08/28 15:54-16:32 1 of 3 LINUX VSI Process Statistics Report NODE LNXE8199 LIMIT 2094 X <-Process Ident-> <-CPU Percents-> nice Time Node Name IDPPID GRP Tot sys user syst usrt valu - - - - 16:32:00 LNXE8199 httpd 15447 15425 2156 0.1 0.1 0.0 0.0 0.0 0 t 2328 2323 2310 0.2 0.0 0.2 0.0 0.0 0 t 2327 2323 2310 0.1 0.0 0.1 0.0 0.0 0 t 2326 2323 2310 0.1 0.0 0.1 0.0 0.0 0 t 2325 2323 2310 0.1 0.0 0.1 0.0 0.0 0 t 2324 2323 2310 0.1 0.0 0.1 0.0 0.0 0 t 2318 2311 2310 0.2 0.0 0.2 0.0 0.0 0 rotatelo 2159 2156 2156 0.1 0.1 0.0 0.0 0.0 0 snmpd 2025 1 2024 0.9 0.5 0.4 0.0 0.0 10 init 1 0 0 7.3 0.0 0.0 6.0 1.3 0 *Totals* 0 0 0 12.0 1.9 2.4 6.2 1.5 0 Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -- 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
Re: Bastille, RHEL 4, perl-Tk, perl-curses
Thanks - The Curses one installed clean and works with Bastille. Tk has some install problems that I will need to look at if ever need it. Enjoyed you sessions at SHARE. Dennis Roach United Space Alliance 600 Gemini Avenue Mail Code USH-4A3L Houston, Texas 77058 Voice: (281) 282-2975 Page:(713) 736-8275 Fax: (281) 282-3583 E-Mail: [EMAIL PROTECTED] All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Post, Mark K Sent: Friday, August 25, 2006 7:33 PM To: LINUX-390@VM.MARIST.EDU Subject:Re: Bastille, RHEL 4, perl-Tk, perl-curses I went to the URL you listed and found these pretty easily: http://www.cpan.org/authors/id/G/GI/GIRAFFED/Curses-1.14.tgz http://www.cpan.org/authors/id/V/VK/VKON/Tcl-Tk-0.90.tar.gz Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Roach, Dennis Sent: Thursday, August 24, 2006 1:31 PM To: LINUX-390@VM.MARIST.EDU Subject: Bastille, RHEL 4, perl-Tk, perl-curses I am trying to run the Bastille script on Red Hat RHEL4. If I try bastille -c, I get: ERROR: Could not load the 'Curses.pm' interface module. This may be due to an invalid $DISPLAY setting, or the module not being visible to Perl. If I try bastille -x, I get: WARNING: /usr/bin/perl cannot find Perl module Tk. The above module(s) is/are required to correctly display the Bastille User Interface. If you are unable to find a pre-compiled module for your OS, they can be found at: http://www.cpan.org/modules/01modules.index.html If you installed the modules in another installation of perl besides the one listed in the error message, you may override Bastille's search path by setting the $CORRECT_PERL_PATH environment variable to the directory that the desired perl binary is located in. Both environment variables are null. I have tried to locate Tk from the above link, the Bastille links (nothing for 390) and CPAN, with no luck. Anyone have an idea. Dennis Roach United Space Alliance -- 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 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
Re: Filesystem type and re-sizing filesystems
On 8/28/06, Carsten Otte <[EMAIL PROTECTED]> wrote: see http://lwn.net/Articles/89560/ I may have branched relatively fast to conclusions, assuming that if ext2 does not allow resizing while mounted, ext3 would not either. The latest activity for ext2resize appears to be 2 years ago for a version of e2fsprogs that is older than the one in my SLES9 and appears to also require a kernel patch. But nothing that says one could not try... Rob -- 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
Re: Filesystem type and re-sizing filesystems
> -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Carsten Otte > Sent: Monday, August 28, 2006 11:40 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: Filesystem type and re-sizing filesystems > > Bernard Wu wrote: > > We are currently running SLES9-SP3. All our filesystems > are type "EXT3" . > > Aside from "REISERFS" , are there other filesystem types >.. > Resize2fs should be part of the e2fsprogs package in sles as > far as I know (I don't have a Sles at hand to verify that). > > with kind regards, > Carsten > -- e2fsprogs is included with SLES. -- 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
Re: Filesystem type and re-sizing filesystems
Rob van der Heij wrote: I hope this does not make you start smoking again, but: lrobv1:~ # resize2fs /dev/dasdd1 resize2fs 1.36 (05-Feb-2005) /dev/dasdd1 is mounted; can't resize a mounted filesystem! lrobv1:~ # cat /proc/mounts | grep dasdd1 /dev/dasdd1 /mnt/0153 ext2 rw,nogrpid 0 0 see http://lwn.net/Articles/89560/ -- Carsten Otte has stopped smoking: Ich habe in 3 Monate, 4 Tage und 32 Minuten schon 460,90 Euro gespart anstatt 1.920,44 Zigaretten zu kaufen. -- 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
Re: Filesystem type and re-sizing filesystems
You can resize ext2 and ext3 filesystems while mounted with ext2online. It's a standard part of RHEL4. I don't know about other distributions. We've used it, and it works fine. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Carsten Otte Sent: Monday, August 28, 2006 12:44 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Filesystem type and re-sizing filesystems Carsten Otte wrote: > I don't know what you mean by "dynamic", but you can resize ext3 > filesystems with resize2fs. There is also a patch that allows online > resizing of ext3 filesystems (that is, resizing while the filesystem > is mounted). I don't know about the state of it, therefore I would > avoid to use it in production environments for the time being. > Resize2fs should be part of the e2fsprogs package in sles as far as I > know (I don't have a Sles at hand to verify that). To avoid misinterpretion: I would feel safe to use resize2fs after backup of a production system, then do an e2fsck -f before going production again. Online resize of ext3 feels too hot for me to use in production systems, but that does also apply to reiserfs in general. with kind regards, Carsten -- Carsten Otte has stopped smoking: Ich habe in 3 Monate, 4 Tage und 10 Minuten schon 460,83 Euro gespart anstatt 1.920,15 Zigaretten zu kaufen. -- 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 If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ -- 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
Re: Filesystem type and re-sizing filesystems
On 8/28/06, Carsten Otte <[EMAIL PROTECTED]> wrote: I don't know what you mean by "dynamic", but you can resize ext3 filesystems with resize2fs. There is also a patch that allows online resizing of ext3 filesystems (that is, resizing while the filesystem I hope this does not make you start smoking again, but: lrobv1:~ # resize2fs /dev/dasdd1 resize2fs 1.36 (05-Feb-2005) /dev/dasdd1 is mounted; can't resize a mounted filesystem! lrobv1:~ # cat /proc/mounts | grep dasdd1 /dev/dasdd1 /mnt/0153 ext2 rw,nogrpid 0 0 IIRC there is a commercial version of resize2fs that does it for a mounted filesystem. Rob -- 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
Re: Filesystem type and re-sizing filesystems
Carsten Otte wrote: I don't know what you mean by "dynamic", but you can resize ext3 filesystems with resize2fs. There is also a patch that allows online resizing of ext3 filesystems (that is, resizing while the filesystem is mounted). I don't know about the state of it, therefore I would avoid to use it in production environments for the time being. Resize2fs should be part of the e2fsprogs package in sles as far as I know (I don't have a Sles at hand to verify that). To avoid misinterpretion: I would feel safe to use resize2fs after backup of a production system, then do an e2fsck -f before going production again. Online resize of ext3 feels too hot for me to use in production systems, but that does also apply to reiserfs in general. with kind regards, Carsten -- Carsten Otte has stopped smoking: Ich habe in 3 Monate, 4 Tage und 10 Minuten schon 460,83 Euro gespart anstatt 1.920,15 Zigaretten zu kaufen. -- 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
Re: Filesystem type and re-sizing filesystems
Bernard Wu wrote: > We are currently running SLES9-SP3. All our filesystems are type "EXT3" . > Aside from "REISERFS" , are there other filesystem types that will allow > for dynamic re-sizing ? I don't know what you mean by "dynamic", but you can resize ext3 filesystems with resize2fs. There is also a patch that allows online resizing of ext3 filesystems (that is, resizing while the filesystem is mounted). I don't know about the state of it, therefore I would avoid to use it in production environments for the time being. Resize2fs should be part of the e2fsprogs package in sles as far as I know (I don't have a Sles at hand to verify that). with kind regards, Carsten -- Carsten Otte has stopped smoking: Ich habe in 3 Monate, 4 Tage und 58 Sekunden schon 460,80 Euro gespart anstatt 1.920,01 Zigaretten zu kaufen. -- 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
Filesystem type and re-sizing filesystems
Hi List, We are currently running SLES9-SP3. All our filesystems are type "EXT3" . Aside from "REISERFS" , are there other filesystem types that will allow for dynamic re-sizing ? Bernie Wu [EMAIL PROTECTED] The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -- 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
