Re: High CPU running backup

[Jonathan Dill]

I would guess that the "ufsrestore" is making an "index" of one of the 
dumps.  If you don't care about interactive "amrecover" you could make a 
dumptype that doesn't do "index" that should eliminate the ufsrestore 
process.  Running fewer dumps in parallel should help, too.

I don't know a lot about Solaris.  0.0% swap should mean nothing is 
paging, but with 729M swap used, I'd still check out high-memory 
processes, maybe something is leaking memory, but any paging should 
still show up in swap and not kernel I would think.  It looks to me like 
it wouldn't take a lot to make the system start paging heavily from the 
state that it is in with only 13M of real memory free.

Simon Lorenz wrote:

Any suggestions for stopping this would be much appreciated.

load averages:  2.21,  2.21,  2.02
17:48:54
142 processes: 131 sleeping, 5 running, 1 zombie, 4 stopped, 1 on cpu
CPU states:  0.0% idle, 13.7% user, 76.9% kernel,  9.3% iowait,  0.0% swap
Memory: 768M real, 13M free, 729M swap in use, 3911M swap free
  PID USERNAME THR PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
10563 amanda     1  22    0 2232K  936K sleep    5:32 35.03% sendbackup
10476 amanda     1   0   19 2640K 1920K run      2:26 15.04% dumper
10568 amanda     1  32    0   11M 9928K sleep    1:49 12.55% ufsrestore
10572 amanda     1  48    0   11M 2864K run      0:47  5.20% ufsdump
10571 amanda     1  53    0   11M 2864K run      0:48  5.16% ufsdump
10573 amanda     1  48    0   11M 2872K run      0:47  4.64% ufsdump
10574 amanda     1  36    0   11M 3072K sleep    0:32  3.53% ufsdump
10570 amanda     1  48    0   11M 7520K sleep    0:20  1.89% ufsdump
10646 root       1  58    0 2104K 1208K cpu      0:01  0.35% top