Since you mentioned network i/o, one thing that "seemed" to help the occasionaly unexplained spike in times with our cluster of WAS -> DB2 was these network settings.
ifconfig hsi0 txqueuelen 1000 (was 100) net/core/rmem_max = 8738140 (was 131071) net/core/wmem_max = 8738140 (was 131071) net/ipv4/tcp_rmem = 4096 873814 8738140 (was 4096 87380 174760) net/ipv4/tcp_wmem = 4096 873814 8738140 (was 4096 16384 131072) You mileage may vary - I don't have any numbers to back them up, but, hey, worth a shot - they can be set on the fly. 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 Eddie Chen Sent: Friday, January 13, 2006 7:28 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] CPU Consumption by ksoftirqd_CPUx processes "softireqd" is part of BH inetrrupts and is mostly used in network releated works. From the "top" report, it seems it can be in a spin lock. Calzaretta Henry - hcalza <Henry.Calzaretta To @ACXIOM.COM> LINUX-390@vm.marist.edu Sent by: Linux on cc 390 Port <[EMAIL PROTECTED] Subject ist.edu> CPU Consumption by ksoftirqd_CPUx processes 01/12/2006 06:15 PM Please respond to Linux on 390 Port <[EMAIL PROTECTED] ist.edu> Hello, We have a WebSphere application running on 4 z/Linux z/VM guests accessing a DB2/UDB V8.2 database running on a separate z/Linux guest. On occasion, the DB2 work will slow to a crawl for several minutes and a "top" command run on the DB2 guest shows most of the available CPU resource is being consumed by tasks called "ksoftirqd_CPUx" (where x is 0-7 representing the number of CPUs defined to the guest) The best I can tell, ksoftirqd is a daemon that does backend I/O interrupt handling. Has anyone seen this situation? Short of not doing I/O, is there anything we can do to tune this situation? Software levels are WAS 5.0.2, DB2/UDB 8.2, SLES8, and z/VM 5.1. Hardware is z900 1Cx with 8-IFLs. Thanks, Hank Calzaretta Acxiom Corp. Tasks: 344 total, 1 running, 343 sleeping, 0 stopped, 0 zombie Cpu(s): 5.0% user, 4.5% system, 0.0% nice, 90.5% idle Mem: 1939124k total, 1936496k used, 2628k free, 64024k buffers Swap: 2094928k total, 359436k used, 1735492k free, 1151176k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20888 db2inst2 25 0 1024 1024 660 R 48.6 0.1 0:06.66 top 16 root 34 19 0 0 0 S 11.8 0.0 93:24.57 ksoftirqd_CPU4 14 root 34 19 0 0 0 S 16.7 0.0 94:15.25 ksoftirqd_CPU2 17 root 34 19 0 0 0 S 15.9 0.0 93:10.27 ksoftirqd_CPU5 12 root 34 19 0 0 0 S 15.6 0.0 96:31.81 ksoftirqd_CPU0 15 root 34 19 0 0 0 S 15.6 0.0 92:59.00 ksoftirqd_CPU3 13 root 34 19 0 0 0 S 13.6 0.0 95:16.56 ksoftirqd_CPU1 18 root 34 19 0 0 0 S 11.8 0.0 92:21.15 ksoftirqd_CPU6 19 root 34 19 0 0 0 S 11.5 0.0 98:58.83 ksoftirqd_CPU7 18815 db2inst2 25 0 168m 165m 159m D 8.1 8.8 0:15.66 db2sysc 15451 db2inst2 15 0 272m 268m 256m D 7.4 14.2 1:01.71 db2sysc 16734 db2inst2 16 0 180m 177m 170m S 5.4 9.4 0:25.78 db2sysc 18816 db2inst2 15 0 157m 154m 147m S 5.4 8.2 0:27.66 db2sysc 18448 db2inst2 17 0 141m 139m 130m S 4.9 7.3 0:29.41 db2sysc 17250 db2inst2 16 0 170m 167m 161m S 4.1 8.9 0:34.68 db2sysc 16378 db2inst2 15 0 45916 41m 34m S 3.6 2.2 0:20.50 db2sysc 18447 db2inst2 16 0 221m 218m 205m S 2.8 11.5 0:36.13 db2sysc 16736 db2inst2 16 0 79868 74m 67m S 2.1 3.9 0:33.28 db2sysc 13573 db2inst2 15 0 196m 193m 183m S 1.8 10.2 0:35.59 db2sysc ************************************************************************ *** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. ************************************************************************ **** ---------------------------------------------------------------------- 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 ----------------------------------------- This message and its attachments may contain privileged and confidential information. If you are not the intended recipient(s), you are prohibited from printing, forwarding, saving or copying this email. If you have received this e-mail in error, please immediately notify the sender and delete this e-mail and its attachments from your computer. ---------------------------------------------------------------------- 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
