Paul and others, Some additional details as requested are:
(i) The stgpool is approx 440GB and spread across 31* 13.5GB LUNs and 3* 72GB internal fibre attached disks. Logs and database are on totally separate LUNs. All LUNs originating from HDS9980V and average read and write times are 10-11ms and 2.5 ms respectively. (ii) No paging out, 8GB memory (~6GB being used by file cache and 1.2GB allocated to application). (iii) Network interface is gigabit with no errors reported and throughput tested using nttcp (results up to 690Mbps achieved). Also flow control enabled so no rx_overflow when multiple clients transmitting data. T'is a mystery... Thanks Sean -----Original Message----- From: Paul Ripke [mailto:[EMAIL PROTECTED]] Sent: 28 January 2003 23:01 To: [EMAIL PROTECTED] Subject: Re: VERY HIGH %SYS CPU On Wednesday, Jan 29, 2003, at 00:11 Australia/Sydney, Broderick, Sean wrote: > Hi, > > The CPU usage (%sys) is extremely high, like 80 - 90%, on the TSM > server > (Sun V880 running TSM v5.1.5) during the backup window. Particularly > when > TDP R3 clients are attempting their SAP backups via backint / brbackup > and > as such the throughput is extremely poor (<9MB/s direct to disk cache > via > gigabit network). How are your disk stgpool volumes configured? Is the system paging? How much RAM do you have? Any errors on your network interfaces? How fast does an ftp run? Since the vast majority of the work done by dsmserv during backups is I/O, a high sys% CPU is to be expected. OTOH, our Sun TSM servers can hit 9 MB/s on 100 Mb ethernet, with much older hardware. Cheers, -- Paul Ripke Unix/OpenVMS/DBA 101 reasons why you can't find your Sysadmin: 68: It's 9AM. He/She is not working that late. -- Koos van den Hout