cp slows machine
in [Slackware]
|
From: Mike Jones on 13 Dec 2009 18:49 I've noticed a slowdown in things when setting cp to copy chunks of data. This mostly affects resource hungry stuff like Seamonkey, making things feel as if I've lost a CPU. I'm thinking about sticking a 'nice' parameter in my .bashrc for cp Now is the time to say "Argh! Don't do that!" and\or "Try this..." Ideas? -- *=( http://www.thedailymash.co.uk/ *=( For all your UK news needs.
From: Keith Keller on 13 Dec 2009 19:14 On 2009-12-13, Mike Jones <Not(a)Arizona.Bay> wrote: > I've noticed a slowdown in things when setting cp to copy chunks of data. > > This mostly affects resource hungry stuff like Seamonkey, making things > feel as if I've lost a CPU. > > I'm thinking about sticking a 'nice' parameter in my .bashrc for cp > > Now is the time to say "Argh! Don't do that!" and\or "Try this..." Yeah, don't run Seamonkey. ;-) > Ideas? What's your disk subsystem like? LVM? md RAID? SATA, PATA, SAS? What do the various disk testers (e.g. vmstat, iostat) say? Are you swapping at all? --keith -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information
From: tapp on 14 Dec 2009 04:53 Mike Jones <Not(a)Arizona.Bay> [Sun, 13 Dec 2009 23:49:53 +0000] > I've noticed a slowdown in things when setting cp to copy chunks of > data. With "chunks" you mean "100s of MB"? Because once your I/O is saturated, a certain slowdown at interactive desktop level is inevitable, with all OSs. The only way to get rid of this would be using SCSI disks, I guess. > I'm thinking about sticking a 'nice' parameter in my .bashrc for cp That won't help much, but ionice(1) might. Also, check the kernel parameter CONFIG_HZ: setting it to 1000 will get you some more responsiveness, while losing a little throughput. (I don't know if this parameter can be changed without kernel recompile though.) Regards, Arnd
From: Mike Jones on 14 Dec 2009 11:22 Responding to Keith Keller: > On 2009-12-13, Mike Jones <Not(a)Arizona.Bay> wrote: >> I've noticed a slowdown in things when setting cp to copy chunks of >> data. >> >> This mostly affects resource hungry stuff like Seamonkey, making things >> feel as if I've lost a CPU. >> >> I'm thinking about sticking a 'nice' parameter in my .bashrc for cp >> >> Now is the time to say "Argh! Don't do that!" and\or "Try this..." > > Yeah, don't run Seamonkey. ;-) > >> Ideas? > > What's your disk subsystem like? LVM? md RAID? SATA, PATA, SAS? What > do the various disk testers (e.g. vmstat, iostat) say? Are you swapping > at all? > > --keith 2 SATA HDDs and sometimes a fair bit of data transfer across the LAN to and from these disks, and from disk to disk. Have multiple swap files (4) adding up to RAM size, but this "dragging" thing appears with or without swap files or swap partitions. Can't make sense of vmstat or iostat ATM as I'm hungry. ;) -- *=( http://www.thedailymash.co.uk/ *=( For all your UK news needs.
From: Mike Jones on 14 Dec 2009 11:23
Responding to tapp: > Mike Jones <Not(a)Arizona.Bay> [Sun, 13 Dec 2009 23:49:53 +0000] > >> I've noticed a slowdown in things when setting cp to copy chunks of >> data. > > With "chunks" you mean "100s of MB"? Because once your I/O is saturated, > a certain slowdown at interactive desktop level is inevitable, with all > OSs. The only way to get rid of this would be using SCSI disks, I guess. Ah. Now I have a better idea of how things work. Ta. >> I'm thinking about sticking a 'nice' parameter in my .bashrc for cp > > That won't help much, but ionice(1) might. Also, check the kernel > parameter CONFIG_HZ: setting it to 1000 will get you some more > responsiveness, while losing a little throughput. (I don't know if this > parameter can be changed without kernel recompile though.) Didn't even know I had ionice. I'll read up on it and play around with it, see what happens. Cheers! -- *=( http://www.thedailymash.co.uk/ *=( For all your UK news needs. |