Chromium veroorzaakt extreme schijfactiviteit op NFS-server

[Josefien]

Mijn vraag
...
Ik gebruik de Chromium webbrowser op cliënts met Ubuntu 16.04. De home-directories zijn via NFS gekoppeld aan een server met Debian 8.0.

Het probleem is dat de Chromium browser extreem veel schijfactiviteit veroorzaakt op de server. Een simpele pagina op GoT laden zorgt ervoor dat de schijven in de server zeker 2 secondes op topdrukte bezig zijn met zoeken en ondertussen is er een vertraging waarneembaar bij het laden.

Deze schijfactiviteit is zelfs zo extreem dat als ik een YouTube-filmpje wil kijken op 720p hij de schijven zó druk belast tijdens het inladen/cachen dat het filmpje simpelweg niet afgespeeld kan worden omdat het inladen/cachen trager gaat dan het afspelen

Qua netwerkactiviteit is er weinig aan de hand, doorgaans blijft dat onder de 2MB/s. Maar de schijven in de server zijn dan constant aan het zoeken ("ratelen") zolang Chromium bezig is. Afsluiten v/h tabblad (of Chromium) betekent ook meteen einde schijfactiviteit.

Dit gedrag doet zich alleen voor als de home-directory via NFS is gekoppeld. Bij lokale home-directories speelt dit probleem niet.

Wat veroorzaakt dit probleem? Waar is Chromium mee bezig op zo'n moment?


Dit probleem was er niet altijd geweest, maar pas na een upgrade v/d cliënt en server OS'en. Bij de oude combinatie Ubuntu 12.04/Debian 6.0 was dit probleem er niet. Bij Ubuntu 16.04/Debian 6.0 ook niet. En met Ubuntu 12.04/Debian 8.0 was dit ook niet merkbaar. Pas toen zowel cliënt als server waren geüpgraded (16.04/8.0) ontstond dit probleem.


Relevante software en hardware die ik gebruik
...
- Ubuntu 16.04 & Chromium 55.0.2883.87 (cliënt).
- Debian 8.0 (server).


Wat ik al gevonden of geprobeerd heb
...
Nog niks geprobeerd, ik weet niet waar ik het probleem moet gaan zoeken

[Ultraman]

Probeer eens de cache van Chromium in een tmpfs te zetten? Wellicht worden daar veel kleine writes uitgevoerd en NFS writes zijn doorgaans sync, waardoor er een relatief hoge latency kan ontstaan.

Geen idee of Chromium zoiets kan, vermoed van wel. Ik doe het met Firefox, daar heb ik mijn cachedir ingesteld op /dev/shm/firefox-cache.
Maakt het teruggaan naar de vorige pagina ook een stukkie vlotter.

Controleer ook wat mogelijk verschillen zijn tussen de NFS mounts van nu en de oude waarbij het wel goed ging. NFSv3 vs NFSv4? Verandering in de mount defaults (controleer mount opties)? Verandering in Chromium die dit veroorzaakte (probeer een oude)?

[ Voor 5% gewijzigd door Ultraman op 16-01-2017 22:13 ]

[pporrio]

Chromium gebruikt standaard ~/.cache/chromium
Misschien handiger om de cache om te leiden naar een lokale map: chrome --user-data-dir=/path/to/foo

Bron: https://www.chromium.org/user-experience/user-data-directory

[Josefien]

Ik heb even geprobeerd... het heeft inderdaad met de cache te maken Als ik de ~/.cache/chromium naar /tmp/josefien/.cache/chromium symlink lijkt het probleem ook niet meer voor te komen.

De oorzaak lijkt dus gevonden, maar hoe aan te pakken? Een handmatige symlink naar iets in de /tmp is geen praktische mogelijkheid, omdat er met hetzelfde account op meerdere PC's wordt ingelogd. Als de map in /tmp niet bestaat, wordt deze niet automatisch aangemaakt. Bij een reboot is dat eigenlijk al een probleem, want /tmp wordt geleegd.

De commandline-optie is ook niet praktisch, want die wordt niet onthouden, maar werkt alleen voor die ene sessie


Ik zit zelf te denken om zelfs de hele ~/.cache te verplaatsen naar /tmp/%USER/.cache. Blijkbaar zitten er in .cache nog meer zooi wat niet behouden hoeft te worden bij een reboot, maar nu wel de NFS-server onnodig belast En de hele ~/.cache lokaal opslaan levert blijkbaar ook met Firefox en veel andere applicaties snelheidswinst op

In principe kan dit met een symlink. Dan gaat alles wat geschreven wordt naar ~/.cache vanzelf naar /tmp/%USER/.cache en wordt ook bij elke reboot geleegd.

Alleen, hoe zorg ik ervoor dat /tmp/%USER/.cache vanzelf wordt aangemaakt zodra de gebruiker zich aanmeld, nog vóórdat de eerste schrijfactie wordt gedaan in de map?

Met een script als dit kan de map worden aangemaakt, maar kan dit script ergens geplaatst worden dat die als allereerste wordt uitgevoerd na het invoeren van gebruikersnaam en wachtwoord, nog voordat onderdelen van Gnome worden geladen? Die schrijven namelijk ook in ~/.cache

code:

#!/bin/bash
if [ -d "/tmp/$USER/.cache" ] 
then
    echo "Map bestaat bestaat al." 
else
    mkdir /tmp/$USER && mkdir /tmp/$USER/.cache
fi

In de NFS-mounts zijn geen verschillen. De bestaande regels in /etc/fstab (cliënt) en /etc/exports (server) zijn gewoon behouden. Op de cliënt gemount met "sync" en "hard". En geforceerd op NFS v3.

[pporrio]

Probeer je script eens te starten via een .desktop bestand in: ~/.config/autostart

[ Voor 22% gewijzigd door pporrio op 16-01-2017 23:02 ]

[Juup]

Chrome is Firefox doen dit beide.
In Firefox kun je het uitzetten (about:config -> browser.sessionstore.interval, hoger getal van maken)
In Chrome kun je het helaas (nog) niet veranderen.
Zie https://www.servethehome....sd-here-is-how-to-fix-it/

[Hero of Time]

Het maken van die map in /tmp kan je via je display manager/sessie manager laten gaan. Dat het dat uitvoert voordat er iets anders wordt geladen.

Overigens kan je mkdir ook korter door de -p optie mee te geven. Een simpele "mkdir -p /tmp/$USER/.cache" is dan voldoende en als de map al bestaat, boeit dat niet. Je krijgt dan alleen een exit 1 terug, maar dat zou geen probleem moeten geven voor de rest van het script dat de sessie start. Zie bijvoorbeeld het /etc/X11/Xsession script. Daar wordt o.a. .xsession-errors gemaakt dat alle error meldingen van je sessie bevat. Ook de meldingen van Gnome e.d.

[Josefien]

pporrio schreef op maandag 16 januari 2017 @ 22:45:
Probeer je script eens te starten via een .desktop bestand in: ~/.config/autostart

Deze worden helaas veel te laat gestart... pas nadat Gnome is geladen

Hero of Time schreef op maandag 16 januari 2017 @ 23:12:
Het maken van die map in /tmp kan je via je display manager/sessie manager laten gaan. Dat het dat uitvoert voordat er iets anders wordt geladen.

Overigens kan je mkdir ook korter door de -p optie mee te geven. Een simpele "mkdir -p /tmp/$USER/.cache" is dan voldoende en als de map al bestaat, boeit dat niet. Je krijgt dan alleen een exit 1 terug, maar dat zou geen probleem moeten geven voor de rest van het script dat de sessie start. Zie bijvoorbeeld het /etc/X11/Xsession script. Daar wordt o.a. .xsession-errors gemaakt dat alle error meldingen van je sessie bevat. Ook de meldingen van Gnome e.d.

Ik heb Lightdm als display manager. En ik vond dit:
https://wiki.ubuntu.com/LightDM#Adding_System_Hooks

Zou ik dan mijn script onder "session-setup-script" moeten plaatsen? Er staat "is run before a user session starts". Betekent het dat 'ie direct wordt gestart zodra gebruikernaam en wachtwoord is ingevoerd of zelfs daarvoor? Hij moet namelijk wel uitgevoerd worden als de gebruiker zelf, anders werkt de variabel "%USER" natuurlijk niet

[Josefien]

Plaatsen onder "session-setup-script" zorgt ervoor dat het script uitgevoerd wordt bij aanmelden en de %USER variabel is dan al aanwezig. Of de directory op tijd wordt aangemaakt, kan ik nog niet testen.

Er komt namelijk nog een nieuw probleem bij: het script wordt waarschijnlijk als "root" uitgevoerd waardoor de aangemaakte mappen als eigenaar "root" hebben. Hierdoor kan de ingelogde gebruiker er dus alsnog niks mee

Het toevoegen van "&& chown -R %USER.users /tmp/%USER" achter de mkdir-regel in het script werkt helaas niet. Resultaat is dat na een eerste aanmeldpoging lightdm terugkeert naar het inlogscherm (foutcode?) en pas bij de 2e poging aanmeld. Echter hebben de mappen dus nog steeds root als eigenaar

[ Voor 5% gewijzigd door Josefien op 17-01-2017 00:56 ]

[Hero of Time]

De chown is als syntax user:groep. Voor de eenvoud kan je zelfs $USER: gebruiken, omdat als je niets achter de ':' zet, de default groep van de user wordt gebruikt. Een chown in /tmp kan gewoon, dus hoe dit zit, geen idee.
Je kan ook het mkdir commando voor laten gaan door 'su -l $USER -c', waardoor je dit krijgt:

su -l $USER -c "mkdir -p /tmp/$USER/.cache"

Enige probleem wat ik hierbij zie is dat $USER wordt gezien als de gebruiker die het werkelijk uitvoert: root. En dus niet de gebruiker als wie je aanmeld.

[Foeijonghaai]

pporrio schreef op maandag 16 januari 2017 @ 22:17:
Chromium gebruikt standaard ~/.cache/chromium
Misschien handiger om de cache om te leiden naar een lokale map: chrome --user-data-dir=/path/to/foo

Bron: https://www.chromium.org/user-experience/user-data-directory

Als je bovenstaande nu combineert met een alias?

[Josefien]

Hero of Time schreef op dinsdag 17 januari 2017 @ 09:24:
De chown is als syntax user:groep. Voor de eenvoud kan je zelfs $USER: gebruiken, omdat als je niets achter de ':' zet, de default groep van de user wordt gebruikt. Een chown in /tmp kan gewoon, dus hoe dit zit, geen idee.
Je kan ook het mkdir commando voor laten gaan door 'su -l $USER -c', waardoor je dit krijgt:

su -l $USER -c "mkdir -p /tmp/$USER/.cache"

Enige probleem wat ik hierbij zie is dat $USER wordt gezien als de gebruiker die het werkelijk uitvoert: root. En dus niet de gebruiker als wie je aanmeld.

"chown" blijkt niet bruikbaar, hij accepteert blijkbaar geen %USER variabel als gebruik, geeft dan de fout "Onbekende gebruiker %USER" terug. Dat verklaart ook waarom het script niet werkte.

Het andere commando ga ik vanavond proberen als ik thuis ben

Foeijonghaai schreef op dinsdag 17 januari 2017 @ 10:33:
[...]

Als je bovenstaande nu combineert met een alias?

Dat lost het mogelijk alleen op voor Chromium. Nu ik erachter ben dat andere applicaties er ook profijt van hebben, wil ik eigenlijk de hele .cache verplaatsen.

[Hero of Time]

Josefien schreef op dinsdag 17 januari 2017 @ 14:02:
[...]
"chown" blijkt niet bruikbaar, hij accepteert blijkbaar geen %USER variabel als gebruik, geeft dan de fout "Onbekende gebruiker %USER" terug. Dat verklaart ook waarom het script niet werkte.

Het andere commando ga ik vanavond proberen als ik thuis ben

Tja, als je stug %USER blijft gebruiken dan is dat ook logisch. Dat is de Windows definitie, en zelfs maar half omdat je nog een % aan het eind mist. Bij Linux wordt er $USER gebruikt.

[...]
Dat lost het mogelijk alleen op voor Chromium. Nu ik erachter ben dat andere applicaties er ook profijt van hebben, wil ik eigenlijk de hele .cache verplaatsen.

Hmm, hier een idee: http://askubuntu.com/ques...-mounting-cache-directory. En meer Google resultaten. Zit vast wel iets tussen dat werkt.

[Josefien]

Hero of Time schreef op dinsdag 17 januari 2017 @ 14:15:
[...]

Tja, als je stug %USER blijft gebruiken dan is dat ook logisch. Dat is de Windows definitie, en zelfs maar half omdat je nog een % aan het eind mist. Bij Linux wordt er $USER gebruikt.

Omg... daar kwam ik net pas ook achter Sorry...

Bij Windows heet 'ie volgens mij zelfs %username%. Heel anders

Ik was mijn script begonnen met $USER, maar halverwege de nacht was ik op de een of andere manier overgegaan naar %USER voor de rest zonder dat ik me er bewust van was

Pas toen ik net jouw command ging proberen...

code:

su -l $USER -c "mkdir -p /tmp/$USER/.cache"

... deze werkte wèl. Maar hij stopte ermee toen ik er "&& chmod 700 /tmp/%USER" achter ging plakken (standaard is namelijk 755, ongewenst) Ging ik goed kijken... zat ik dus gewoon %USER te gebruiken i.p.v. $USER

Nu blijkt dus het eerdere...

code:

"mkdir /tmp/$USER && mkdir /tmp/$USER/.cache && chown $USER /tmp/$USER"

...ook te werken Het werkte alleen de hele nacht en ochtend niet omdat ik onbewust over was gegaan op %USER

Omg... dit is zo beschamend...

[Hero of Time]

Ik vroeg mij al af waarom je hier telkens %USER neerzette.

[Josefien]

Hero of Time schreef op dinsdag 17 januari 2017 @ 14:37:
Ik vroeg mij al af waarom je hier telkens %USER neerzette.

Ik was misschien niet meer helemaal helder, te moe of zo

Hero of Time schreef op dinsdag 17 januari 2017 @ 14:15:
[...]

Hmm, hier een idee: http://askubuntu.com/ques...-mounting-cache-directory.

Dit brengt me mogelijk op een nòg beter idee

Die genoemde ~/.xprofile wordt van wat ik kan vinden al uitgevoerd voordat Gnome wordt geladen en werkt ook met Lightdm

In theorie zou ik dus ook een script daarin kunnen zetten, dan kan het per gebruikersaccount worden geregeld met een bestandje in de home-directory en hoef ik niet elke cliënt-PC aan te passen

Nu is dat linkje gericht op het opslaan op ramdisk terwijl ik /tmp wil. Maar dat lijkt me een kwestie van de paden aanpassen en het bestaande erin verwerken. su of chown zijn dan niet nodig als het script wordt uitgevoerd als de inloggende gebruiker zelf

Ik kom uit op zoiets:

code:

#!/bin/bash
if [ -d "/tmp/$USER/.cache" ] 
then
    rm -rf /tmp/$USER
    mkdir -p /tmp/$USER/.cache
    chmod 700 /tmp/$USER
    rm -rf /home/$USER/.cache
    ln -s /tmp/$USER/.cache /home/$USER/.cache

else
    mkdir -p /tmp/$USER/.cache
    chmod 700 /tmp/$USER
    rm -rf /home/$USER/.cache
    ln -s /tmp/$USER/.cache /home/$USER/.cache
fi

In theorie moet dit werken.

Gebruik van if/then/else omdat /tmp alleen wordt geleegd bij een reboot. Als een gebruiker af- en weer aanmeld blijft de map dus bestaan en vrees ik voor een foutmelding waardoor Lightdm terugkeert naar het inlogscherm.

[Kees]

Josefien schreef op dinsdag 17 januari 2017 @ 16:40:
[...]
Ik kom uit op zoiets:

code:

#!/bin/bash
if [ -d "/tmp/$USER/.cache" ] 
then
    rm -rf /tmp/$USER
    mkdir -p /tmp/$USER/.cache
    chmod 700 /tmp/$USER
    rm -rf /home/$USER/.cache
    ln -s /tmp/$USER/.cache /home/$USER/.cache

else
    mkdir -p /tmp/$USER/.cache
    chmod 700 /tmp/$USER
    rm -rf /home/$USER/.cache
    ln -s /tmp/$USER/.cache /home/$USER/.cache
fi

Ik haat dubbele code

dus zoiets werkt ook al:

code:

#!/bin/bash

[ -d "/tmp/$USER/.cache" ] && rm -r /tmp/$USER

mkdir -p /tmp/$USER/.cache -m 0700

rm -rf /home/$USER/.cache
ln -s /tmp/$USER/.cache /home/$USER/.cache

Let er wel op dat het symlinken in principe maar 1 keer (per gebruiker) nodig is, daarna staat het voor alle gebruikers goed, je kan dat dus ook achterwege laten en meteen voor de gebruiker de symlink aanmaken (de /tmp directory hoeft daarvoor niet te bestaan). Dat scheelt nog meer code

En als het je niet uitmaakt of de directory leeg is dan voldoet

mkdir -p /tmp/$USER/.cache -m 0700

al, want die geeft geen error als de dir al bestaat.

[ Voor 7% gewijzigd door Kees op 17-01-2017 19:07 ]

[Josefien]

Die kortere lijkt ook te werken, ja

Klopt, die symlink is maar een keer nodig Ik wil bij bestaande of nieuwe gebruikersaccounts echter alleen het script erin hoeven zetten. Met die extra handeling "verwijder & maak" wordt dan in zo'n geval een bestaande map vanzelf verwijderd en vervangen door een symlink