Nedprioitering af cli-kommandoer

[NickyThomassen]

I forbindelse med min DNS-server på lokalnetværket vil jeg meget gerne analysere logfilerne så jeg kan se hvilken lokal-ip der besøger hvilken side. Jeg har med hjælp fra forum og AJ konstrueret en kommando der gør netop det, men nu hvor logfilerne så småt begynder at blive store, får jeg problemer.

BIND9 gemmer logfilerne i 8 * 5mb bider, dvs. 1 aktuel og 7 gamle, som jeg exportere fra serveren til min stationære med

Kode: Vælg alt

cat /var/log/bind_queries.log* > /volume1/download/bind_queries.log

Omend det tager lidt tid, så virker det fint. Resultatet er én 30mb fil, som jeg så prøver at sortere med

Kode: Vælg alt

awk '{ print $5 }' < ~/Desktop/bind_queries.log | sort | uniq -cd -w 13 | sort -rbfn > ~/Desktop/værter && awk '{ print $7 }' < ~/Desktop/bind_queries.log | sort -r | uniq -cd | sort -rbfn >> ~/Desktop/værter

(Jeg kopiere logfilen over på skrivebordet inden jeg køre sorteringskommandoen)

Problemet er at overstående kommando hårdt og kontant crasher Debian, noget der ellers aldrig sker. Kører jeg kommandoen med

Kode: Vælg alt

nice -n 19

foran, så er det kun X-Serveren der går ned, og efter ~60 sekunder er Debian klar igen. Jeg køre kommandoen fra en terminal-emulator, så jeg regner med det er derfor det kun er X-Serveren der går ned når kommandoen bliver kørt med nice.

Jeg kunne selvfølgelig nøjes med 1 5mb logfil istedet for at slå dem sammen, men det svarer lidt til at gå udenom problemet, og det lære jeg ikke noget af...

Der skulle vel ikke være nogen blandt læserne der har nogle forslag, måske ser problemet eller kender en løsning?

Hilsen Nicky

[lath]

I forbindelse med min DNS-server på lokalnetværket vil jeg meget gerne analysere logfilerne så jeg kan se hvilken lokal-ip der besøger hvilken side. Jeg har med hjælp fra forum og AJ konstrueret en kommando der gør netop det, men nu hvor logfilerne så småt begynder at blive store, får jeg problemer.

BIND9 gemmer logfilerne i 8 * 5mb bider, dvs. 1 aktuel og 7 gamle, som jeg exportere fra serveren til min stationære med

Kode: Vælg alt
cat /var/log/bind_queries.log* > /volume1/download/bind_queries.log


Omend det tager lidt tid, så virker det fint. Resultatet er én 30mb fil, som jeg så prøver at sortere med

Kode: Vælg alt
awk '{ print $5 }' < ~/Desktop/bind_queries.log | sort | uniq -cd -w 13 | sort -rbfn > ~/Desktop/værter && awk '{ print $7 }' < ~/Desktop/bind_queries.log | sort -r | uniq -cd | sort -rbfn >> ~/Desktop/værter


(Jeg kopiere logfilen over på skrivebordet inden jeg køre sorteringskommandoen)

Problemet er at overstående kommando hårdt og kontant crasher Debian, noget der ellers aldrig sker. Kører jeg kommandoen med

Kode: Vælg alt
nice -n 19


foran, så er det kun X-Serveren der går ned, og efter ~60 sekunder er Debian klar igen. Jeg køre kommandoen fra en terminal-emulator, så jeg regner med det er derfor det kun er X-Serveren der går ned når kommandoen bliver kørt med nice.

Jeg kunne selvfølgelig nøjes med 1 5mb logfil istedet for at slå dem sammen, men det svarer lidt til at gå udenom problemet, og det lære jeg ikke noget af...

Der skulle vel ikke være nogen blandt læserne der har nogle forslag, måske ser problemet eller kender en løsning?

Hilsen Nicky

Kernen lukker et program uden varsel, hvis det bruger for mange ressourcer.
Har du ikke så meget fri RAM tilbage lukker kernen dine programmer, når grænsen for at bruge mere RAM er nået. Det ser også ud til at det omfatter hele proces-træer.
Det er ikke en fejl - det er en feature, og du kan ikke slå det fra (uden at omkode kernen).
Denne proces dræber feature har det formål at holde liv i kernen, uanset om der skulle være et program, der går amok i ressource forbrug.

Du kan løse det ved at tilføje mere fysisk RAM, eller endnu bedre: omkode scriptet så det behandler en strøm (stream) af data. Det bruger ikke ret meget RAM, men kan være meget sværere at lave.

Streaming teknik:
fil(er)1 -> program1 -> fil(er)2 -> program2 -> filer3 -> ... -> filerN -> programN -> filerN+1
(samme metode som mainframe computere bruger)
I Linux kan du evt. bruge filer i /tmp, hvis du har en stor nok Linux swap. Det har den fordel at er der plads nok i RAM, bruges der RAM, er der ikke plads nok i RAM, begynder tmp filsystemet at bruge Linux swap.

Du kan oprette en Linux swap fil, og bruge swapon kommandoen til at mounte din Linux swap fil.
Teknikken er:

• Kode: Vælg alt

  sudo dd if=/dev/zero of=/media/extra-swap bs=1024  count=262144

  
  Du kan skrive noget andet for 'count=':
  
  • en count på 1 giver 1 Kb swap
  • count på 1024 giver 1 MB swap
  • count på 262144 giver 256 MB
  • ... etc. - gang selv op.
    count tallet skal helst være deleligt med 4, da en page (den mindste blok i RAM) netop er 4 Kbytes.

• Kode: Vælg alt

  sudo mkswap /media/extra-swap

  kommandoen formatterer fil som en Linux swap block device

• Kode: Vælg alt

  sudo swapon -v -f /media/extra-swap

  mounter Linux swap fil
• ... senere, når computeren er færdig med hukommelsesslugende program(mer) ...

• Kode: Vælg alt

  sudo swapoff -v /media/extra-swap

  unmounter linux swap fil

• Kode: Vælg alt

  sudo rm -f /media/extra-swap

  slet fil (hvis du ikke skal bruge den igen)

Nyttigt at vide: Selv om du ikke bruger en device driver direkte, er det her også rart at vide:
Bruger dit program en device driver og der i device driveren opstår en segmentation fault, så lukkes dit program ned - også uden varsel.

/Lars

[AJenbo]

Det er nok sort og uniq der kræver for meget ram da de ikke så godt kan udskrive før de har gennemgået alt input.

@lath er det virkelig nødvendigt at citere hele brugerens tekst når du svare direkte under indlægt?

[NickyThomassen]

Hej Lars og endnu engang tak for hjælpen

Jeg har 8gb ram installeret og 2gb swap allokeret, og af dem bruger systemet aldrig over 1gb ram og ingenting af swappen. Det er også min spillecomputer, derfor den lidt høje mængde ram.

Umiddelbart skulle man tro at kernen godt kan klare en 30mb-fil, den kan jo trods alt ligge i ram nogle gange, og selv hvis både, awk * 2, sort * 4 og uniq * 2 skal have filen i ram adskellige gange, har kernen alligevel 7gb...

Men jeg vil prøve og følge dit råd med at oprette en stream, dog tror jeg at istedet for at bruge /tmp, i første omgang prøve at bruge /dev/shm. shm har på mit system adgang til 4gb ram, og så slipper jeg for at bekymre mig om efterladte filer, langsom I/O og så videre.

Hilsen Nicky

[NickyThomassen]

Det her er bare en strøtanke, inspireret af din forklaring af:
"count tallet skal helst være deleligt med 4, da en page (den mindste blok i RAM) netop er 4 Kbytes."

De 30mb i logfilen er lige med 227590 linier, og selv hvis en hel linie kan være i én page, giver det 889mb ram. Kan det være derfor, computeren ikke har ram nok?

Apropos process-dræberen, er det "The Out Of Memory" (OOM)-killer du referer til? Da jeg søgte på fejlkoderne fra syslog var det nemlig den der blev ved med at kommer frem, og det ville jo egentlig give god mening.

Hilsen Nicky

[lath]

Det er nok sort og uniq der kræver for meget ram da de ikke så godt kan udskrive før de har gennemgået alt input.

Herunder bruger jeg 2 abstrakte begreber. 1 brik, og 1 sætning. Brik kommer af det engelske ord token, og sætning ja - sentence, og er fra fortolker og compiler datalogi.

1 brik udgør den mindste helhed der i et program skal forstås.
1 sætning indeholder en eller flere brikker der udgør en samlet enhed.


Hvis man lige et øjeblik antager at man stream sorterer på den første brik (hvor den første ting kan være et bogstav, dato og/eller tid f.eks).
En sætning indsættes i den fil der matcher sin første brik.
En anden sætning med samme første brik tilføjes til samme fil.

På den måde får man opdelt opgaven ud i N lige store dele.
Hvis første brik er bogstaverne a-z, så er N=25, og alt andet lige må man så også bruge 1/N (her=1/25) mængde RAM, hvis hver ting i RAM er lige stor. I prakis også til at holde styr på en hash table af første brik nøgle -> fil værdier.
Så sorterer man på hver af de 25 filer, og kører uniq på den, og tilsidt lægger man dem sammen i rækkefølge (a, b, c ... etc, hvis første ting er et bogstav)

Indrømmet:
Det er datalogi af den måske mere langhårede type, som hører til udvikling af programmeringssprog.
Det er noget op ad bakke, men når man først har forstået det kommer belønningen. Overnævnte måde at løse problemet på hedder iøvrigt language oriented programming, hvor man kort fortalt laver et programmeringssprog der passer til den opgave man skal lave, og derefter koder man løsning/programmet i det Domæne Specifikke Sprog (DSL) man lige har lavet. Bonus er at udvikling af sproget (DSLen), og at kode i sproget(DSLen) kan udføres i parallel af et udviklerteam*.
UNIX og Linux er fyldt med DSLs. Det skulle ikke undre mig om der allerede er noget der kan stream sortere på baggrund af en regex du selv kommer med.

@lath er det virkelig nødvendigt at citere hele brugerens tekst når du svare direkte under indlægt?

...plejer jeg altid at gøre ...

/Lars

*: På mit 4. semester lavede vi denne robotstyring, der sorterer rektangulære emner på baggrund ad massefylde (masse/volumen). Den styres af et DSl, som jeg udviklede på ca 3 arbejdsdage. Fortolkeren med de semantiske aktioner (kode der skal køres, når en sætning er læst) tog yderlige et par dage.
Udviklingen foregik sådan. at jeg udviklede DSLen alene, og senere gav jeg DSL specifikation til de andre. Den var så vores kontrakt på hvordan tingene skulle fungere. Jeg fortsatte så mit arbejde med fortolkeren og de semantiske aktioner. En undergruppe lave en GUI styring der snakkede med fortolkeren, en 3 gruppe lavede noget der kunne køre et program ved at hente et program fra en database.

[lath]

Apropos process-dræberen, er det "The Out Of Memory" (OOM)-killer du referer til? Da jeg søgte på fejlkoderne fra syslog var det nemlig den der blev ved med at kommer frem, og det ville jo egentlig give god mening.

Jeg fandt lige noget om killer featuren på denne side:
http://linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html
Det er noget med at der i loggen står killed, hvis kernen har taget livet af din proces/program.



Out of memory er en fejl meddelelse der kommer tilbage fra kernen, når der bare ikke er mere RAM:
Det minder mig om den anden mulighed på hvorfor et program pludselig slutter: Mange programmer vælger at kalde perror(), efterfulgt af abort() funktionen, hvis der ikke er mere RAM. Årsagen er den simple at de alligevel ikke kan fuldføre deres arbejde.
perror("valgfri tekst") skiver til loggen, og abort() er en funktion der afslutter et program uden at rydde op - den opgave bliver så overladt til kernen. Det kan give anledning til zombie processer (Z) i top-programmet.

Det her er bare en strøtanke, inspireret af din forklaring af:
"count tallet skal helst være deleligt med 4, da en page (den mindste blok i RAM) netop er 4 Kbytes."

De 30mb i logfilen er lige med 227590 linier, og selv hvis en hel linie kan være i én page, giver det 889mb ram. Kan det være derfor, computeren ikke har ram nok?

En linje fylder normalt ikke en hel page. Det er noget programmet styrer. Bruger man C og allokerer meget RAM, kommer den RAM i rækkefølge.
Linier er normalt bare adskilt af en enkelt byte, - det tegn skrives \n i C - og tegnet er allerede skrevet til slutningen af hver linie i tekstfilen før dit oprogram overhovedet åbner filen.
Programmet vil med garanti oprette et array af tekststrenge, der passer med længden af filen i bytes + 1 byte der er 0 - den information kan fås fra filsystemet.

Jeg har mistanke om at programmet allokere små mængder af RAM masser af gange. Det er ekstremt ineffektivt, og bruger nemt masser af RAM, og er dårlig stil/adfærd.
Et program der allokerer RAM får altid RAM i blokke af 4096 bytes, 4 Kbytes, altså en page. Allokerer f.eks. sort programmet masser af små mængder af RAM på f.eks 300 bytes - en meget lang linje, så æder den mange gange 4 Kbytes RAM, og så løber du måske tør for RAM (fysisk RAM + Linux swap).

Jeg tror at du ret i programmerne nok gør netop det.

Det hurtige fix kan være at oprette, formatte, og mounte en linux swap fil. For kernen er det som at få mere ultra-langsomt RAM tilføjet - men det virker. Du skal bare regne med at tingene går en faktor 100x til 1000x langsommere.

/Lars

[AJenbo]

Måske kan du prøve at debugge lidt på dit scirpt og se hvor det er du løber tør for hukommelse

Kode: Vælg alt

awk '{ print $5 }' < ~/Desktop/bind_queries.log > temp1.txt
cat temp1.txt | sort > temp2.txt
cat temp2.txt | uniq -cd -w 13 > temp3.txt
cat temp3.txt | sort -rbfn > cat temp4.txt
cat temp4.txt  > ~/Desktop/værter
awk '{ print $7 }' < ~/Desktop/bind_queries.log > temp5.txt
cat temp5.txt | sort -r > temp6.txt
cat temp6.txt | uniq -cd > temp7.txt
cat temp7.txt | sort -rbfn > temp8.txt 
cat temp8.txt >> ~/Desktop/værter

Jeg ved ikke lige hvordan awk fungere, men det virker overflødigt at du har de ekstra sort før uniq og så en ny sort. Sort før uniq vil sandsynligvis bruge flere ram en efter, så her er en uden den første sort, så vidt jeg kan regne ud vil output være ens:

Kode: Vælg alt

awk '{ print $5 }' < ~/Desktop/bind_queries.log > temp1.txt
cat temp1.txt | uniq -cd -w 13 > temp2.txt
cat temp2.txt | sort -rbfn > cat temp3.txt
cat temp3.txt  > ~/Desktop/værter
awk '{ print $7 }' < ~/Desktop/bind_queries.log > temp4.txt
cat temp4.txt | uniq -cd > temp5.txt
cat temp5.txt | sort -rbfn > temp6.txt 
cat temp7.txt >> ~/Desktop/værter

@lath er det virkelig nødvendigt at citere hele brugerens tekst når du svare direkte under indlægt?

...plejer jeg altid at gøre ...

So I have noticed

[NickyThomassen]

Apropos process-dræberen, er det "The Out Of Memory" (OOM)-killer du referer til? Da jeg søgte på fejlkoderne fra syslog var det nemlig den der blev ved med at kommer frem, og det ville jo egentlig give god mening.

Jeg fandt lige noget om killer featuren på denne side:
http://linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html
Det er noget med at der i loggen står killed, hvis kernen har taget livet af din proces/program.

Dine svar gav en del stof til eftertanke, og jeg er stadig i gang med artiklen
Videoen om den sorterende robot var god, jeg kunne især godt lide at det lykkedes robotten for det meste at holde sin grab på samme sted i rummet. Skulle i i opgaven tage højde for hvad robotten skulle gøre, hvis der kom en klods på båndet, der ikke matchede en beskrivelse af de blokke den skulle sortere?

Men ja, der stod noget med kill i sysloggen, massere af gange faktisk. OOM-killeren starter fra en ende af, og lukker programmer indtil problemet er løst, startende med programmer som Firefox og musikafspilleren. Jeg tror jeg talte omkring 10 programmer der blev lukket før den fandt det rigtige, altså terminalemulatoren (som jeg gætter på ligger under X).

Jeg tror godt at jeg kan følge princippet i n=25, og altså 1/25, men du har også ret i at tingende bliver adskellige grader mere indviklet på den måde. Det er ganske givet ikke umuligt (for mig, vel at mærke), det kommer bare til at tage lidt øvelse og eksperimenteren. Jeg prøvede tilgengæld at finde et program eller scipt der allerede kan løse opgaven, men uden held. Det virker som højt specialiseret kode, selv for Linux, eller også ved jeg ikke hvad jeg skal søge efter. Alt hvad jeg fandt var forslag der matcher det jeg allerede har gjort.

Måske kan du prøve at debugge lidt på dit scirpt og se hvor det er du løber tør for hukommelse

God idé, det havde jeg slet ikke overvejet. Jeg prøvede først som du havde skrevet, og endte med ~3.5mb der skulle sorteres af sort, den gik ned. Så prøvede jeg en anden rækkefølge, så sort kun skulle tage ~650kb, den gik ned...

Så det er sort der giver problemer, da både awk og uniq køre rigtig godt. awk gør faktisk jobbet med at gennemtygge de 30mb på 450ms, og uniq er ikke meget langsommere. Jeg læste i sorts man-fil at man kan nedsætte antallet af bider programmet indlæser af gangen og sortere på, men det hjalp ikke. En søgning på nettet hjalp heller ikke, fordi alle artikler handler om at bruge programmet, ikke at debugge det Eller begrænse det, nok nærmere).

Er der nogen alternativer til sort? Eller kunne man "nøjes" med de 100 mest besøgte sider fx, men jeg vil helst have det hele med, da det giver det bedste overblik.

Hilsen Nicky

[NickyThomassen]

Det her er faktisk lidt pinligt, men jeg har lige kørt den samlede sorteringskommando uden problemer, og uden mellemliggende filer. Bare ikke på den stationære, men på den bærbare.

Begge maskiner køre med Debian 6 stable, så jeg tænkte ikke på at der kunne være problemer på den stationære før jeg kørte

Kode: Vælg alt

sort --version

og systemet gik ned...

Jeg har prøvet at geninstallerer core-pakken hvor sort er med, men uden held. Så det næste må blive at få sort til at virke, og så prøve at indarbejde en stream som forslået i et script, der samler alle kommandoer, filer osv.

Tak for hjælpen og forslagene

Hilsen Nicky

[lath]

Det her er faktisk lidt pinligt, men jeg har lige kørt den samlede sorteringskommando uden problemer, og uden mellemliggende filer. Bare ikke på den stationære, men på den bærbare.

Begge maskiner køre med Debian 6 stable, så jeg tænkte ikke på at der kunne være problemer på den stationære før jeg kørte

Kode: Vælg alt

sort --version

og systemet gik ned...

Jeg har prøvet at geninstallerer core-pakken hvor sort er med, men uden held. Så det næste må blive at få sort til at virke, og så prøve at indarbejde en stream som forslået i et script, der samler alle kommandoer, filer osv.

Tak for hjælpen og forslagene

Hilsen Nicky

sort --version og systemet går ned? godt gået af sort kommandoen - det burde faktisk ikke ske.
Det er godt nok ikke lige det man regner med.

apropos robotstyringen
Nej, man laver ikke robotstyringer der håndterer ting de ikke er programmeret til. Det nærmeste man kommer er at robotten stopper, og beder om hjælp af et menneske ved at afgive en alarm og/eller sende en besked til et overordnet styringssystem (produktionssystem).

/Lars

[lath]

logtools pakken er måske noget for dig+

clfmerge - merge common-log-format web logs in order without sorting (good for
when you have a gig of logs).

logprn - like "tail -f" but after a specified time period of inactivity will
run a program (such as lpr) and pipe the new data to it)

funnel - pipe one stream of data to several files or processes.

clfsplit - split CLF format web logs by client IP address.

clfdomainsplit - split CLF logs by server domain.

Der er også mergelog:

A small and fast C program which merges and sorts http log files in
'Common Log Format' from web servers behind round-robin DNS. It has
been designed to easily manage huge log files from highly stressed
servers.

og analog:

Analog er en hurtig logfilbehandler som opretter statistikrapporter over
udnyttelsesgrader for internetservere.

Features:
- Fast: can process millions of lines per minute;
- Scalable;
- Flexible: the default output is well suited for many needs but there
are many options and 32 alternative report styles;
- Internationalized output;
- HTML output (compliant with standards);
- Handles many log file formats;
- Uses a command-line interface or a web interface.

Jeg ved godt at du ikke arbejder på web logs men de er måske mere eller mindre brugbare alligevel

/Lars

[NickyThomassen]

Hvis det var pinligt at sort ikke virkede, og jeg ikke tænkte på at tjekke programmet, så ved jeg ikke hvad det her er. Jeg fandt nemlig årsagen til at sort ikke virkede, og der er kun én at give skylden: mig.

I formiddags startede jeg fejlsøgningen af sort med

Kode: Vælg alt

titanus@debie:~$ whereis sort
sort: /usr/bin/sort /usr/share/man/man1/sort.1.gz /usr/local/bin/sort

og lagde med det samme mærke til den sort i /usr/local/bin/, og kom i tanke om at jeg for nogle måneder siden lavede et sorteringsscript som ikke virkede. Scriptet blev ved med at ligge systemet ned, så jeg opgav det, og troede at jeg havde slettet det.

Det gjorde jeg idag, så nu virker

Kode: Vælg alt

#/bin/bash
set -e

clear
echo "Starter op;"

if [ -f /media/dc-do/bind_queries.log ];
then mv /media/dc-do/bind_queries.log /dev/shm/queries
else
echo "Fil ikke fundet i /media/dc-do/, afslutter."
exit 1
fi

echo "Fil findes, fortsætter;"

# A Series, covers IPs (top-15)

awk '{ print $5 }' < /dev/shm/queries > /dev/shm/tmpA1
sort < /dev/shm/tmpA1 > /dev/shm/tmpA2
uniq -cd -w 13 < /dev/shm/tmpA2 > /dev/shm/tmpA3
sort -rbfn < /dev/shm/tmpA3 > /dev/shm/tmpA4
echo "--- Viser kun top-15 ip-adresser ---" > /home/titanus/Desktop/værter
echo >> /home/titanus/Desktop/værter
head -n 15 < /dev/shm/tmpA4 >> /home/titanus/Desktop/værter
echo >> /home/titanus/Desktop/værter
rm /dev/shm/tmpA*

echo "A kørt;"

# B Series, covers pages (top-100)

awk '{ print $7 }' < /dev/shm/queries > /dev/shm/tmpB1
sort -r < /dev/shm/tmpB1 > /dev/shm/tmpB2
uniq -cd < /dev/shm/tmpB2 > /dev/shm/tmpB3
sort -rbfn < /dev/shm/tmpB3 > /dev/shm/tmpB4
echo "--- Viser kun top-100 URLs ---" >> /home/titanus/Desktop/værter
echo >> /home/titanus/Desktop/værter
head -n 100 < /dev/shm/tmpB4 >> /home/titanus/Desktop/værter
rm /dev/shm/queries
rm /dev/shm/tmpB*

echo "B kørt;"
echo "All done!"
exit 0

# EOF

helt uden problemer. En time på sciptet giver en køretid på 6 sekunder og 297 millisekunder og resultatet er

Kode: Vælg alt

--- Viser kun top-15 ip-adresser ---

 163624 192.168.20.42#32768:
...
--- Viser kun top-100 URLs ---

  21649 mail.google.com
...

Så selvom det var en fejl 20 (20 centimeter fra skærmen) vil jeg gerne sige tak for hjælpen til jer begge, tråden har givet en masse ny viden og inspiration til fremtidige projekter og scripts

Hilsen Nicky