Ten titulek by se měl jmenovat "Prohlížeče požírají...", ne "Firefox požírá...".
Za druhé, zkoušel jsem to testovat sám, na dvou různých počítačích (oboje Fedora) a nemůžu to nareprodukovat. Firefox za 2 dny běžného kancelářského používání (8h denně) má zapsáno 2.3 GB (případně 1.6 GB, pokud započítám cancelled_write_bytes). Jde to rychleji nahoru když se díváte na videa, ale očekávaně (prostě bandwidth videa). Měřeno pomocí /proc/pid/io (write_bytes, cancelled_write_bytes) i pomocí iotop -a -P -u $USER.
Takže bych řekl, že je to spíš kachna, nebo ten MS nástroj prostě zobrazuje něco jiného, než si lidi myslí (ne skutečně syncnutá data na disk).
V povodnom clanku ten autor, aspon podla screenshotov testoval Firefox na Windowse. Je otazne ako moc sa lisi v tomto pripade windows build od linuxoveho a tak isto kolko z toho zachyti OS a kolko samotny management disku.
Druha vec je ze dnes sa na nejaku optimalizaciu uz nikto nehra. V poslednej dobe sa stretavam s tym ze prakticky kazdy klient na nejaku sluzbu, teda navonok standalone aplikacia, je vlastne skompilovany chrome/webkit kde gui a vsetko lokalne je riesene cez js/html. Ako to je uz dost nechutne peklo.
No, ale ono to tak bylo skoro vždycky. Velké množství aplikací bylo vždy napsáno jako obecné runtime + logika. Takové FoxPro bylo všude. A mělo to přesně stejnou strukturu.. GUI prefabrikáty + trocha logiky. Proč totiž dělat speciální UI, když html + js to všechno udělá "samo" a existuje v nich obrovské množství dobrých (i špatných) knihoven.
Nie je to kačica. K rovnakému záveru som došiel už pred niekoľkými rokmi pomocou nástroja ProcessMonitor od SysInternals. Aj preto mám všetky prehliadače presmerované, aby profily (vrátane cookies, histórie atď.) ukladali na mechanický disk. Jedinou výnomkou je Internet Explorer resp. Edge od Microsoftu, kde sa to jednoduchým spôsobom urobiť nedá. Taktiež mám presmerované dočasné adresáre Windowsu. Najväčším zapisovateľom na SSD je momentálne antivírus od Esetu, ktorý pri každej aktualizácii zapíše na disk asi 300 MB dát, na čo som upozornil spoločnosť Eset. S tým sa ale dá zmieriť.
Přijde mi nepravděpodobné, že by se chování Firefoxu takto dramaticky lišilo mezi systémy, spíše bych čekal, že ty čísla z Windows (ať již zobrazené kterýmkoliv nástrojem) zobrazují něco trochu jiného, než lidi předpokládají. Taktéž bych čekal, že už by si lidi na SSD dávno všimli, že jim ve SMARTu hodně rychle odsýpá životnost disku. Což zatím u všech komentářů, co jsem četl (a i v mém případě) tak vůbec není. Takže dokud ten test neprovede někdo, kdo se v I/O vážně vyzná a nenechá se zmást nějakým hausnumerem kdesi, tak bych se příliš nad tím nevzrušoval.
Je to známka blbě napsaného programu.
TinyTinyRSS (webová rss čtečka) je schopná vygenerovat denně stovky MB wal logů, přičemž db samotná má 40MB. Stovky mega nemají ani data stahovaná z rss zdrojů. Co dělá s tou db jsem raději ani nezjišťoval, nějakou čtečku potřebuju, a pokud dám vše na blacklist, tak se potom těžko vybírá.
Mám dvě zařízení s SSD a na obou používám chrome.
Jedno SSD (V300 60 GB) má nalítáno skoro 2 roky čistýho času, za tu dobu jsem na něj zapsal 2.5 TB (TBW 32 TB), to SSD je jediný disk v počítači a je na něm i swap.
Druhý SSD (850 Pro 256 GB) má nalítáno pouze půl roku, zapsal jsem 1.2 TB (TBW 150 TB), opět je to jediný disk, ale nepoužívám swap.
Opravdu v tom nevidím žádný problém. Stejným tempem mi to starší vydrží ještě 10 let a to druhý dokonce 60 let non stop provozu. Do deseti let bych musel plotnovej disk minimálně jednou měnit.
Obecně mě záznam session Firefoxu docela vadí ve způsobu implementace. Poměrně často se mi stane, že Firefox/ Iceweasel např. po resume (Debian Testing) žere hodně CPU. Potom ho ukončím no a někdy prostě taby neobnoví. Hlavně pokud bylo např. otevřeno ještě separátní okno nebo tak něco. Je fakt, že mám hodně tabů, často výrazně přes 100. Na druhou stranu s 16 GB RAM by to neměl být problém.
Lepší logování stavu by jistě pomohlo. Nakonec by se dalo i dost ušetřit na uložených datech. Pravděpodobně budou mít oblíbené, aktuální záložky a historie docela slušný překryv co se URL týče. Ten obří JSON není asi úplně ideální, když jde o rychlý zápis. Možná by se mohl dělit podle nějaké LRU heuristiky do více souborů a ty se zase updatovat jen inkrementálně. Starší by se daly komprimovat. Více stupňů granularity možností obnovení by bylo taky fajn. Někdo má opravdu důležité věci v záložkách i když je zrovna v určitý den nepotřebuje. Pro někoho je pád prohlížeče prostě obří ztráta času, pro někoho je to asi takový problém jako dvojitý klik.
Obecně nástroje by neměly předepisovat chování, ale zkvalitňovat určité řešení úkolů.
Firefox v recovery moc robustní není, i když je to esenciální součást dnešního workflow.
Jasne ... http://kb.mozillazine.org/Browser.sessionstore.enabled
Has an effect in
Mozilla Firefox 3.0 and below. Since Firefox 3.5 this preference is superseded with setting browser.sessionstore.max_tabs_undo and browser.sessionstore.max_windows_undo to 0.
Možná woknařům požírá SSD. U svého prvního SSD jsem úzkostlivě sledoval, kolik denně zapíše. Z toho jsem vypočítal, že s takovou ho budu mít 48 let. Teď mám 120 GB SSD, dlabu na nějaké optimalizace, FF a TB stahují kde co na SSD a životnost klesá o 1% za půl roku. Pokud svoji práci neodvede EU bezolovnatá pájka, tak ten disk mám na doživotí.
Jestli to nakonec nebude humbuk, protože u SSD musím vědět kolik zapisuji a podle toho vyberu velikost SSD. Pokud zapisuju jako o život, tak se nesmím dívat na cenu, ale velikost SSD, což uživatelé právě nedělají. A nebo tam musím mít doplňující HDD, případně dostatek RAM.
Trochu potrollím:
1) jakou životnost očekáváte u SSD (HW i morální)?
2) sejme vaše SSD prodřené hradlo, bezolovnatá pájka nebo jev zvaný data retention?
3) tipujete, že to může být v horizontu do 5 let?
1) jakou životnost očekáváte u SSD (HW i morální)?
Své první ssd používám už šestým rokem. 60GB na systém bohatě stačí. Rychlost už dneska není zrovna oslňující, ale furt lepší jak hdd.
2) sejme vaše SSD prodřené hradlo, bezolovnatá pájka nebo jev zvaný data retention?
Těžko říct.
3) tipujete, že to může být v horizontu do 5 let?
Viz bod 1
Tiez som mal bezne vo firefoxe otvorenych 200+ zaloziek, potom sa mi pomaly spustal, zaberal vela v pamati. Odkedy som zacal pouzivat rozsirenie OneTab, ktore zavrie nepouzivane stranky, vie ich organizovat do skupin som s firefoxom nadmieru spokojny. Vacsina problemov je ked sa nechava vela otvorenych tabov, potom ide odozva rapidne dolu.
Z tohoto důvodu používám https://github.com/graysky2/profile-sync-daemon.
Neviem asi niesom nejaky kruty analytik, nemam asi za sebou milion riadkou kodu ako fesaci z Mozilly, ale rad by som stretol toho deb*la co to takto nadesignoval. Fakt by som chcel pochopit naco potrebuje Firefox ukladat v nejakom pravidelnom casovom intervale stav (otvorene taby) ktory sa pritom sam od seba nemeni ale vzdy nastava zmena po vonkajsom vstupe - uzivatel zavrie/otvori novy tab. Preco neulozia aktualny stav pred otvorenim noveho tabu a po uzavreni niektoreho tabu? Ved to je jediny moment kedy s nimi nieco robi (teraz neriesim ked do toho zacnu sahat pluginy a js ale aj to sa da osetrit).
Možno stav tabov ukladajú preto, aby ho vedeli obnoviť po násilnom zatvorení aplikácie. Moja polovička, keď jej napríklad vypadne elektrika a vybije sa baterka, tak si situácie vôbec nevšimne, zareaguje až potom ako sa notebook vypne. Keď pochopí, že notebook musí pripojiť na sieť a zapne ho, bola by veľmi rozčarovaná keby firefox nenašla v takom stave ako ho zanechala.
Dá sa to vypnúť, takže by som to neriešil.
Je to o odvahe :-). Sybase som este nikde nedaval, mozno skusim. Mam take male databazy do 10GB a realne ich naplnit v podmienkach Slovenska zaberie 2 roky. Neviem si predstavit kde by sa zobralo 10TB, teda ak tam ludia neukladaju obrazky a dokumenty, ale take zvrhlosi hadam nerobite :-)
Jsou to většinou data z tradingu, schovává se něco na analýzu kvůli automatizovanemu obchodování, dále výzkum biochemie, casticova fyzika atd. Záleží na firmě/instituci pro kterou se poskytuje servis. Je fakt ze v českých podmínkách jsem zatím na takové požadavky nenarazil, ale české firmy obecně kvůli bordelu v IT dělat nechci a tak možná je můj vesmír izolovany.
Asi si nepochopil o com pisal, alebo ja nechapem co si chcel povedat.
Ak si ff ulozi len zmeny tabov, cize ked daky zatvoris/otvoris, len vtedy ked sa tak stane (ako pise kolega vyssie) tak usetris mrte writes, a to ci ff killnes alebo chcipne pc alebo ho normalne vypnes je uplne jedno predsa
Ked mas 10min otvoreny ff a nerobis ziadnu aktivitu s oknami (citas clanok napr) tak je uplne chore aby to kazdych 15s prepisovalo tie iste data
Alebo ides na obed alebo afk na 1h , ff nic nerobi ale kazdych 15s ti zapise stav okien, akoze to je naco dobre?
Suhlasim s tym nazorom ze to maju nahovno nakodene.
A jako stav coho ? Podla toho webu je to nejaky js a cookies. Ten js bude asi aj tak vnutorne json. Nepoznam az tak do detialov ff a nechce sa mi ho teraz instalovat.
V prncipe ale co potrebujem, ulozit akurat tak otvorenu url a session. Aj tak po restarte/znovuotvoreni browser da znovu request na stranku a uz je to potom v rezii browseru ci ide na server alebo pouzije cache ale to je uz ina cast. Pripadne ak chcu byt az moc "user friendly" tak mozu este ukladat stav formularov/input boxov a celkovo elementov. Ak mal clovek nieco vyplnene tak to ulozit. Ale zasa, ak mam otvoreny formular a nieco busim do text area alebo imput boxu, kde je problem zapisovat dane hodnoty do toho "recovery" suboru a v momente ked dopisem proste prestat zapisovat.
Neviem si dost dobre predstavit tak kriticku pracu ze ked drbne browser tak pride koniec sveta. Ak niekto pouziva taku aplikaciu tak jednak ta aplikacia je debilne napisana pretoze samotne http uz z principu negarantuje drzanie spojenia a celkovo pouzivat na nieco kriticke web browser je uchylovina. Vo vsetkych ostatnych pripadoch je to proste len otravne.
Vypadá to, že se ukládají jen změny, pokud nějaké jsou. Takže je skoro jedno, jestli se sledují události vedoucí ke změně, nebo periodicky kontrolují změny.
Otázka je, proč se tam pořád mění a jestli je to potřeba všechno ukládat.
V notebooku mám klasický magnetický disk ale přesto jsem zkusil v nastavení Firefoxu tu problematickou hodnotu přepsat. Jako člověk, který běžně otevře klidně 50 panelů musím uznat, že pozoruji okamžité zlepšení rychlosti a doufám i ve zlepšení stability.
Jinak hodnotu jsem přepsal na 900 000 (15 minut).
"Chrome například je schopen při 80 otevřených panelech..."
No já nevím, jak vám, ale mně se podaří naráz otevřít max 12-14 panelů a pak už Chrome padá. Nedejbože aby na některých panelech bylo něco flashovýho, pak mi padá už třeba při půlce otevřených panelů nejdřív samotná karta a posléze i celý prohlížeč (proč nefunguje oddělení karet od prohlížeče samostatnými procesy jak má?). Kde jsou ty časy, kdy jsem měl v Chromu oteřených 50 panelů a vše šlapalo jak hodinky?
Reality show: Přepisujeme 40GB SSD Intel 320 Series až do skonání
http://diit.cz/clanek/ssd-deep-in-hell
Nová studie: SSD více likviduje čas než používání, SLC a MLC vydrží stejně
http://diit.cz/clanek/nova-studie-ssd-vice-likviduje-cas-nez-pouzivani-slc-mlc-vydrzi-stejne
Jak dlouho vaše SSD udrží data? Záleží na teplotě
http://www.svethardware.cz/jak-dlouho-vase-ssd-udrzi-data-zalezi-na-teplote/40444
OCZ Vector 150: v testu výdrže jej umučíme k smrti
http://www.svethardware.cz/recenze-ocz-vector-150-v-testu-vydrze-jej-umucime-k-smrti/40050
Zajímavé odkazy, obzvlášť ten druhý, ale přeci jen mi tam něco chybí-
Životnost - data retention s procentem vyčerpání počtu přepisů hodně rychle klesá a tabulková doba se obvykle udává pro "nevyčerpané" paměti. Je velký rozdíl mezi pamětmi co vydrží 1k nebo 100k zápisů, ty druhé udrží při tom samém počtu přepisů data déle. (ale pokud je dobrý HW řadič a je stále zapnutý tak si to pohlídá a data refreshne takže to není takový problém).
Dále,jestli se dobře pamatuju, tak rozdíl mezi "enterprise" a "client" podle Jedec není jenom počet přepislů a data retention ale i počet zapsaných dat(nebo snad hodin v záisu?) za den. U client se nepředpokládá trvalý zápis(nebo provoz? - juž si to moc nepamatuju).
Že jedec povoluje pro enterprise kratší dobu data retention je pravda, zřejmně se nepředpokládá že to bude dlouhodobě ve vypnutém stavu.
Rád bych požádal autora článku (klidně i další diskutéry) o názor na následující věc.
Připadne mi poněkud nepravděpodobné, že by konfigurační položka "browser.sessionstore.enabled", pokud by měla zapínat / vypínat dotyčnou funkčnost, byla datového typu řetězec (přestože v odkázaném článku je také uvedeno "String"). Totiž když si na stránce about:config nechám vyfiltrovat řetězec "enable", drtivá většina parametrů je - dle mne správně - datového typu boolean (alespoň žádného dalšího Stringového jsem si nevšiml).
A pak druhá věc. V diskuzi pod tím odkázaným článkem je zmíněno, že se to ovládá jinak pojmenovaným konfiguračním parametrem, a sice "browser.sessionstore.resume_from_crash".
Nejspíš preventivně nastavím oba konfigurační parametry, datového typu boolean, na hodnotu false.
Co si o tom myslíte?
Díky.
Ano, presne toho sameho jsem si vsiml take string x boolean.
Ale jak pise Mozilla na http://kb.mozillazine.org/Browser.sessionstore.enabled, tak se to netyka FF > 3.0. Coz uz je tak archaicky prohlizec, ze ho nikdo nepouziva. Misto toho se ma pouzivat:
Mozilla Firefox 3.0 and below. Since Firefox 3.5 this preference is superseded with setting browser.sessionstore.max_tabs_undo and browser.sessionstore.max_windows_undo to 0.
Coz ma l ale tu nevyhodu, ze nemuzete pak pouzivat "Undo closed tabs ci windows". Otazkou je, jesti ten, co na to s temi prisel, pouziva FF <= 3.0. Spis bych rekl, ze ne, ze pouziva vyssi (soucasny FF). Pak ale je mi zahadou, jak to FF ma naprogramovane, ze diky tehle funkcnosti zapisuje tolik na disk. Protoze me napada, ze zapis na disk by mel byt jen v okamziku, kdyz uzivatel zavre tab ci windows, coz budou snad jen par byte na URL, nanejvys data z formularu ci tak.
Takze tomu ve finale nerozumim.
Takéto správanie Firefoxu sa mi nepáči, a to musím povedať, že do verzia cca 30(?) to bolo ešte horšie a ukladal čosi každú sekundu.
Jednej veci nerozumiem - nikde v článku ani v diskusii som nenašiel jednoduché riešenie - nastaviť v /etc/fstab pre príslušný disk, na ktorý firefox zapisuje, parameter frekvencie uloženia cache na disk, napr.
commit=600
(600 sekúnd). Firefox sa môže prihovárať disku koľko chce a vždy mu odpovie len cache. A tá raz za povedzme 10 minút pošle disku nazbieranú zmenu za 10 minút. Keďže Firefox prepisuje dokola ten istý súbor, tak tých zmien na konkrétnom mieste disku nebude veľa.
Není zde zmíněna dost zásadní skutečnost - pokud je na SSD disku (běžná kapacita 128-256GB) nedostatek místa, musí systém přepisovat stále tutéž, relativně malou oblast. Pokud tedy mám (a skutečně mám) na SSD kolem 10-15 GB prostoru, při této aktivitě Firefoxu bude brzy na konci životnosti. Takže v mém případě - této funkci - palec dolů.