Alt om ingenting og litt i mellom En blogg av Knut-Olav

Millioner av filer i samme katalog på filsystemet i Linux

2. desember 2014 · Comments Off

På jobb her om dagen kjørte vi i to-hundre (nye filer i sekundet) “rett i en veggen”, da antallet filer på filsystemet ble for mange og alt gikk i stå.

Hovedsaklig møtte vi på to problemer: ingen flere ledige inodes, og lang venting på å liste ut alle filene, med millioner av filer lagret i én og samme katalog.

Filene ble lagret på filsystemet EXT4 i Linux, Ubuntu 14.04.1 LTS.

EXT4 har en fastsatt grense for antall filer som filsystemet kan håndtere, og denne settes under oppretting av filsystemet, så denne kunne vi ikke endre.
Videre klarer ikke EXT4 å håndtere stort mer enn ca 100k filer i én og samme katalog uten at alt går i sneglefart.

Vi måtte finne et nytt filsystem, noe som ikke hadde noen øvre grense for antall filer, med unntak av diskplass så klart.

Andre filsystemer til unnsetning

Vi måtte gjøre noen tester for å finne ut hvilket filsystem vi kan bruke istedenfor EXT4.
Kandidatene vi kom fram til var BTRFS, XFS og ZFS.

I tillegg vurderte vi OneFS, et produkt fra Isilon som vi allerede har kjørende i produksjon, et nettverkslagringssystem som er spesialisert til å håndtere veldig store datamengder, men dette produktet er heller ikke bra til å håndtere veldig mange filer i én katalog.
Vi kan rett og slett ikke bruke den på grunn av risiko for å krasje hele filsystemet og ta med oss alle andre systemer i produksjon som bruker dette.

Testingen jeg gjorde er relativt enkel:

  1. Opprettet tomme filer på 20 GB, loopback-montert og formattert med filsystemet som skulle testes
  2. Kopierte 1.6M (1.644.553) filer på til sammen 19 GB, alle i én katalog, til hver av filsystemene
  3. Tømte Linux OS-cache før testing av hvert filsystem
  4. Tok tiden for detailjert sortert utlisting (kald test)
  5. Tok tiden for detailjert sortert utlisting enda en gang (varm test)
  6. Tok tiden for usortert utlisting (varm test)

I tillegg tok jeg noen notater om komprimeringsgrad for de filsystemene som støttet komprimering, og hvor mye OS-cache og minne som ble brukt etter gjennomført testing.
Maskinene har noen bakgrunnsprosesser som vil kunne allokerer noe minne mens testene kjøres, men jeg anses aktiviteten på disse som lite i forhold til ressursbeslaget disse testene vil gjøre.

Hastighet på lesing eller skriving av innholdet i filene er ikke det viktigste for oss.
Det er små filer, fra 50 KB til 500 KB, så det er viktigere at vi kan lese flere filer raskt enn å lese én stor fil raskt.

Vi trenger et filsystem som lar oss jobbe med filene, skrive nye filer, flytte filer og kopiere filer når behovene melder seg, istedenfor å krype stille sammen for å dø – altså er uthenting av metadata om filer og utlisting av filene viktige kriterier.

For å tømme OS-cache på Linux kjørte jeg følgende kommando:


echo 3 | sudo tee /proc/sys/vm/drop_caches

For utføring av testen “detailjert sortert utlisting” kjørte jeg følgende kommando:


time ls -lht KATALOG | wc -l

For utføring av testen “usortert utlisting” kjørte jeg følgende kommando:


time ls -1 -U KATALOG | wc -l

Disse kommandoene tar tiden for å liste ut filer.
I steden for å bruke tid på å printe ut all teksten til konsollet så gjorde jeg en telling av linjer, som også ble en verifikasjon på at jeg hadde kopiert over alle filene til alle filsystemene som ble testet.

Testoppsett

Filene lå opprinnelig på Server1 på et EXT4-filsystem.
Disse ble kopiert over til Server2 hvor testene av de andre filsystemene ble gjort.
Server2 hadde omtrent ingen annen aktivitet mens testene pågikk, så målingene skal være nokså nøyaktige.
For å måle opp mot problemet vårt ble også testene gjennomført på Server1 mot EXT4.
I tillegg gjennomførte jeg en test på Server1 over NFS mot XFS-filområdet til Server2.

Filsystemene ble i hovedsak opprettet med standard-opsjoner på Ubuntu 14.04.1 LTS.
Komprimering ble aktivert i BTRFS og ZFS.

Resultater

På Server1 gjennomførte jeg en tømming av OS-cache, men målte ikke minneallokeringsbruk, da det er andre tjenster som kjører på serveren, og det kunne gitt villedende resultater.

NFS-testen fra Server1 mot Server2 sitt XFS-testoppsett mangler noen måletall, tall jeg anså som uviktige å måle på grunn av nettverksseparasjonen.
Den kalde testen av detaljert utlisting av filer ble ikke gjennomført over NFS.

Skriving av filer til ZFS ble merkbart tregere for hver fil som ble skrevet – i starten var overføringshastigheten over 6.5 MB/s, men slutta på 3.2 MB/s.
Usikkert om det skyldes komprimering, diskstørrelse eller andre årsaker.

Server1 Server2 Server2 Server2 Server1
EXT-4 BTRFS XFS ZFS NFS over Server2 XFS
Block-size (GB) 83 10 25 10
Diskbruk (GB) 19,0 8,0 19,0 6,5
KB / inode 16,0 1,0 1,0 0,5
detailjert sortert utlisting (kald) 03:22 03:36 01:53 08:20 ???
detailjert sortert utlisting (varm) 00:44 00:19 00:16 00:33 07:40
usortert utlisting (varm) 00:02 00:02 00:01 00:15 00:15
Allokert RAM (GB) ??? 5,9 3,45 3,3
OS-cache (GB) 0,1 3,7 0,8 1,4

Tid ble målt i minutter og sekunder.
BTRFS, XFS og ZFS allokerer inodes dynamisk.

EXT4 var eneste som hadde et maksimalt antall inodes.
BTRFS rapporterte ikke om inodes i “df -i”, verken ledige eller brukte.
Både XFS og ZFS var fleksible i ledige inodes som ble rapportert og endret seg i takt med ledig diskplass.

Alle filsystemene gjennomførte testene innen akseptabel hastighet når systemet var varm.
Allikevel var BTRFS og XFS de raskeste her med svar på under 20 sekunder, mens ZFS brukte 33 sekunder og EXT4 brukte 44 sekunder.

XFS var klart raskest når systemet var kald med svar på under 2 minutter.
EXT4 og BTRFS var nokså like med omkring 3,5 minutter når systemet var kald.
ZFS brukte uakseptabel lang tid (over 8 minutter) når systemet var kald.

EXT4, BTRFS og XFS leverte et akseptabelt raskt svar på usortert utlisting av filene, på maksimalt 2 sekunder.
XFS var raskest, på 1 sekund.
ZFS brukte uakseptable 15 sekunder.

Alle filsystemene unntatt EXT4 allokerte mye minne og cache for å utføre testene.
Det er usikkert om loopback-monteringen på Server2 kan ha hatt innvirkning.
EXT4 allokerte bare 109 MB som cache, men den var også noe tregere enn de andre når systemet var varm.
XFS allokerte 3.5 GB minne, hvorav 830 MB cache.
ZFS allokerte 3.3 GB minne, hvorav 1.4 GB cache.
BTRFS allokerte 5.9 GB minne, hvorav 3.7 GB cache.

Konklusjon

Vi anså XFS til å være best for våre behov.
Den leverte svar innen akseptabel tid både da systemet var kaldt og varmt, og var også den raskeste til å levere usortert utlisting av filene.

ZFS skuffet stort med uakseptabelt trege svar.
BTRFS brukte for mye minne, men ellers virket den lovende.

Felles for både BTRFS og ZFS var at komprimering var aktivert.
Kanskje kunne minnebruken vært lavere for både BTRFS og ZFS om testingen ble utført uten komprimering.

Det er god aktivitet rundt BTRFS i Linux-kildekoden og ser ut til å bli arvtakeren til EXT3/4.
BTRFS har funksjoner for blant annet komprimering og snapshotting, og det vil være aktuelt med ny vurdering av BTRFS senere.

Avslutning-rant

Etter at ny diskenhet ble koblet til Server1 og XFS ble satt opp, så dukket et nytt problem fram – overføring av filene fra EXT4-partisjonen til den nye XFS-partisjonen gikk i trege 1 MB/s.
Løsningen ble å overføre filene tilbake fra Server2 sitt XFS-filsystem over NFS…

Et enda større problem møtte vi med en annen katalog, som inneholder omkring 1.1 millioner kataloger, som igjen inneholder filer, men mer om dette kan diskuteres over et par kanner kaffe – jeg har god tid…

Montering og vanntest av ølbryggerutstyr – Beer Brew 30

6. august 2014 · Comments Off


Knutebrygg, som jeg valgte å kalle hjemme-/pico-bryggeriet mitt har sin egen blogg.

Jeg kjøpte Komplett startpakke Beer Brew 30 v.3 fra Ølbrygging.no.
Pakken ble raskt levert med Posten; fikk hentemelding 3 dager etter bestilling.

To ting manglet og blir ettersendt: Refraktometer og Kapselpåsetter.
Litt surt at jeg ikke får målt oechsle når jeg skal sette mitt første brygg, men håper da inderlig at kapselpåsetteren kommer før ølet er ferdig utgjæret og skal flaskes…

Bli kjent med utstyret

Det er viktig å bli godt kjent med utstyret.
Jeg bestemte meg for å montere utstyret og få god oversikt over delene og bryggeprosessen, og dette gjorde jeg ved å gå igjennom hele bryggeprosessen, men bare med vann.

På denne måten kan jeg få en oversikt over eventuelt utstyr jeg mangler når jeg skal brygge det ordentlige ølet og hvilke effekt og temperaturer som er passende under forskjellige steg i bryggeprosessen.

Jeg satte i gang med testingen 1. august 2014.

Arbeidsrom

Arbeidsrommet er et grovkjøkken med full kjøkkenløsning, gulvbelegg og dusj.
Der har jeg god tilgang til vann og sluk, og mulighet for å varme opp vann på komfyr jeg trenger til utmeskingen.

Montering av kjølespiral

Slanger til kjølespiralen fulgte ikke med.
Jeg kjøpte en hageslange på 20 meter, 2 slangeklemmere, 2 Gardena hurtigkoblinger og én Gardena krankobling 21 mm (G 1/2″) for montering på dusjkran.

Jeg valgte en stivere hageslange enn de “tynne grønne” som ofte får seg en knekk, selv om det kostet litt mer.
For at kjølingen skal fungere best mulig bør det være god gjennomstrømming av vann, og da slipper jeg å tenke så mye på å rette ut alle de bøyde hjørnene på slangen når jeg setter i gang kjølingen.

Jeg kappet opp slangen i passe lengder, slik at det passer mellom krana på dusjen (arbeidsrommet er et type grovkjøkken) og kokeren (Beer Brew 30).
Det ene kappet er på 2,20m, med Gardena hurtigkobling montert i den ene enden, for kobling til Gardena-tuten på dusjkrana, og den andre enden festa med slangeklemme til kjølespiralen.
Det andre kappet er på 3,30m, festet med slangeklemme til kjølespiralen i den ene enden, og den er såpass lang nok til å legges i en sløyfe i dusjen, slik at den ligger nokså i ro når vannet strømmer igjennom.

Montering av sirkulasjonspumpe

Alt fulgte med for montering av sirkulasjonspumpa.
Monterte en av de to tynne slangene mellom krana på kokeren og filteret.
Filterkomponenten har en retningspil.
Det fulgte også med et grovere filter, men dette har jeg ikke brukt ennå.
Pass på at beholderen er skrudd godt igjen på filteret, ellers vil det lekke (erfart).
Skrudde så den korteste av de litt tykkere slangene til inntaket på pumpa (retningspil), og den andre enden av slangen festet jeg til utgangen på filteret med slangeklemme.
På utgangen av pumpa skrudde jeg på kulekrana, og på utgangen av kulekrana skrudde jeg på den lengste av de tykke slangene, og enden på denne slangen skal så festes på toppen av kokeren.

Koker

Effektregulatoren på kokeren er noe feilmerket, slik at når knotten er skrudd til maks effekt vises dette som ca 90% på apparatet.
Dermed kan jeg anta at halv effekt vil vises som 40% på den feilmerkede etiketten.

Test oppvarming

Testet oppvarming av rent vann på maks effekt, både med og uten lokk, først opp til 70 grader uten lokk, og så med lokk til full kok.

Vannet fra springen holdt 17 grader ved start av oppvarming.
Romtemperatur var 26 grader.

Uten lokk så ble varmen veldig ujevnt fordelt i karet.
Jeg satte termostaten til 70 grader, og det tok 30 minutter å nå 61 grader.
Jeg satte så på lokk, og termostaten slo så ut etter 9 minutter da temperaturmåleren på karet viste 75 grader, mens et eksternt digitalt termometer viste 70 grader.
Etter litt tid under lokk så viste det eksterne termometeret likt som termometeret på kokeren.

Senket så termostaten til 60 og prøvde ny oppvarming til 70 grader, nå med lokk og sirkulasjon med pumpe, og denne gangen slo termostaten ut på 72 grader.

Da jeg stilte termostaten til 80 grader, så viste begge termometerene det samme (+/- 1 grad) underveis opp til 80 grader.

Test av “keep warm”

Etter oppkok til 100 grader, så testet jeg hvor mye effektregulatoren må stå på for at temperaturen skal holde seg og at vannet skal fortsette å koke.
Jeg testet kun uten lokk, og kom fram til at 50% effekt (som vist på den feilmerkede etiketten) var nok til å holde 100 grader, og å øke temperaturen sakte dersom den hadde falt noen grader.

Test av kjøling med kjølespiralen

Ved 100 grader så satte jeg kjølespiralen oppi kokekaret, skrudde av kokeren, og startet sirkulering med kaldt vann fra dusjkrana.

Det tok 20 minutter å senke temperaturen fra 100 grader til 28 grader, men derfra tok det lenger tid å kjøle ned grad for grad.
Det tok totalt 60 minutter å nå 24 grader, men jeg målte da 22 grader lenger ned i karet.
Det var vesentlig mye varmere i vannet som lå over kjøleren, mens i området rundt kjøleren og under var det mye kaldere enn hånda (merkbart ved å legge hånda på kokekaret).

Jeg har en teori om at jeg kan starte å tappe vørteren over til gjæringskar når nedre del er kald nok, og at det øvre laget vil bli kjølt ned tilstrekkelig mens væskestanden synker og passerer kjølespiralen i karet.

Erfaringer og behov

Etter disse testingene lærte jeg litt om hvor lang tid bryggeprosessen vil ta og hvilke hjelpemidler og utstyr jeg vil trenge.

Jeg trenger en liten klut jeg kan løfte silkaret med, da dette håndtaket er tynt og vil holde 80 grader etter meskingen er ferdig.

Jeg trenger en meskeskje, noe å røre i malten med under mesking.

Slanger med vanntrykk har en lei tendens til å røre på seg og det var flere ganger at gulvet ble vått.
Det følger med en festeordning for å feste en slange på toppen av kokekaret, men jeg følte at slangene ikke alltid var godt nok festa.

I tillegg ser jeg behov for å kunne hekte slangeendene opp i høyden når jeg ikke bruker dem, slik at de ikke faller ned og drypper utover gulvet, samt at det gjerne er mer støv, rusk og bakterier på gulvet enn i luft.
Selv om kokeprosessen vil drepe de fleste bakterier så ønsker jeg ikke rusk oppi brygget.

Første brygg

Første brygg er allerede satt, Pale Ale.
Detaljer om hvordan første batch gikk kommer senere.

Konklusjon

Jeg gleder meg til brygge mange øl og bli skikkelig godt kjent med utstyret – da tror jeg dette kommer til å gå som en lek!

Bigdata RDF-server erfaringer

23. juni 2014 · Comments Off

I jobbsammenheng jobber jeg mye med modellering av data i RDF.

Vi har lenge lagret RDF-grafer som filer på disk, men har den siste tida undersøkt flere RDF-databaser.

Felles for de fleste grafdatabaser er at de trives best i RAM.
Store installasjoner som skryter av å lagre milliarder av tripler består enten av servere med masse minne, eller av mange maskiner i et kluster som tilsammen innehar mye minne – da snakker vi størrelsesorden hundrevis av GB RAM.

Tidligere tester av RDF-databaser

Vi har tidligere testet Jena Fuseki og OpenLink Virtuoso, men begge har sine irriterende problemer.

Jena Fuseki TDB

Jena Fuseki med TDB blir fort ubrukelig når databasen blir større enn Java heap-size, og den feiler ofte med OutOfMemoryError.
Testet med 4 GB Java-heap.

OpenLink Virtuoso

OpenLink Virtuoso har vi testet i versjon 6 og versjon 7.
Versjon 6, som følger med i pakkesystemet til Ubuntu, støttet ikke SPARQL UPDATE.
Versjon 7 feiler når vi prøver å laste inn grafer som inneholder mange blank nodes, selv om vi klarte å hacke oss til en løsning ved å splitte opp insertene i mindre deler.
Generelt sett har Virtuoso flere irriterende problemer, blant annet at den ikke forstår “INSERT DATA” fra SPARQL UPDATE – her måtte vi bruke “INSERT INTO”.

Bigdata

Jeg har i noen dager testet Bigdata, en server for lagring og spørring over RDF-data.

Bigdata-serveren er en Java-applikasjon som kjører i en standard Servlet applikasjons-container.

Innlasting av data

Datagrunnlaget er oppdelt i 525K (525.000) grafer – dokumenter i RDF/TURTLE-format.

Grafene inneholder mange blank nodes, ressurser som ikke er navngitte og globalt identifisérbare med IRI.
Grunnen til at vi bruker blank nodes er fordi vi konstruerer ressurser sammensatt av data fra kildesystemer som ikke tilordner ID-er til disse konseptene.
Dersom vi skulle konstruert ID-er for disse ressursene må vi bruke mye energi og mange kodelinjer for å holde de ID-ene stabile, for å tilordne de samme ID-ene ved neste eksport fra kildesystemet – da er det mye enklere å konstruerer blank nodes.

Innlasting av data ble gjort graf for graf i form av SPARQL UPDATE-meldinger over HTTP, hver delt i to seksjoner – først sletting av eksisterende tripler i grafen, for så innsetting av nye tripler i samme graf.

Sletting av grafer er en viktig funksjon i vårt tilfelle, da vi ønsker å bytte ut alle tripler fra en eventuell gammel versjon av grafen med tripler fra en ny versjon.
Utskiftingen av hele grafer ønsker vi å gjøre som en atomisk operasjon for å unngå at en graf fremstår som tom før nye data lastes inn.

Serveroppsett

Jeg startet med å kjøre Bigdata i en Jetty-container på en server med 4 GB RAM og 100 GB disk – dbdev01.
Med unntak av lokasjonen til journal-fila (databasen til Bigdata), kjørte jeg med standardinnstillinger og 2 GB Java-heap.

Datamengder

Mot denne lastet jeg inn ca 450K (450.000) grafer.
Dette utgjorde i overkant av 84M (84.000.000) tripler.

Journal-fila vokste til 14 GB.

Ytelse ved innlasting av data

I starten klarte jeg å laste inn ca 10 grafer per sekund.
Det er ikke spesielt imponerende hastighet, men siden dette var en test så lot jeg prosessen fortsette.
Etter ett døgn var hastigheten nede i 2-3 grafer per sekund.
Etter to døgn var hastigheten nede i 1-2 grafer per sekund.

Å gjøre SPARQL-spørringer mot databasen samtidig som importen pågikk var bortimot ubrukelig, selv enkle spørringer som å hente ut navn på 60 ressurser.
Samtidig sakt importhastigheten ned til ca 1 graf per 10 sekunder.

Da var 450.000 grafer importert, 85% av datasettet vårt, som for tiden øker med ca 100.000 grafer per år.
Dette skalerer ikke.
Bestemte meg for å avbryte importen.

Ny server med mer minne

Jeg fikk en ny server til rådighet, med 32 GB RAM og 100 GB disk – dbdev02.
Serveren kjørte allerede noen tjenester, så jeg hadde ca 28 GB RAM ledig.
Ellers var det lite last på serveren.

Jeg kopierte journal-fila på 14GB fra dbdev01 til dbdev02, og starta opp Bigdata på begge servere, samme konfigurasjon, og med 1 GB Java heap.

Ytelsestester spørringer

Gjorde samme tester mot begge serverne.

Test #1

Første spørringen mot serveren er en SPARQL-spørring med datofiltrering og dybde på 5 (Vedlegg 1).
Resultatet fra spørringen er ca 80K (80.000) løsninger, i SPARQL RESULTS XML-format på 75 MB.

Ved kald, nyoppstartet Bigdata var dbdev02 (24s) vesentlig raskere enn dbdev01 (2m31s).

Ved gjentatte utføringer av samme spørring var begge servere nokså like raske, også etter kjøring av andre relativt enklere spørringer i mellomtiden.

Test #2

En annen spørring som ga store utslag var med dybde på 4, uten filtrering og med LIMIT 100.000 (Vedlegg 2).
Resultatet fra spørringen er ca 53K (53.000) løsninger, i SPARQL RESULTS XML-format på 22 MB.
Resultatet var altså mindre enn den angitte begrensningen på 100K.

dbdev02 (1m19s) var mye raskere enn dbdev01 (12m23s).
Dette var med varm database.

Innlasting av data mot 32 GB minne

En ny test av import av data, som inkluderer overskriving av gamle grafer, denne gang gjort mot dbdev02 med 32 GB minne, viser en importhastighet på ca 5 grafer i sekundet.

Analyse av testresultatene

Den største forskjellen er rett etter Bigdata nettopp har starta opp.
Mange av spørringene som ga store utslag etter kald oppstart returnerte omtrent like raskt etter gjentagende spørringer.
Dataene i resultatet blir muligens cachet et sted.

Minne

dbdev01 har etter noen spørringer lite ledig RAM, mens dbdev02 har mye ledig RAM.
Det kan tyde mot at Bigdata har det bedre når mye av datafila ligger i minnet.

Diskytelse

Hjelper nok også om disken er rask.
Virker som at disken er raskere på dbdev02 enn dbdev01.
En test lokalt på hver server viser at kopiering av fil på 1 GB tok 14.5s på dbdev01 og 6.2s på dbdev02.
Ingen prosesser på noen av boksene som bruker nevneverdig mye disk-IO når Bigdata idler.

Swapping

Kanskje swapping på dbdev01 kan være årsak, selv om swap-aktiviteten for tiden er lav.

Munin-graf over minne for dbdev02 viser en økning på 16GB i cache (fil-cache) etter oppstart av Bigdata.
Null swapping.

Munin-graf over minne for dbdev01 er fullstendig mongo, går opp og ned som en jojo i den perioden Bigdata har kjørt (2 dager).
Viser også mye swapping, spesielt under inserts.

Konklusjon

Bigdata trives veldig godt med mye RAM og bruker operativsystemets filcache for å få rask aksess til dataene.

Bigdata feiler ikke like dramatisk som Jena Fuseki TDB når minnet går fullt.
Selv om vi endte opp med å teste Bigdata med mer minne enn vi testet med Jena Fuseki TDB, så taklet Bigdata med 4 GB minne mye større datasett enn Jena Fuseki TDB klarte med det samme.

Det er ikke så viktig med stor Java heap under innlasting av data.
Heap-størrelsen øker når det gjøres spørringer, så større heap har kanskje en positiv effekt ved mange og tunge spørringer.

Den nye innlastingstesten viser at Bigdata er mye raskere på innlasting av data dersom den har nok minne til databasen.

Vedlegg

Vedlegg 1: SPARQL Test #1

SPARQL-spørring som lister ut avspilt musikk i en tidsperiode på én måned:

PREFIX dct: <http://purl.org/dc/terms/>
PREFIX ebuccdm: <http://www.ebu.ch/metadata/ontologies/ebuccdm#>
PREFIX digas: <http://id.nrk.no/2013/digas/class/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT * WHERE {
  GRAPH ?g {
    ?part a digas:Music .
    ?timeline ebuccdm:hasTimelineTrackPart ?part .
    ?prog ebuccdm:hasTimelineTrack ?timeline .
    ?trans ebuccdm:playsOut ?prog .

    ?part dct:title ?partTitle .
    ?prog dct:title ?progTitle .
    ?trans ebuccdm:publicationStartDateTime ?startTime .
    FILTER ( ?startTime >= "2014-01-01T00:00:00+01:00"^^xsd:dateTime ) .
    FILTER ( ?startTime < "2014-02-01T00:00:00+01:00"^^xsd:dateTime ) .
  }
}
ORDER BY ?startTime

Vedlegg 2: SPARQL Test #2

SPARQL-spørring som lister ut medvirkende på programmer med en begrensning på 100.000 resultater:

PREFIX nrk: <http://gluon.nrk.no/dataordbok.xml#>
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX ebuccdm: <http://www.ebu.ch/metadata/ontologies/ebuccdm#>

SELECT ?obj ?title ?contactName ?roleName
WHERE {
    ?obj a nrk:programme .
    ?obj dct:title ?title .
    ?obj ebuccdm:hasContributor ?contributor .
    ?contributor ebuccdm:contactName ?contactName .
    ?contributor ebuccdm:hasRole ?role .
    ?role ebuccdm:roleName ?roleName .
} LIMIT 100000

HTC One – trådløst nettverk funnet…

5. juli 2013 · 2 Kommentarer

Ja, så koble deg til det da!! Et av de mest irriterende problemene med HTC One er trådløst nettverkstilkoblingen. Eller mangel av det. Når jeg aktiverer trådløst nettverk tar det gjerne et halvt minutt før den finner nettverket til basestasjonen ved siden av meg. Av og til kobler den seg til, men av og til klager den på autentiseringsproblemer… på et åpent usikra nettverk… WTF?

Når jeg har brukt telefonen litt og har lagt den fra meg for en kort periode før jeg tar den ibruk igjen, så hender det at den forteller meg at alt er i skjønneste orden… men hvor er Internett? Nettleseren har ikke skjønt det ennå, men det er faktisk ingen kobling mot det trådløse nettverket. Løsning: skru av og på trådløst på telefonen… og vente 30 sekunder.

Irriterende! Ellers grei telefon!

Synd det er så gammel Android på den, 4.1.2. Jeg kjører nyere Android på min gamle HTC Desire! Blir nok roota i løpet av sommeren! God sommer :D

Tilkoblingsparametere for å styre Denon AVR 2807

10. oktober 2012 · Comments Off

Jeg har koblet stue-PC-en til receiveren i hjemmekinoanlegget som er en Denon AVR 2807. Den er koblet til med en USB-til-seriell-kabel, slik at jeg kan styre receiveren ved å sende kommandoer til den, men dette skrev jeg om for mange år siden.

Det jeg derimot glemte å skrive var hvordan man skulle koble opp mot den for å sende kommandoer, noe jeg så klart har glemt siden den gang og trøblet litt med i kveld.

Det jeg sleit mest med er at alle terminalklientene jeg testet har aktiv maskinvarebasert flytkontroll, noe som ikke fungerer mot denne receiveren. Så det må skrus av.

Dette kan gjøres via minicom eller kermit. Beskrivelse finnes blant annet hos Gumstix Developer Center.

Etter at flow control er skrudd av kan minicom kjøres:

minicom -b 9600 -D /dev/ttyUSB0 -8 -o

Et tips hvis du bruker minicom er å aktivere “Add linefeed” i konfigurasjonen av “Screen and keyboard”.

FreeBSD top of network connections

2. oktober 2012 · Comments Off

To view the active connections in FreeBSD, which might be a very good debugging/overview tool for a router, one can use ipfstat -t.

This will output something like this:

Source IP             Destination IP         ST   PR   #pkts    #bytes       ttl
10.1.1.100,1052       199.47.216.148,80     4/4  tcp   37860   6446150 119:59:07
10.1.1.100,17500      255.255.255.255,17500 0/0  udp   11681   1740469      1:55
10.1.1.100,17500      10.1.1.255,17500      0/0  udp   11681   1740469      1:55

Finding which Windows process uses what IP socket

2. oktober 2012 · Comments Off

To find out which application uses what IP port on a Windows, both open listening sockets and open connections, you can use netstat with some options and then grep for the port number, or findstr as it’s called in Windows world.

netstat -ano | findstr “:xxxx”

This outputs something like this:

Aktive tilkoblinger

  Prot. Lokal adresse          Ekstern adresse          Tilstand           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       1232
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:17500          0.0.0.0:0              LISTENING       3500
  TCP    10.1.1.100:139         0.0.0.0:0              LISTENING       4
  TCP    10.1.1.100:1051        10.1.1.1:443           CLOSE_WAIT      3500
  TCP    10.1.1.189:1052        199.47.216.148:80      ESTABLISHED     3500

In the right column you’ll find the PID of the process using the socket. Open task manager, make sure the PID column is visible (might need to add it to the view, then look around in the drop down menus).

Windows Task Manager shows process PID of Dropbox

Windows Task Manager shows process PID of Dropbox

Source: http://www.windowsnetworking.com/kbase/WindowsTips/WindowsServer2008/AdminTips/Network/DeterminingwhatserviceorapplicationownsaTCPport.html

KMail – Use GSSAPI for authentication to IMAP account

21. september 2012 · Comments Off

On a freshly installed Debian testing with KDE desktop, i set up KMail to read email from our corporate MS Exchange server using the IMAP protocol.

The curiosity in me wanted to check out GSSAPI for authentication, but the IMAP server replied with SASL(-4): no mechanism available: no worthy mechs found.

Of course, I need the krb5-user package and run the kinit command to retrieve a valid Kerberos session ticket. What wasn’t so obvious was the need for the package libsasl2-modules-gssapi-mit. Voila! Got me some emails :D

Redshift – a Linux tool for late nights

6. september 2012 · Comments Off

Redshift is a nice Linux tool for adjusting the color temperature of the screen according to time of the day.

At night this tool makes the screen a bit warmer, so your eyes wont “hurt” so much of the otherwise so bright display of your desktop background, browser or editor.

You provide the tool with your approximately geo coordinates and some value for upper and lower limit of color temperature, then it will automatically and continuously change color temperature all through day and night.

Example command for running this tool, if your’re in Norway:

$ redshift -l 60.0:10.0 -t 5700:3600 -g 0.8 -m vidmode -v

MIME Multipart, boundary og linjeskift

3. august 2012 · Comments Off

MIME Multipart-meldinger er kresne og er vanskelige å håndkode.
Det er allikevel mulig å håndkode dem hvis man har god nok teksteditor (som kan vise kontrolltegn som linjeskift) og god tålmodighet og tunga rett i munnen.

MIME-meldinger krever CRLF-endinger på linjene før og etter boundary-kodene og etter hver MIME-header.
I eksempelet nedenfor representeres hvert linjeskift som LF.

MIME-meldingseksempel

De steder hvor det står ^M brukes CR, som oftest rett før linjeskiftet.


--part-boundary-1^M
Content-Type: text/plain; charset=utf-8; name=litt-tekst.txt^M
Content-ID:
^M
Content-Disposition: attachment; name="litt-tekst.txt"; filename="litt-tekst.txt"^M
^M
Dette er noe tekst i en fil som heter some-text.txt
Denne fila bruker UNIX-linjeendinger, altså LF og ikke CRLF,
og det er helt i orden, siden innholdet av denne tekstfila er utenfor kontekst av MIME.

Dette er siste linje i fila^M
--part-boundary-1^M
Content-Type: image/png; name=lite-bilde.png^M
content-transfer-encoding: base64^M
^M
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAL
EwAACxMBAJqcGAAAAAd0SU1FB9wIAwwLKSOxKhgAAAAZdEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRo
IEdJTVBXgQ4XAAAAMklEQVQoz2P8z4AD/Mcuw8RAIhjGGv7/J0UDbtUMDAws+KQZGUnxAzbVuDXg
UD1SYxoAH7UJHx3uIsQAAAAASUVORK5CYII=
^M
--part-boundary-1--^M

Store og små bokstaver i navn på MIME-headere har ingen betydning.

Blokk og separatorkoder (boundary)

I denne meldingen bruker vi separatorkoden (boundary) part-boundary-1.
Separatorene i fila prefikses med --, som viser til start på en MIME Part-blokk.
En slik blokk varer fram til neste separator av samme kode.
Siste separator appendes med -- i tillegg til prefiksen, som betyr at det ikke er flere blokker.

En blokk i en multipart kan også være en multipart, men blokker under denne separeres med egen separatorkode.

Teste meldingen mot en server

For å teste opplasting med HTTP til en web servlet kan man bruke curl.
Vi lagrer multipart-meldingen på fil melding.multipart.
For at serveren skal kunne forstå multipart-meldingen må Content-Type-headeren spesifiseres som multipart/related og boundary satt til part-boundary-1.

Eksempel på kommando:


$ curl -X POST \
    -H "Content-Type: multipart/related; boundary=\"part-boundary-1\"" \
    --data-binary @melding.multipart \
    "http://localhost:8080/multipartServlet"

Forskjellige biblioteker og krav til CRLF

Det er noe forskjeller i hvordan forskjellige kodebiblioteker tolker multipart-meldinger.
Noen tillater linjeendinger med bare LF (uten CR), mens andre er strengere og krever CRLF.

Servlet 3 sin multipart-parser er streng og krever CRLF.
Samme er tilfellet med CXF sin SOAP-Attachment-parser.

Telia MMS MMSC-parser er derimot mer tilgivende.

Ansvarsfraskrivelse…

Det er ikke sikkert jeg har forstått dette 100% ennå.
Det kan være at mitt håndkoda eksempel over inneholder noen skrivefeil.
Jeg hadde Java i tankene da jeg skrev dette, og det er Java jeg har arbeidet med for behandling av MIME-meldinger da jeg forsket på feilscenariene jeg har hatt med linjeendinger.

Mer om MIME-meldinger

RFC 1341 og spesielt seksjonen 7.2 om multipart gir mer informasjon om strukturen til MIME multiparts.