Verte mi, že keby som dokázal veci pomôcť, rád to urobím. Nie každý je dostatočne zdatný, aby mohol linuxu pomôcť technicky ako programátor. Ja sa skôr snažím presadzovať ho medzi užívateľmi vo svojom okolí.
Nemajte mi to za zlé, (zrejme málo vidím do problematiky) ale myšlienka "dohodneme sa na zmene" vo mne vyvoláva obavy, že žiadne pozitíva nebudú ale že to zasa bude o tom, že niekto to implementuje a niekto nie.
Je pravda, ze za nektera vylepseni by clovek rad nekoho nakopal do riti. Treba namontovat /tmp na tmpfs mohl jenom debil. Clovek pak zjistuje, proc najednou nemuze vypalit CD nebo neco nainstalovat a jak je mozne, ze nema misto v /tmp, kdyz je na disku mista dost a jak to hlavne zmenit zpet. A jeste pak najednou zjisti, ze po te, co jsou docasne soubory zpet na disku, je stroj o velky kus rychlejsi, zejmena na starem stroji se prestane plazit GUI. Alespon, ze tohle v pripae /run snad nehrozi.
Tak tady je otazka, kde pro vas nebo pro vyvojare zacinaji stare systemy. Pokud cokoliv, co je starsi nez pul roku, tak tedy ano, P 4 s 2GB pameti je stare, P III se 196 MB pak tretihorni. Ovsem pokud ficura, jako presun tmp do tmpfs vyzaduje 32 GB pameti a nejnovejsi osmijadro na 15 GHz, tak je asi neco nekde spatne.
1. Nekdo testoval, u kolika % uzivatelu to je lepsi? Testoval to nekdo na slabsich strojich nebo jenom novych? A kolik % budeme pozavazovat za dostatecne na to, abychom to natvrdo, bez ptani prestelovali? Jestlize to zpusobi potize pouze 1/4 uzivatelu, je to porad moc. Krome toho, instalator by mohl alespon zjistit velikost pameti, protoze ne kazdy ma 16 GB a na strojich s mene pameti mit default na disku. Aby se nestavalo, ze se neda vypalit CD nebo treba vygenerovat initrd. Treba netbooky maji typicky 1 GB pameti a nebeha jich po svete malo. Notebooky mivaji vic, ale casto to ma k 16 GB daleko.
Trvalo mi chvili, nez jsem vygoogloval, o co go. Zretelne jsem s tim problemem nebyl jediny, ale vsichni si akorat stezovali, tech, co nabizeli reseni, bylo pomalu. Predstavte si BFU s Linuxem, jak se mu tohle stane a reseni je utajeno nekde hluboko v databazi Google. Tak takto Linux mezi BFU moc nedostaneme.
2. Kdyz jsem mel /tmp na disku a nekdo se rozhodl, ze je lepsi v pameti, povazoval bych za inteligentnejsi, aby mi to instalator oznamil, ze mi hodla zmenit zavazne nastaveni a eventuelne mi dal na vybranou a rekl, kde dane nastaveni najdu. Nekdy se instalatory ptaji na veci, ktere me vubec nezajimaji, ale na toto se vykasle.
3. Jestlize to zpusobuje pokles vykonu (nebo minimalne zhorsuje odezvu GUI) na mych dvou slabsich strojich, existuje slusna sance, ze to zpusobuje stejny problem na silnych strojich take nebo alespon na jejich nezanedbatelne podmnozine, akorat si toho uzivatele nevsimnou, protoze jejich stroj je rychly. To je nesmyslne plytvani vykonem ve stylu MS.
Plně sdílím vaše rozhořčení.
Podle mě - když na podobné problémy půjdu od lesa - jde o generační záležitost. Distribuce v posledních pár letech začali ovlivňovat hošíci, vychovaní Microsoftem, kteří už moc nevědí, co to je Unix. A tak vedle drobných "vylepšení" třeba kolem adresářů čím dál víc člověka otravují nejrůznější nepřehledné slepence, "pokrokově" řešící problémy, které často vůbec neexistovaly, ale vytvářející množství zcela nových a otravných chyb.
Člověk by se někdy nad tím zblil jako Alík.
Zaplaťbůh za to, že je to pořád otevřené a můžete si to přizpůsobit. Jen te ztracený čas vás občas na.ere....
"Distribuce v posledních pár letech začali ovlivňovat hošíci, vychovaní Microsoftem, kteří už moc nevědí, co to je Unix." skuste toto napisat Linusovi ;)
Inak hosi nechapem co tu riesite. Ked tmp adresar premapujete na pevny disk, tak dost pochybujem, ze vam pojde prostredie rychlejsie. Okrem toho, ze si skor odrovnate HDD, ktory bude musiet robit castejsie R/W operacie, vam to pojde o dost pomalsie, kedze HDD operacie su podstatne pomalsie nez operacie s RAM pamatou. Inak viete preco vam to ide pomaly, ked vam dojde miesto v tmp? Je to preto, ze sa dalsie udaje zacnu ukladat do swapu, ktory je prave na HDD a preto vam to vsetko zacne sekat, takze premapovanie by bolo kontraproduktivne. Ja skor pouzivam vypinanie swapu prikazom swapoff -a. Vtedy mam istotu, ze vzdy sa pouzije iba RAM pamat. Ma to vsak nevyhodu v tom, ze vam mozu programy bud padat alebo vyhlasia, ze je malo miesta na ulozisku.
> Inak viete preco vam to ide pomaly, ked vam dojde miesto v tmp? Je to preto, ze sa dalsie udaje zacnu ukladat do swapu, ktory je prave na HDD a preto vam to vsetko zacne sekat, takze premapovanie by bolo kontraproduktivne.
To asi tezko. Hned po nabehnuti stroj s 2 GB nevycerpa dostupnou pamet, ani kdyby na nem jelo KDE, tim mene moje LXDE. Pameti je volne dost, nicmene stroj, hlavne GUI je pomalejsi. Jiste tam nekde je zakopany pes, ale bude nekde jinde.
a ste si isty, ze problem mate v pamati? Totiz ja pouzivam KDE prostredie na pc ktore ma 1GB RAMky a CPU ma 9 rokov stare a ani ked som ho kupoval to nebola zrovna spicka. System, mi na nom bezi celkom svizne, pokial sa krotim v pocte spustenych aplikacii. Skusili ste uz diagnostiku, ze ci vam nieco nevyziera CPU resource alebo priliz casto nekomunikuje z HDD, lebo co sa tyka rychlosti RAMky, tak tam by problem byt nemal podla mna?
> a ste si isty, ze problem mate v pamati?
Zadny problem v pameti nemam. Mam 2 GB a staci mi to.
> Skusili ste uz diagnostiku, ze ci vam nieco nevyziera CPU resource alebo priliz casto nekomunikuje z HDD
Podle grafu v systrayi CPU nic moc nedela a disk jen obcas blikne. BTW, kdyby problemem bylo pretizeni disku, tak presunem tmp na disk by se rychlost spis zhorsila, nez zlepsila.
> Zadny problem v pameti nemam. Mam 2 GB a staci mi to.
Asi som to potom pochopil zle, lebo ste pisal, ze vas problem je v tom ze tmp adresar je namapovany na RAMku ale pokial ho premapujete na HDD tak to ide dobre. Ak mate pocas prace na pc RAMky dostatok, CPU neslape na plno a HDD je v poriadku, tak by som to videl na problem s HW. Skusil by som este pouzit nejake live CD distro (bez primountovania HDD), ci to aj na nom pojde vsetko pomaly. Tym aspon overite, ci to nema na svedomi nejaky SW na vasej aktualnej instalacii. Ak to pojde pomaly aj na tom live CD, tak podla mna je problem v HW.
Celkem neverim, ze by se na dvou strojich z ruzne doby a s odlisnymi specifikacemi vyskytl stejny HW problem nebo stejny SW zpusobujici zpomaleni. Jedno je stara instalace Debian testing s LXDE, druhe je na Debianu testing a Mepisu zalozeny Antix s IceWM ocesany na minimum.
Je stejne celkem jedno, cim to zpomaleni je zpusobene. I kdyby se problem podarilo nakrasne vyresit, tak pokud mi budou padat aplikace na nedostatek mista v tmp, tak skutecnost, ze budou padat rychleji, mi nepomuze. Davat tmp na tmpfs na stroji s 2 GB pameti (v druhem pripade dokonce jen 196 MB) je nehorazny nesmysl. Tohle mel nejaky konfigurator otestovat, dat mi na vybranou a upozornit me, ze pameti neni zrovna moc. Anebo se do toho nemel nikdo stourat a poslat rootovi mail se sdelenim, ze se tmp nyni muze dat na tmpfs a jak se to udela.
Jiste, pokud to treba delate vy a ne nekdo za vasimi zady, kdo vam prestavuje veci v systemu a ani vas neupozorni, ze se neco muze podelat, protoze bydete mit malo mista v tmp.
Ja mam jeste vetsiho starescka s 196 MB SDRAM a toho to totalne zabilo. Pozoruhodne je, ze na desktopu s DDR pozoruji zpomaleni take.
Je to notebook, tam toho moc nevymenim, vic pameti neumi. A notebooky na srotaku jsou vetsinou uplne pro kocku, jeste horsi nez ten muj nebo naprosto zdevastovane, eventuelne oboji. V podstate se da pouzit akorat jako terminal k necemu - ma docela dobry display. Ale jinak na prd. Rychlost celkem ujde, ale staci spustit browser a za chvili se ucpe pamet. Linux jsem tam strcil jen tak ze zvedavosti. Ale pri laborovani s timhle kramem jsem zjistil problem s tmp na tmpfs. A pak jsem zjistil, ze prehozeni tmp na disk prinasi zrychleni i na mem o dost modernejsim desktopu. K cemuz ale doslo az tehdy, kdyz jsem nedokazal vypalit CD, protoze nebylo misto v tmp a zjistoval jsem, jak je to mozne.
„Jiste, pokud to treba delate vy a ne nekdo za vasimi zady, kdo vam prestavuje veci v systemu a ani vas neupozorni, ze se neco muze podelat, protoze bydete mit malo mista v tmp.“
Pokud se jednalo o nějakou testing distribuci, jsi si jistý, že to neproběhlo mailing listem a případně dalšími informačními kanály?
Pokud se jednalo o stable distribuci, pak ano. V takovém případě by to bylo špatně.
To je zase celé padlé na hlavu. Aplikace chce dočasně odložit soubor na disk, nejspíš protože se jí data nevejdou do paměti. Takže vytvoříme ramdisk, aplikace tam bude odkládat dočasné soubory, a my se budeme hrozně divit, že se to - světe div se - nevejde do paměti(!). Takže nejspíš zítra vytvoříme "opravdový" temp directory na disku, naučíme všechny aplikace rozdělovat dočasné soubory na ty v temp dir a ty "opravdovém" diskovém temp dir... a budeme čekat, než nějaký inteligent ten nový FS také iniciativně narve do RAM. Pak se může celé kolečko opakovat.
na 100% souhlasim, dokud byla cilem Linuxu implementace Unixu, tak to bylo jednoduche. Vsichni meli podobne zazemi, podobny rozhled a zadani bylo taky jasne. Proste vzali to nejlepsi s ostatnich Unixu trochu to poladili a implementovali.
Ted ale nestava obdobi hledani novych cest a opousteni tech slepych. Prijde mi, ze nove vizionare vubec nezajimaji stavajici reseni, oni si jdou svoji cestou, a kdyz to nevyjde tak to klidne cely prekopaji a zacnou od zacatku.
Kdyz odhlednu od tech desktopovych veci, tak me namatkou napadne detekce HW a postup bootovani, LVM(LVM1, EVMS, LVM2, MD, ...).
Zrovna vcera, jsem omylem zahnal pocitac do swapu (spustil jsem "make -j" - bez cisla). Pocitac byl uplne mrtvej, nedalo se to zabit z terminalu a nedalo se prihlasit na konzoli. S hruzou jsem zjistil, ze poradne nefunguje ani prepinani konzoli Alt+Fn. Ten novej init se necha klidne odswapovat - WTF?
Jojo, taky jsem si vsiml ze swap system v posledni dobe spolehlive zlikviduje, a celkem me to irituje.
Napriklad Mysql Workbench na mem Ubuntu ma tu vlastnost, ze pri spusteni SQL dotazu je tak 20% procentni sance ze zacne zrat pamet jak divy. UZ jsem si zvykl, ze vetsina veci spojenych s Mysql je naprd. Co me ale dostalo je, ze pokud nezareaguju dostatecne rychle - tak do peti sekund - a system zacne swapovat, prepnuti do konzole trva klidne 10 minut. Pokud to necham swapovat jeste o chvilku dyl (dalsich 5 sekund), odezva na CTRL+ALT+F? se nedostavi ani za hodinu ... dyl jsem cekat nevydrzel. Totez se mi podarilo i s javou ...
Linux pouzivam dlouha leta, a jsme presvedcen, ze pamet jsem dokazal spolehlive ucpat mnohokrat, vzdy jsem ale byl schopen pres konzoli problem vyresit. Proc to ted nejde?
Také mne zaujalo, že když darktable spolykal veškerou RAM v důsledku přehnané paralelizace z mé strany (8 GB, nemám swap) a Xka zatuhla, tak mezi konsolemi jsem se stále mohl přepínat. Jenže to bylo k ničemu, protože jsem se už nepřihlásil ani jako root.
Po půl hodině čekání jsem to vzdal...
Neverim. Ten stroj je sice stary vrak, ale po nabehnuti IceWM mu porad zbyvat tak tretina pameti volna, jestli se dobre pamatuji. Mozna i vic. A pak staci pustit xterm, v nem mc a je to tak pomale, ze nez se presune kurzor, clovek by vyletl z kuze. Po prestehovani tmp na disk se sice kurzor nepohybuje rychlosti svetla, nicmene se s tim da normalne delat. Zrychleni je nejmene nekolikanasobne.
Tiez som narazil na podobny (mozno aj rovnaky) problem s pomalostou GUI na starsich strojoch od 3GHz Northwood/1GB RAM az po 800MHz IP III/1GB RAM, distro Fedora od 14 vyssie, Gnome.
Mne sa zda, ze by to mohlo byt spojene s X-kom. Uz samotne vykreslovania grafickych primitiv ako ciarym kruznice, obdlzniky, vyplnove vzory su pomalsie zhruba 10 nasobne oproti distram pred Fedora 14.
Je mozne, ze je tam sucastne viac problemov, pretoze je vidiet ako sa okna prekresluju a to iba vtedy ak nastane nejaka zmena v pohybe s GUI prvkom. Zda sa mi ako keby zaciatok procesu na nieco par desiatok milisekund cakal a potom bezal takmer normalne.
Pritom vykon procesora je v norme. Ak sa spusti vypocet trebars Pi, tak to bezi normalne, len odozva GUI je nejaka divna.
Bohuzial tomu nepomoze ani ina grafika (vyskusal som 4 rozne), ani ine ovladace a dokonca ani zmena na LXDE ak sa doinstaluje a zmeni po instalacii Gnome.
Ak sa LXDE zvoli pri instalacii bez Gnome, tak to bezi vcelku rozumne. Nemozem, ale potvrdit ci to bezi lepsie na stasich strojoch ako 3GHz Northwood. Este som sa nedostal k tomu aby som to vyskusal.
1) tmpfs pouzivam uz tak dlouho, ze ani nevim jak. A zacal jsem s tim uz v dobe, kdy Debian (unstable) o necem takovem neuvazoval
2) kazdy stroj s 2 a vic GB RAM, zadne zpomaleni jsem nezaznamenal.
3) na mem aktualnim debianu unstable na notebooku jsem zjistil, ze tmpfs neni zapnute... Nijak jsem to po instalaci neovlivnoval. Prvni co mne napadlo, bylo podivat se do /etc/default/ . A hle, zde je soubor tmpfs, sem vkladam relevantni cast:
...
# mount /tmp as a tmpfs. Defaults to no; set to yes to enable (/tmp
# will be part of the root filesystem if disabled). /tmp may also be
# configured to be a separate mount in /etc/fstab.
#RAMTMP=no
# Size limits. Please see tmpfs(5) for details on how to configure
# tmpfs size limits.
#TMPFS_SIZE=20%VM
#RUN_SIZE=10%
#LOCK_SIZE=5242880 # 5MiB
#SHM_SIZE=
#TMP_SIZE=
# Mount tmpfs on /tmp if there is less than the limit size (in kiB) on
# the root filesystem (overriding RAMTMP).
#TMP_OVERFLOW_LIMIT=1024
...
Takze z meho pohledu nevidim zadny podraz na uzivatele v podobe zakerneho meneni za uzivatelovymi zady.
4) pokud mam problem, tak vypis prikazu df a letmy pohled napovi. Potom snad neni problem vytvorit iso jinde.
Zřejmě tohle je příčina, proč na Debianu 6 nejede video v plném rozlišení (respektive jede s cca 1/3 rychlostí oproti zvuku), zatímco na pětce na stejném železe jede zcela bezproblémově. Faktem je, že když už nějaký b*l*b udělá takovouto změnu, tak by měla být rozumně dostupná informace, jak to změnit zpět a obnovit funkčnost systému. Já to řešil downgradem zpět na verzi 5, protože počítač mám na to, aby fungoval, ne na to, aby byl "aktuální".