Vraag & Antwoord

OS Linux

waarom swab file

Anoniem
wstolk
14 antwoorden
  • Heb een sloot geheugen in mijn machientje maar hier schrok ik toch wel een beetje van:

    [code:1:990d5b7c9b]
    10:59pm up 14:12, 1 user, load average: 0.54, 0.64, 0.39
    94 processes: 90 sleeping, 3 running, 1 zombie, 0 stopped
    CPU states: 22.8% user, 45.0% system, 0.0% nice, 32.1% idle
    Mem: 771644K av, 751552K used, 20092K free, 0K shrd, 12540K buff
    Swap: 265036K av, 180108K used, 84928K free 559872K cached
    [/code:1:990d5b7c9b]

    Komt dit bekent voor ?

    En wat is jullie verbruik zo'n beetje.
    Moet zeggen dat er wel eea. open stond hoor en ook zware proggie's en ik ben de hele dag al bezig
  • Mijn Debian servertje gebruikt volgens mij helemaal niks :wink:

    [code:1:49ddab44b9]
    23:43:32 up 3 days, 3:57, 1 user, load average: 1.00, 1.00, 1.00
    48 processes: 45 sleeping, 3 running, 0 zombie, 0 stopped
    CPU states: 0.1% user, 0.2% system, 99.6% nice, 0.1% idle
    Mem: 192160K total, 174140K used, 18020K free, 104456K buffers
    Swap: 313228K total, 0K used, 313228K free, 35784K cached[/code:1:49ddab44b9]

    BTW: Celeron 300, 192 MB RAM, alleen server, dus geen X etc.
  • Vergeet niet dat veel pages (bijvoorbeeld shared libraries) in het geheugen blijven staan, zodat ze niet opnieuw geladen hoeven te worden. Lang inactieve pages worden pas eruit gegooit als het vrije geheugen kritisch laag wordt (en dan wordt de boel vaak eerst nog geswapped). Daarnaast wordt een aantal buffers aangepast op het totale/vrije geheugen.

    Mijn uitkomst is (onder X):

    [code:1:2f24d87f3b]
    load averages: 0.14, 0.31, 0.23 07:17:07
    39 processes: 2 runnable, 36 sleeping, 1 on processor
    CPU states: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% idle
    Memory: 51M Act, 3548K Inact, 352K Wired, 174M Free, 256M Swp free
    [/code:1:2f24d87f3b]

    Hoeveel MB is bij jou inactief, wired, etc?
  • [code:1:a51c0bdfa1]
    load average: 0.06, 0.02, 0.00
    55 processes: 54 sleeping, 1 running, 0 zombie, 0 stopped
    CPU states: 0.5% user, 0.5% system, 0.0% nice, 10.7% idle
    Mem: 61900K av, 60112K used, 1788K free, 64K shrd, 8888K buff
    Swap: 32760K av, 13132K used, 19628K free 29896K cached
    [/code:1:a51c0bdfa1]

    AMD 133-K6, 64MB RAM, server (geen X) -> httpd, sshd, telnetd, sftpd, satellited, samba, sendmail, pop3d….


    En zo kan het ook:
    [code:1:a51c0bdfa1]
    load averages: 0.06, 0.05, 0.05 08:46:05
    170 processes: 169 sleeping, 1 on cpu
    CPU states: 99.1% idle, 0.3% user, 0.6% kernel, 0.0% iowait, 0.0% swap
    Memory: 1152M real, 614M free, 473M swap in use, 3098M swap free
    [/code:1:a51c0bdfa1]
    (universitaire server met SunOS 5.8, 8 CPU's als het goed is ofzo…)

    [ Dit Bericht is bewerkt door: greffov op 2002-03-25 08:48 ]
  • Mijn stats:
    [code:1:6a6823b30f]
    9:19am up 11:10, 2 users, load average: 0.80, 0.48, 0.23
    64 processes: 63 sleeping, 1 running, 0 zombie, 0 stopped
    CPU states: 7.0% user, 4.2% system, 0.0% nice, 88.6% idle
    Mem: 62096K av, 59800K used, 2296K free, 0K shrd, 1136K buff
    Swap: 136512K av, 44576K used, 91936K free 22424K cached[/code:1:6a6823b30f]
    Wat mij bij Linux opvalt is, dat als het gebruik van de swap-partitie boven de 70 MB uit komt, Linux significant trager wordt. En dat, terwijl er vaak niet veel applicaties geopend zijn.

    max
  • total: used: free: shared: buffers: cached:
    Mem: 31260672 30359552 901120 0 1310720 22790144
    Swap: 198172672 46833664 151339008
  • Zoals je ziet is ruim 500 mb van je geheugen gebruikt voor je disk-cache. Dit kan dus wel kloppen… (dat je geheugen zo vol zit). Hier moet je je niet druk over maken, tenzij je je computer te langzaam vindt.
  • Maakte me ook niet druk maar zohoog had ik het nooit gehad :wink:

    Machiene werd niet merkbaar trager hoewel Gimp wel wat meer rekentijd vroeg dan verwacht :wink:

    idd die cach is natuurlijk ook heel groot
    Vroeg me eigenlijk meer af hoe de boel voorheen met 128Ram+256Swab altijd zo goed draaide. Maar antwoord ligt dus gewoon in die cache, weer wat geleerd :grin:
  • BTW: Het gaat niet altijd op hoe meer geheugen, hoe sneller. Als je L2 cache niet groot genoeg is voor grote hoeveelheden geheugen wordt het systeem langzamer naarmate je er meer geheugen inzet.
  • [quote:f8c93fc75c]
    Op 25-03-2002 14:25, schreef danieldk:
    BTW: Het gaat niet altijd op hoe meer geheugen, hoe sneller. Als je L2 cache niet groot genoeg is voor grote hoeveelheden geheugen wordt het systeem langzamer naarmate je er meer geheugen inzet.

    [/quote:f8c93fc75c]

    Ach kon ooit eens makkelijk aan 750Mb komen (ik had 256 moest eigenlijk 2x 128 MB kopen heb er 2x 256 van gemaakt)
    dacht toen kan geen kwaad maar win98 heeft er wel een probleem mee win 2000 kan er aardig door vertragen en alleen linux gaat ermee om zoals het hoort. Oftewel volpompen en zomin mogelijk swap gebruiken
    En dat gebeurt dus eigenlijk altijd alleen viel me dit keer op dat er veel swap gebruikt werd maar als je kijkt hoeveel processen er nog gladen staan ….
    Logisch dus eigenlijk :grin:
  • Win '98 komt niet voorbij de 512 MB heb ik begrepen..
    Bij Linux krijg je boven de 1,5 GB geen verdere acceleratie meer als je KDE of Gnome als desktop gebruikt..

  • win98 werkt wel, maar dan moet je eoa optie meegeven in eoa sys.ini ding. weet ik veel hoe dat werkt :grin:

    post dat even in hardware (of windows) als je dat wilt weten…
  • [quote:5f5d359bdf]
    Op 26-03-2002 0:59, schreef Mithrandir:
    win98 werkt wel, maar dan moet je eoa optie meegeven in eoa sys.ini ding. weet ik veel hoe dat werkt :grin:

    post dat even in hardware (of windows) als je dat wilt weten…

    [/quote:5f5d359bdf]

    Wil ik helemaal niet :grin:

    Waarom win98 op mijn bak staat :???:

    Wel pqboot wil fat32 dus… en ik heb een enkel spel dat het echt niet doet met win2000 , en dat speel ik bijna nooit dus als hij het dan 1,5 uur volhoud is het al genoeg :grin:
  • huh? boot ie dan met #MB > 512?
    ik dacht dat dat al problemen gaf!

Beantwoord deze vraag

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.