I've had computers come in that had *hunderes of megs* of lost clusters..
Win3.1 would create tons if not shutdown properly..
On several ocasions there would be so many *.chk files after running
chkdsk /f that I had to delete them and run chkdsk again for several
passes (because there is a 512 file limit in Fat-16 root dir).
There used to be a disdefraggmenter but I dont think it's maintained.. But
its really not nessassary esp if you keep multiple partitons which have
'like lifetime files' in them.. (like /var /home /tmp / /usr /usr/local
all seperate).
The orignal poster was prob refering mostly to memory leaks.. Which I have
not seen many Linux kernels have.. Also perhaps, the cache or swap system
becomes 'stupid' as the system is running.. Or perhaps kernel memory has
become fragmented and the normal system structures are taking up more then
they should..
If you are expirenceing such rusting, kill off any big apps and compile
this info.. Both at system boot and after slow down:
ps aux
/proc/meminfo
/proc/slabinfo
uptime, kernel version etc..
Also take a look at the ps.. You might just find that something daemon has
become big because of a bug (or incomatiblilty with 2.1)..
A solid test of slowness might be:
time dd if=/dev/zero of=/dev/null bs=8388608 (vary the size depending on
system ram)
Do this at boot and after slowdown.. This prob isn't a good test unless
the system has the same amount free at both times.. It also might be a
good idea to populate the disk cache before the inital test to even out a
few things..
I would guess that there are 'smarter' ways to measure slowdown.. Some
proggies need to be made up.. Before you can fix it you need to mesaure it
to judge improvment.. And 'feel' dosent really cut it..
On Sat, 18 Apr 1998, Gerhard Mack wrote:
>
> On Sat, 18 Apr 1998, Warren Hughes wrote:
> > Rusty .....that's a term I haven't heard to explain degraded
> > performance...but anyways...:)....as a Computer Technician it seems that I
> > see this kind of situation almost on a daily basis....I don't want to
> > sound like I am talking down to you, I'm not...but many
> > times...performance degration is usually causes of end users' not
> > performing routine maintenance on their respective systems...it seems that
>
> I partially agree with this statement, I've seen windoze machines with 30
> megs of lost chains, sure they need to check the drive more often but
> the point is the os shouldn't generate them in the first place.
>
> That reminds me, anyone know of a disk defragmenter for linux ?
>
> > many users think that they just go buy a system and voila, it runs
> > perfectly forever....if we were to treat our vehicles in the same fashion,
> > automakers would control the world...(don't they already?!) Regarding your
> > statement that when you boot into your kernel, performance goes bad, it's
> > probably just because you are trying to run programs that are "memory
> > hogs" and of course, the way to solve that is to increase your RAM and
> > processor power. I know how it is to run at 16 M with a Pentium
> > 120....it's not fun...and it would be different if only coders who write
> > programs wouldn't make them for the 64 M machines that they happen to
> > own...I see that all the time! I currently run 80 M with a 120 MHz
> > processor....I still don't like memory hogs...it's annoying...
>
> It would seem to me that if that was the problem all the user would have
> to do is close everything and the problem would be solved.
>
> To the original poster: Does that work?
>
> --
> Gerhard Mack
> irc admin centurion.starchat.net
>
> gmack@imag.net
> innerfire@starchat.net
>
> As a computer I find your faith in technology amusing.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu