[OT] Linuxova distribuce pro rourt 486?

[Josef Štengl]

> btw nevi tu nekdo proc u techto distribuci neni prikaz TOP? Chtel sem 
Je moc velky a z toho duvodunahraditelny? aktualni/celkove zatizeni se
da pri trose snaze vycist z /proc/uptime - cim mensi rozil, tim mene
vytizeny system. 

> zjistit jak presne je na tom ten CPU s vykonem kdyz treba spustim na 
> tech PC za routerem nejake P2P (spousta pripojeni najednou) a neuspel 
> sem. Cosi se da zjistit z load average (je i v tom web configu), ale 
> nevim presne co ty 3 cisla znamenaji. Vim ze to ma byt prumerna zatez za 

U load average je to to dane cislo deleno poctem procesoru. 

Zmanualove stranky o /proc (preklada to nebudu pac jsem linej a mohl by
utrpet vyznam)
<cite>
The first three fields in this file are load average figures giving the
number of jobs in the run queue (state R) or waiting for disk I/O (state
D) averaged over 1, 5, and 15 minutes. They are the same as the load
average numbers given by uptime(1) and other programs. The fourth field
consists of two numbers separated by a slash (/). The first of these is
the number of currently executing kernel scheduling entities (processes,
threads); this will be less than or equal to the number of CPUs. The
value after the slash is the number of kernel scheduling entities that
currently exist on the system. The fifth field is the PID of the process
that was most recently created on the system.
</cite>
Je to k /proc/loadavg, prvni tri cisla jsou stejne.


Tady to hezky popisujou 

Optimally, then, you want to have the load average stay below the number
of CPUs in your machine.  So, on a dual box, it's best if the load
average is below 2.

Actually, processes waiting on I/O are counted in the load average,
which is why it spikes when an NFS server is down, a disk goes
off-line, or a box just gets insanely I/O bound.

When the load average goes over the number of CPUs on the system, this
means that there are tasks left sitting and waiting for CPU time.  This
may or may not be a problem depending on what the system is doing, how
good the kernel scheduler is, and other things.  For example, if you're
running something like distributed.net or SETI@home, your load average
will never go below the number of processes you've got running for those
projects; this isn't a problem because the priority for those tasks is
low and there's no deadline for finishing those tasks.

So there's no magic rule about load averages.  You could have two
single-CPU boxes, and the one with a 1.5 load average could perform much
worse than the one with a 4 load average.  I've heard of boxes with load
averages in the three-digit range (before the decimal) that are still
usable.

Incidentally, the same information that's displayed in /proc/loadavg is
also displayed with the "uptime" command; the output from that command
is pretty standard, so your code will be more portable if you parse
uptime's output instead of parsing /proc/loadavg.


Takze snaha je ty cislika dostat pod jedno na procesor, jinak mame
prilis vytizen system nebo nam neco neposloucha a ceka to za se to
vyresi (naprikad se sto snazi zapsat preze NFS, ktere jsem mu zakrene
ukonicil, takze jeden proces porad ceka jestli se server nahodou
nevzpamatuje, cisilko je prez jedna, ale na system to nemam zadny
vyznamny vliv (rychostne)) No snad moc nekecam, ale tohle tem je do jine
konfery (linux@linux.cz).

Me se obcas na routru
kousne disk a tohle cisilko by me mimo jine zajimalo, ale nemam sanci se
tam dostat pac me to odmita prihlasit. Ale vesele si to routuje dal.)
ced