Vice paměti = více problémů (UPDATE)

25.11.2007 23:37 | Přečteno: 1670× | Linux obecně | poslední úprava: 26.11.2007 22:28

Tak jsem se rozhodl vylepšit si můj pomalu zastarávající počítač. Volba padla na upgrade RAM, hlavně kvůli tématu mojí bakalářské práce (virtuální mašiny přecejen něco spotřebují). Dneska jsem ale při instalaci narazil na kopu problémů, které netuším, jak ideálně vyřešit.

Jak jste se mohli dočíst v odkazovaném článku, mám desku ASUS P5B-VM. Tato deska má ohromné limity, pokud jde o práci s větším množstvím paměti, jak jsem se dneska sám přesvědčil. Koupil jsem si 2x2GB RAM a nasadil do počítače. Jaké ale bylo moje překvapení, když jsem zjistil, že podle BIOSu 2048+2048=2800(+-50MB). Když jsem přidal ještě původní 1GB, dostal jsem se cca na 3800MB. Nutná otázka jistě zní: kde je sakra to jedno gigo?

Trochu jsem se pošťoural v BIOSu a povedlo se mi najít vlastnost Memory remapping a najednou byla všechna paměť k dispozici. Zaradoval jsem se a bootoval do systému. To by to ale nebyla realita, kdyby v tom nebyl háček. V tom BIOSu sice psali, že povolení Memory remappingu doporučují pouze na 64bit systémy, ale říkal jsem si, že většina výrobců zřejmě zná pouze systémy od MS, kde na 32 bit systému na 3GB paměti prostě končíte, a možnost jsem povolil. Ale najednou mi linux při bootu resetnul PC. To se opakovalo ještě několikrát. Sám nechápu, jak jsem dokázal nabootovat až do KDE. Log samozřejmě mlčel, není v něm ani tečka o nějakém problému. Ale to nebylo všechno, systém mi navíc přestal detekovat mou druhou síťovou kartu, připojenou na konektor sběrnice PCI. Nebyla vidět prostě ani ve výpisu lspci. Problém dočasně řeším přechodem zpět na vypnutou možnost Memory remappingu, ale rozhodně to neberu jako stálé řešení.

Chtěl bych se proto zeptat: jak byste řešili situaci? Evidentně mám následující možnosti:

• upgrade na 64bit systém: o tomhle uvažuju jako asi o nejlepší variantě, ale nechci provádět formou reinstallu, takže kdyžtak nevíte někdo, jak upgradovat Kubuntu z 32bit na 64bit bez nutnosti reinstalace?
• flash BIOSu: zde si nejsem ani trochu jistý, jestli pomůže (navíc nemám disketovku, abych z ní ten flash provedl )
• koupě nové desky: máte někdo zkušenosti s nějakou deskou, která je ozkoušená na 5GB RAM a nedělá podobné problémy:

UPDATE:
Tak jsem zkusil vypálit 64bit systém a instalovat. Nabootoval jsem LiveCD, spustil instalaci. Ale došlo k podobnému zatuhnutí jako u 32 bit systému (prostě se to restartovalo). Nicméně po restartu se mi podařilo bootnout starý systém s celými 5GB paměti. Začal jsem tedy pátrat, kde by mohl být problém. První, co mě napadlo, byl memtest.
S memtestem nemám moc zkušenosti, tak jsem ho pustil nejdříve na první 2GB modul - bez problému. Přešel jsem tedy na druhý modul - bez problému. Alespoň tedy doufám, odvodil jsem si, že memtest prostě ty testy pořád dělá dokola, proto mi tam běželo několikrát to samé. Přešel jsem tedy na test, kdy jsem zapojil paměti do dual-channelu a pustil memtest. Hned v prvním testu se vyskytlo cca 5 chyb (zajímavé bylo, že se jevily být mimo adresní prostor paměti). Při opakovaném provedení testu už se chyba nevyskytla, ale po rebootu stroje tam byla znova. Zkusil jsem tedy paměti zapojit do single-channelu - bohužel se stejným výsledkem.
Když jsem chtěl znovu nabootovat 32bit Kubuntu, opět došlo na padání systému, to skončilo opět až po nastartování 64bit systému a dalším restartu do staré 32bit verze. Teď momentálně jsem v té 32bit se 4GB RAM.
Vyvstaly tedy další nutné otázky: co to bylo za chybu v tom memtestu, že nešla replikovat? Myslíte, že je nějak možné, aby 64bit systém nějakým způsobem dočasně "opravil" chybné sektory v paměti, když 32bit šel nabootovat teprve po nabootování 64bit systému a následném restartu? Po Manipulaci s pozicí pamětí ve slotech bylo třeba opět rozjet 64bit systém, aby šel potom nabootovat 32bit.

       

Anketa

Komentáře

[Ilfirin]

Tak ten upgrade bez reinstalu si myslím, že ani smykem. Spíš si zazálohuj /home a nainstaluj 64bitové KUbuntu od nuly. NAhraj zpět /home a měl bys být tam, kde jsi byl (po doinstalování aplikací).

[frEon]

spis si dat /home na jinej oddil?
proc nechces preinstall?? stejne by se zmenilo 99% vseho co v tom systemu mas, takze nakonec by bylo s upgradem vic prace, nez s novou instalaci.

[JZ]

Jj, /home mam na jinem oddilu, takze v tom by problem vubec nebyl. Do reinstalu se mi nechce hlavne protoze mam ruzne po systemu pohazene specialne upravene konfiguracni soubory a programy a nevim, jestli bych tu konfiguraci zase dal potom dohromady tak, jak byla :-/

[Ilfirin]

Tak to je otázka. Nicméně i /etc je do značné míry (ne-li úplně) univerzální.

[disorder]

/etc si zalohuj, /home sa ani nedotkni, dpkg --get-selections > file ; dpkg --set-selections < file

[Josef Kufner]

Ale notááák.. vždyť stačí změnit zdroje balíčků, udělat apt-get clean a v aptitude pak zmáčknout velké L...

[frEon]

myslis ze to dopadne dobre? ja bych se toho bal...

[JZ]

No neco takoveho bych potreboval, akorat prave nevim, jestli mi to neslozi system

[Jan Grmela]

Mám tu nový Thinkpad X61 a i s nejnovějším BIOSem bylo v Slaxu vidět jen něco málo přes 3 giga paměti, musel jsem tedy nainstalovat 64-bit Linux, jinak bych to "poslední giga" nedokázal využít. Vždycky jsem si myslel, že omezení 32-bit platformy jsou 4 giga, ale jak vidno, tak tomu tak opravdu nebude. Že by první pořádý důvod pro přechod na 64 bitové operační systémy?

[Radek Hladik]

Limit na 32 bit platformě je opravdu 4GB, ale kvůli různým mapováním atd systém vidí jen něco přes 3GB. Jedna z možností je nainstalovat kernel s zapnutým PAE. Pak jsou k dispozici všechna 4GB. Dokonce i více, jen jeden proces nemůže používat víc jak 4GB. Někteří škarohlídové tvrdí, že PAE je pomalejší, ale podle mého testování, je někdy dokonce i rychlejší.

A upřímě řečeno, nevím, odkud je informace, že MS systémy se 4GB končí, dle mých zkušeností naopak 32bit WinXP prostě zapne PAE a ani nekvákne...

Radek

[Luk]

Někteří škarohlídové tvrdí, že PAE je pomalejší, ale podle mého testování, je někdy dokonce i rychlejší.

Rychlejší než co? PAE má svoji režii, protože se musí vytvářet a rušit mapování fyzické paměti do okna ve virtuálním prostoru.

[Radek Hladik]

Rychlejší než bez PAE. Dělal jsem si tu jednoduché benchmarky - openssl speed, bzip, php, mysql inserty-selecty, http stress atd... A zkoušel jsem různé varianty kernelů - PAE, nePAE, SELinux, 64bit... A v některých testech byl PAE kernel až o 20% rychlejší, než kernel bez PAE. Používal jsem standardní Fedoří balíčky a rozdíl v .config byl opravdu jen v tom PAE. Chápu, že teoreticky by to mělo být pomalejší, protože PAE má nějakou režii, ale jestli je ten kód s PAE lépe napsaný nebo něco tu režii vyvažuje... Například ten openssl speed byl víceméně srovnatelný (rozdíl max 1-2% ve prospěch PAE), ale mysql, http stress i php sktript, který v paměti seřadil 1.5GB velké pole, dělaly rozdíly 20-30%.

[Luk]

ale jestli je ten kód s PAE lépe napsaný nebo něco tu režii vyvažuje

Jak by mohl být lépe napsaný? Např. kmap() v jádře bez PAE pouze převede fyzickou adresu na virtuální (konkrétně logickou), kdežto tatáž funkce v jádře s PAE v první řadě rozhoduje, jaké adresy se to týká. Pak pro dolní paměť provede převod adresy, kdežto pro horní musí vytvořit mapování, což se navíc dělá pod uzamčením (čili na víceprocesorových strojích to může dále zdržovat).

[Radek Hladik]

Taky si myslím, že by to mělo být s PAE pomalejší, ale měření to nepotvrdilo. Jestli je to tím, že ten kernel s PAE dělá ještě něco jiného jinak, jestli to nějak lépe zoptimalizuje procesor nebo jestli byla chyba v měření, to nevím. Každopádně jsem se snažil chybu v měření co nejvíce eliminovat a výsledky vypadají vcelku smysluplně. Čistě CPU intesive věci (openssl speed a bzip (celý testovací soubor jsem nejprve nacachoval do paměti, abych vyloučil vliv HDD)) měly výkon víceméně stejný. Věci, kde běží více procesů nebo se "zuřivě" šahá do paměti (PHP a řazení velkého pole), s PAE dosahovaly o 20-30% víc. Jak jsem psal v reakci dole, účelem testu bylo pouze porovnat jednotlivé kernely a rozhodnout, který kernel používat na serverech, které mají 4GB.

[Lu-Tze]

Při všech těch testech bylo k dispozici stejné množství paměti?

[Radek Hladik]

Hardware byl samozřejmě stejný, tedy množství HW paměti bylo pořád stejné - 4GB. Množství dostupné paměti pro procesy se samozřejmě lišilo podle toho, kolik systém "viděl". Ale všechny testy jsem dělal po čistém rebootu a dával jsem si pozor, zda využití paměti nepřesáhne 3GB (pro jistotu). A to bylo to, co jsem potřeboval zjistit. Tedy jaký kernel použít na stroji, který ma 4GB paměti.

[Lu-Tze]

V těch 3 GB byla i cache? Jediné vysvětlení podle mě je to, že některé testy prostě měly k dispozici víc paměti. Kdybys to vyzkoušel na fyzických 3 GB paměti, tak není možné, aby systém s PAE byl v něčem rychlejší.

[Radek Hladik]

Dyť píšu, že systém měl 4GB HW RAM, tedy 2x 2GB modul. Ani s diskovou cachí to něprekočilo využití paměti 3GB a mám pocit, že L1 i L2 cache na pentiu pokrývají celé 4GB. Jo a abych nezapoměl, jednalo se o dvoujádrový procesor, což by mohlo PAE spíš poškodit. (Ano, všechny kernely jely v režimu SMP) Dokonce jsem to zkoušel už i na quadru a výsledek byl přesně odpovídající. CPU intesive věci zrychlily přesně podle frekvence (quaddro mělo 3GHz místo 2.8GHz dualcore), http stresy zrychlily o dvojnásobek a fous (t.j. dvakrát více jader a vyšší frekvence)

[Lu-Tze]

Já vím, že to píšeš. Ale někde prostě musí byt chyba.

[Radek Hladik]

Ty testy jsem dělal poměrně pečlivě a snažil jsem se vyeliminovat všechno možné, aby mi zůstalo čistě jen PAE vs. nePAE vs. 64bit (tam je trošku težší, tam jsem musel nainstalovat i 64bit fedoru). Například při http zátěži, kdy server na localhostu odpovídal jednoduchou statickou stránkou, tak nePAE kernel dělal v průměru 3592 transakcí/s, zatímco PAE kernel 3959 trans/sec.

PHP script, který vzal řetězec, udělal z něj hash (md5 kvůli rychlosti), insertnul ho do databáze, a znovu hash a znovu do databáze a to celé asi milionkrát, tak na nePAE kernelu bežel 418s, ne PAE kernelu 385s. (Po každém testování jsem DB zničil a znova vytvořil). Zatímco čisté počítání md5 na nePAE dělalo 416MB/s, tak s PAE 417MB/s.

[Luk]

Ono to zřejmě bude právě tím, že tam jsou ty 4 GB (plně využitelné jen s PAE). Každé zvětšení využitelné paměti je u Linuxu velmi znát na výkonu. Systém se může i velmi krátkodobě dostávat do stavů, že není dost paměti. Jádro to řeší různými využitelnými cestami (zmenšování cache stránek, zmenšování rezerv ve slab alokátorech, odkládáním stránek do swapu apod.), vždy ale pochopitelně s drastickou ztrátou výkonu.

[Radek Hladik]

To se mi taky moc nezdá. Když systém čistě nabootuju, spustim mysql, apache a jednoduchou php stránku s jedním selektem, tak nemůže využití paměti ani chvilkově včetně cachí přesáhnout ty 3GB. Celá instalace zabírá na disku 1.8GB, i kdyby z toho při bootu do file cache načet 20%, tak je to furt 400MB....

[Luk]

Jestli to byla Fedora, tak ta dělá při startu read-ahead (přednačítání) všeho možného i nemožného. Takže se mohlo natáhnout do paměti kde co. A co se týká MySQL, tak tam je také možné všechno.

[Radek Hladik]

Jojo, ale mám pocit, že to bych v topu někde viděl

[Jan Grmela]

Informace o 3G omezení je FUD. Jak ale vznikl? Jednoduše, na microsoftích stránkách se píše, že PAE není zapnuto automaticky, ale jen pokud je předán jádru parametr \PAE. Další možností, která povolí PAE kernel je zapnutí podpory No Execute bitu a to buď softwarové nebo vynucené hardwarem.

Obyčejný uživatel tyto věci většinou neví a tak se potom diví, proč jeho Windows vidí jen něco kolem 3 GB RAM.

[trekker.dk]

Vice paměti = více problémů

Jo, mě to povídej - od té doby, co mám v počítači 1GB RAM a historicky jenom 1GB swap oddíl mi tuxonice každou chvíli řekne, že nemohl uspat, protože nemá dost místa. Přitom je to blbost, protože

- polovina swapu je většinou volná a víc než polovinu paměti zabírají cache, které pro uspání nepotřebuje (může je zapsat na disk třeba)

- mám vyzkoušené, že vypnutí swap oddílu způsobí, že 500MB zabraného swapu se změní na tak 50MB zabrané paměti navíc, takže zabraný swap se nechá uvolnit

- komprese při suspendu funguje docela dobře, takže i kdyby neměl dělat nic jiného, do místa na swap oddíku se musí vejít.

Samozřejmě tohle je ten lepší případ, který se nechá ručně vyřešit a opakovaný pokus už uspěje. Bohužel momentálně se mi častěji stává, že počítač zamrzne s Seeking to free xxxMB of memory.

[jam001]

Tiez nemam disketovu mechaniku a flashnut bios isiel aj z cdrom. Pri starte stacilo stlacit alt+f2 a bios sa snazi najst novy bios na disketovke a cdrome, navyse ak najde medium tak vypise aj nazov suboru, ktory hlada (ak nie je na cdrome). Kedze subor stiahnuty zo stranky vyrobcu nezodpovedal tomuto nazvu, musel som ho premenovat. Mam asus p5p800-vm a subor, ktory hladal bol P5P800VM.ROM

Ak sa nemylim, tak je to postup pre pripad, ked sa "pokasle" bios a predpoklada sa, ze pouzijes bios z cd, ktore bolo k doske.

[Milan Jurik]

Chces-li vsechnu tu pamet vyuzivat, tak bud PAE mod ci 64-bit system. Proste nekam se v tom adresnim prostoru to PCI mapovat musi. To neni deskou ci BIOSem, to je architekturou PC.

[avip]

Tak nějak...

Vzdor populární víře, druhdy slavných 640kB nemělo ani tak co do činění s MS jako spíš s IBM... protože konstrukce železa a způsob, jak se mapuje paměť byla plně v rukou IBM a Moft +/- přišel v tomto směru k hotovému.

[JZ]

No samozrejme, ze to je architekturou PC. Me je spis divne, ze si to namapuje tak divne, ze to potom ze systemu neni videt. Nicmene kernel mam zkompilovany s podporou az 64GB pameti, takze v tom by problem byt nemel.

[Milan Jurik]

Je mozne, ze to BIOS te desky proste nezvlada spravne namapovat, dost mozna vubec nepocita, ze by nekdo na te desce pouzival PAE mod (ovsem jak se pouziva PAE na Linuxu netusim). Asi bych zkusil prejit na multiarch, jadro 64-bit, pripadne par aplikaci 64-bit (problematicke je rozhrani pro wifi a pro v4l, ty nejsou zrovna multiarch friendly) a zbytek nechat 32-bit. Takovy Debian pro to podporu ma.

[qk_]

Mam stejnou desku a 6GB pameti a se 64bitovym systemem to jede uplne v pohode.

[Jan Drábek]

kdysi jsem se rozhodl nainstalovat z chrootu 32bitového debianu 64bit gentoo... což jsem si uvědomil až když to začalo hlásit chyby....

Stačí nainstalovat AMD64 jádro a knihovny pro základní knihovny (je to v repozitářích)

[kotyz]

Upgrade BIOSu a nasledne instalace 64bit OS.

Flashovat by melo jit i bez disketovky, ikdyz je to prace navic.

[Jan Grmela]

Někteří výrobci dokonce už zveřejňují své BIOSy ve formě ISO obrazu bootovacího CD. Že to trvalo...

[depka]

a nepomohlo by skompilovat jadro s CONFIG_HIGHMEM4G nebo rovnou CONFIG_HIGHMEM64G ?

[JZ]

mam zkompilovano s 64G, ale problemy to delalo i s tim 4G :-/

[stativ]

A důvod? V tomhle místě je jakási „díra“ kam se mapují PCI irq atd. Je to tedy problém architektury. Možná by to šlo obejít použitím memmap-u či jak se ten parametr jádra jmenuje, ale dokumentace o něm prakticky není.

[Kvakor]

Presneji receno, mapuje se tam hlavne pamet a MMIO (memory-mapped I/O) PCI zarizenich (putna, jesli na desce nebo na PCI/AGP/PCIe karte). Klasicky pripad je pamet graficke karty, buffery radicu, sitovek a TV karet, AGP apertura, APIC a IOAPIC, ACPI tabulky a podobne (doporucuju protudovat /proc/iomem). Navic samotny operacni system se take musi kamsi namapovat, takze bezne reseni na 32bit systemech je prave system 3GB pamet pro aplikace/!GB pro mapovane pameti, IOMMU, jadro, obvladace a podobne.

[JZ]

Jj, ja vim, ten pomer se da dokonce nekde nastavit, uz jsem na to narazil

[Luk]

Ale ten výchozí je vcelku rozumný. Rozhodně lepší než (možná nepatrně technicky jednodušší) dělení 2G/2G použité ve Windows.

[CET]

Na Debianech musime pouzivat jadro 2.6.18-5-686bigmem. V ubuntu jsem zadnou "bigmem" variantu nenasel, ale jadro "server" ma zapnutou podporu vice pameti. Tak to leda zkusit jeste s tim original Ubuntu jadrem, pripadne, zkusit malou partisnu pro debian se "686bigmem" jadrem (jenom na test). Ne ze bych neveril Ubuntu nebo tobe (kdyz sis kompiloval vlastni jadro), ale Debian stable je pro me proste referencni distro o stavu HW

[mimi.vx]

flashnui bios a prejdi na 64 bit.........