Speaking of disk I/O... VMS (yes, I always resort to that) has a parameter (settable at both the system level and the user level) that determins the min number of clusters/blocks that are allocated to a file when it requests more disk space [unused blocks are returned to the free list in the master index when the file is closed] so that you have fewer file growths but in a more orderly fashion, hopefully preventing file fragmentation and speeding file growth and I/O [If I said reducing window turns would it mean anything to anyone ?]
Is there an equiv in unix (I'm less familiar with unix ufs/efs/xfs file structure, growth and fragmentation than I am with the other) ? Would it help to utilize those features on the server when receiving the dump files from the clients ? Would it also help when the output device is disk rather than tape ? > I'd expect I/O contention to force lower CPU usage... > > Rather I'd look at the inparallel parameters or the use of > the spindle id number in the disklist (optional 4th field) > to force single threading at least on the server/client if > not on all clients. > > > > > On Mon, Nov 24, 2003 at 10:48:43PM -0500, Eric Siegerman wrote: > > > On Sun, Nov 23, 2003 at 07:46:32PM -0500, Kurt Raschke wrote: > > > > ...when amdump runs, the load spikes to between 4.00 and > > > > 6.00, and the system becomes nearly unresponsive for the duration of > > > > the backup. The server is backing up several local partitions, and > > > > also two partitions on remote servers. > > > > > > Are you short of RAM? If the system's paging heavily, that'd > > > make it crawl too. > > > > No, the box has plenty of ram. > > > > > > > > I've tried starting amdump > > > > with nice and setting it to a low priority, but when gtar and gzip are > > > > started by amanda, the priority setting is somehow lost. > > > > > > Not surprising. Recall that Amanda runs client/server even when > > > backing up the server's DLE's. The client-side processes are > > > descendents of [x]inetd, not of amdump, and so don't inherit the > > > latter's "nice" level. > > > > I realized that about a second after I hit send. However, the more > > that I look at it, I doubt that 'renice'ing tar and gzip will > > help--the box seems to have hard drive issues. I suspect there may be > > a problem with the 3ware RAID card in there, or possibly the driver. > > > > > > > > The server > > > > isn't even trying to back up multiple partitions in parallel, > > > > > > By this do you mean, "only one DLE at a time"; or "only one DLE > > > *from the server* at a time, along with remote backups in > > > parallel"? If the latter, well, of course there's some amount of > > > server-side work even for the remote DLEs. Is the compression > > > for the remote DLEs client- or server-side? If the latter, > > > change "some amount" to "a lot" in the previous sentence :-) > > > > > > > Well, compression is client-side, and not every DLE is compressed, but > > as I recall from the runs the past few nights, the server is usually > > backing up one of the local DLEs as well one of the remote ones at the > > same time. I suppose that if it's trying to store the incoming data > > from the remote client to the HD at the same time it's trying to back > > up a local DLE, that could cause contention for the disk array. I'll > > try moving the holding disk to another drive (not part of the array on > > the 3ware card) and see if that improves things. > > > > -Kurt >
