Hallo, Am Tue, 03 Apr 2012, Christian Boltz schrieb:

Am Dienstag, 3. April 2012 schrieb David Haller:

...

Am Mon, 02 Apr 2012, Christian Boltz schrieb:

...

Ich weiß, dass Du bei unnötigen greps und rpm-Aufrufen allergisch reagierst ;-) - aber wenn man das Ergebnis an ein rpm -V verfüttert, dürfte der Performance-Unterschied nicht wirklich messbar sein *g*

Stimmt wohl, die meiste Zeit dürfte für's 'rpm -qa' (implizit in -Va) draufgehen, also die Abfrage aller Pakete. Der Rest ist dann weitgehend I/O. Das extra 'rpm -V' und 'grep' zu starten sollte nicht viel ausmachen.

# time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 0m2.673s # time rpm -V `rpm -qa |grep -i yast` real 0m2.810s

Entweder Du hast kaum YaST-Pakete installiert oder (was ich eher vermute) die obigen Zeiten sind mit vorgewärmtem Plattencache gemessen.

Mit Cache natürlich. Sonst müßte ich ja zwischendrin rebooten! Ok, zum Vergleich mal ne Laufzeit ohne Cache wäre evtl. sinnvoll, bzgl. "Relevanz" der Laufzeitunterschiede vs. Laufzeit ohne gefüllten Cache.

Sieht hier so aus:

# time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 1m39.836s # erster Durchlauf - Cache war vorher "leer"

# time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 0m3.811s # zweiter Durchlauf kurz danach - Cache hilft :-)

# time rpm -V `rpm -qa |grep -i yast` real 0m4.053s # nicht schlecht, aber...

# time rpm -Va '*[Yy][Aa][Ss][Tt]*' real 0m2.865s # ... speziell für diesen Befehl gecacht geht es noch schneller ;-) (wahrscheinlich lag vorher nur ein Teil der RPM- Datenbank im Cache)

...

Sowas ist nicht wirklich relevant.

Genau. Der wichtigste Unterschied ist, ob die RPM-Datenbank und die Dateien aller zu prüfenden Pakete schon im Cache liegen ;-) Zumindest bei letzteren ist es unwahrscheinlich - wer ruft schon zweimal hintereinander rpm -V fürs gleiche Paket auf?

/me wenn er das Ergebnis des ersten Laufs nicht nachvollziehen kann. Hast zufällig den nvidia-Treiber aus dem nvidia-Repo installiert? $ time rpm -Va '*nvidia*' 5S.T..... /usr/bin/X.x11-video-nvidiaG02 ...T..... /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so Ja, das ist ok so. Wird im postinstall-script gemacht. Aber bis man das nachvollzogen hat ... ;)

...

Der Unterschied dürften weitgehend die Startzeiten vom extra rpm und grep sein.

Ja - aber im Vergleich zu einem rpm -V bei leerem Plattencache sind diese Zeiten eher lächerlich.

ACK.

Wo ich eh schon am Testen bin, noch eine Variante: Übergabe aller Paketnamen direkt beim rpm-Aufruf. Damit haben wir den Teil "Auflistung der Pakete" ausgeklammert.

Das könnte scheitern ... allerdings scheint da jemand an der max. Länge der Argument-Liste gedreht zu haben, ich hatte zuletzt immer was von 131xxx in den config.log ... Im WindowMaker-Log find ich: checking the maximum length of command line arguments... 1572864 $ rpm -qa | wc -c 112051 ok, da ist dann doch (inzwischen) noch gut Luft ;)

Jeweils die Daten vom 2. Durchlauf (vorgewärmter Cache):

# time liste=$(rpm -qa '*[Yy][Aa][Ss][Tt]*') real 0m1.928s

# time liste=$(rpm -qa | grep -i yast) real 0m2.033s

Das zusätzliche grep kostet also 5% Performance. Weltuntergang! ;-)

# time rpm -V $liste real 0m1.100s

Wer will, kann diese Zahlen jetzt noch zusammenrechnen und mit den Werten von oben vergleichen ;-)

Aber doch ... Woast Bub, ich denk bei sowas immer willkürlich an den Worst-case. Nämlich das das nicht ein Gscheidle wie du macht, sondern daß das irgendeiner hier oder in irgendeinem Forum aufschnappt. Und dann das macht: for i in $(rpm -qa); do rpm -Va | grep -i $i; done Oder so. Ok, da ist das grep auch eher wurst. Hier mal ne Auswahl an Grausamkeiten bei einer einfachen Aufgabe: ,----[ dynip_testing.sh ] | #!/bin/bash | export LC_ALL=C | test -n "$1" || { | echo "Usage: [LOOPS=<iterations>] $0 INTERFACE [IP]"; | exit 1 | } | trap "echo "Aborted!" && exit 1" 2 | dh1() { sed -n 's/.*addr:\([0-9\.]*\).*/\1/p'; }; | dh2() { grep "inet addr:" | sed 's/.*addr:\([0-9\.]*\).*/\1/'; }; | dh3() { echo -n $(sed -n 's/.*addr:\([0-9\.]*\).*/\1/p'); } | dh4() { echo -n $( grep "inet addr:" | sed 's/.*addr:\([0-9\.]*\).*/\1/' ); } | dh5() { while read l; do m="${l%%*addr:[0-9.]*}"; if test "x$m" = "x"; then | a="${l//*addr:/}"; a="${a// */}"; echo "$a"; fi; done; } | dh6() { sed -n '/addr:/s/.*addr:\([0-9\.]*\).*/\1/p'; } | tj1() { grep "inet addr:" | awk '{print $2}' | cut -c 6- | perl -pe 'chomp;'; } | tj2() { grep "inet addr:" | awk '{print $2}' | cut -c 6- ; } | sd1() { perl -ne 'if (/inet addr:(\S+)/) { print $1 }'; } | ww1() { grep "inet addr:" | cut -f2 -d: | cut -f1 -d' '; } | mh1() { grep inet | awk '{print $2}' | awk -F: '{print $2}'; } | mt1() { grep 'inet addr:' | cut -f2 -d":" | awk '{ print $1 }'; } | dk1() { read; read -a A; echo ${A[1]#*:}; } | jt1() { awk '/inet addr:/{print substr($2, index($2,":") +1) }'; } | dh7() { awk -F'[: ]+' '/inet addr:/{print $4;}'; } | | echo "testing for IF: $1" | | IFCFG="$(/sbin/ifconfig "$1")" | if test -z "$2"; then | IP=$(echo $IFCFG | dh1) | fi | | # run some dummies first (using all external tools at least twice) | echo "caching tools ..." >&2 | for m in dh1 dh7 mt1 sd1 dk1 tj1; do { | time for i in $(seq ${LOOPS:=2}); do | test "x$(echo "$IFCFG" | $m )" = "x${IP}" || { | echo "ERROR" >/dev/stderr; break; | }; done } >/dev/null 2>&1 | done | | echo "running benchmark ..." >&2 | for m in dk1 dh5 dh1 dh6 dh3 dh2 dh4 ww1 mt1 mh1 tj2 sd1 tj1 jt1 dh7; | do | echo -ne "$m: " >&2 | { | time for i in $(seq ${LOOPS:=1000}) | do | test "x$(echo "$IFCFG" | $m )" = "x${IP}" || { | echo "ERROR" >/dev/stderr; break; | } | done | } 2>&1 | sed -n '/real/p' | done | exit 0 `---- Gedacht die dynamische IP eines ppp/dsl devices per ifconfig auszulesen. Achso, die 'dh*' sind bis auf dh1, dh5, dh6 und dh7 rein akademisch zum Vergleich mit drin. Die nicht 'dh*' sind alle als IIRC ersten Vorschläge hier in der ML geschrieben worden ... Besonders klasse übrigens das "perl -pe 'chomp;'", tut mir leid IIRC Thorsten (da hätt's ein xargs echo oder printf "%s" $( ... ) auch getan :) und das extra perl sieht man in der Laufzeit ... $ dynip_testing.sh eth1 testing for IF: eth1 caching tools ... running benchmark ... dk1: real 0m1.458s dh5: real 0m1.681s dh1: real 0m2.432s dh6: real 0m2.470s dh3: real 0m3.135s dh2: real 0m2.786s dh4: real 0m3.270s ww1: real 0m3.104s mt1: real 0m3.522s mh1: real 0m3.529s tj2: real 0m3.365s sd1: real 0m3.395s tj1: real 0m4.742s jt1: real 0m2.667s dh7: real 0m2.702s Im anderen Durchlauf war dk1 ähnlich, tj1 bei ~5.2s. Da war wohl perl evtl. noch nicht ganz fit ;) Und nein, daß die rein auf die bash-builtins setzenden dk1 und dh5 vorn liegen ist wenig überraschend. Und daß dann 'dh1' folgt ist zumindest für mich nicht überraschend. Das möge aber jede(r) selber austesten und nachvollziehen. Leider sind auf der neuen Kiste mit DDR3-1333 RAM und 3GHz Doppelkern bei warmem Cache die Startzeiten der Tools nimmer so deutlich wie auf der alten (mit SDRAM (133) und 500MHz Einzelkern). Da hatte ich schon bei 100 Loops krasse Unterschiede, IIRC um Größenordnungen (also z.B. 2s für dk1 und >20s für tj1 oder so in der Richtung). Bei "kaltem" FS-Cache schlägt die Größe der Programme speziell gegen die bash-builtins weiter voll zu, allerdings laufen die verwendeten Programme sowieso beim boot in diversen init-scripten. Mit systemd dürfte sich das aber ändern, was v.a. bei perl zuschlagen würde. bash läuft wohl eh und cut/grep/sed/awk dürften bzgl. Startzeit in etwa gleichauf sein. Achso, was ich schreiben wollte: wenn du die Tools kennst (und dabei helfen solche Threads), dann kannst du immer besser abschätzen, was effizient ist[2] und was nicht (und in einer Schleife über $viele Hosts z.B. "ewig" dauert). Um mal die wichtigsten 2 meiner Faustregeln zu nennen: - Prozesse starten ist lahm - x kann alles was auch y kann Liste (x<y): grep < sed < awk < perl[1] ed einzusortieren ist nicht ganz einfach (irgendwo sehr nah bei ed). Von (x)emacs (vim?) im batch-mode sowie python, lua etc. will ich hier nicht anfangen ;) Wenn man also irgendwo in ner Pipe ein 'sed' verwendet darf da eigentlich kein 'grep' mehr drin auftauchen (denn das kann sed selber, ist dabei aber teils arg lahm, da ist ein grep | sed ggfs. ok). awk kann noch mehr als sed und perl alles außer [1] was awk kann. Ich selber schreib mein längeren scripte inzwischen im Zweifelsfall in perl (und ein fertiges sub für's bequeme fehlerbehandelnde Aufrufen externer Programme hab ich auch ;) [1] mit einer Ausnahme: den "Record seperator", der darf bei awk auch ne Regex sein, bei perl nicht (und das nachzuarbeiten ist selten trivial, und braucht entweder mehr Speicher oder mehr Zeit). ==== man perlvar ==== HANDLE->input_record_separator( EXPR ) $INPUT_RECORD_SEPARATOR $RS $/ The input record separator, newline by default. [..] Remember: the value of $/ is a string, not a regex. awk has to be better for something. :-) ==== [2] bei perl "intern" gibt's da aber durchaus mal die ein oder andere Überraschung.

...

Nur: daß rpm auch selber Paketnamen "matchen" kann (vgl. rpm -qa '*kernel*') ist noch wenig bei den Anwendern angekommen.

Weiß ich ;-)

Du und ich und noch ein paar ... Was "man" daheim an der Konsole ist die eine Sache, was man in Scripte schreibet eine andere. Wenn man die Script aber publiziert oder Befehle in einer ML, NG oder nem Forum schreibt gelten andere Maßstäbe. Wenn du wüßtest, was ich hier im xterm schon an Mist getippert hab ... BTW: $ for f in ~/bin/*[^~]; do test -f "$f" || continue; file -- "$f"; done \ | awk '/shell/{s++;};/perl/{p++;}END{print s, p;}' 304 234 Ich glaub ich sollte mein ~/bin/ mal ausmisten. Da ist definitiv einiger "Schrott" dabei (aber viele Perlen, sach ich ma so ;)

...

...

PS: Ich such mal die passende sig raus ;-)

*hrhrhr* dito.

OK, das sig-Match ist eröffnet. Ich suche nochmal ;-)

BTW: deine is ein Fake. Das hat A. Schott an mich geschrieben. Und das auf einer anderen Liste ... .oO( gut daß ich auch (vermeintliche) Sigs meinerseits archiviere *hrhrhr* )

...

...

[1] / hat 8,5 GB used - wobei /tmp, /var und natürlich /home auf einer anderen (verschlüsselten) Partition liegen

Inkl. /var und /tmp lt. 'df -m': 27515M used.

27G? Da würde mich der Anteil von /var und /tmp doch interessieren. Ich hätte bei Dir ein schlankeres System vermutet ;-)

/tmp ist praktisch leer, in /var/ liegt ein großer Haufen logs # du -ms /var/cache/ /var/lib/ /var/log /var/tmp/ 6447 /var/cache/ 707 /var/lib/ 1319 /var/log 13 /var/tmp/ Äh, und der Rest dürfte dann /var/spool/news sein :P Da ich leafnode verwende (atime-basiertes "zu holen oder nicht") mach ich da mal kein 'du' drüber, will die Gruppen nicht wieder aus interesting.groups rauspopeln. Und ja, da liegen mind. 2 Gruppen mit nem dicken Archiv ;) Bei anderen könnte ich mal das expire anpassen oder sie gleich ganz rauswerfen, da ich da eh nix les. Aber so 2-3 Monate Archiv find ich schon angemessen ;)

...

PS: hab heute mal den 3.3 aus Kernel:stable getestet, der vermurkst einem offenbar das DVB, ich bekomm da nur noch Artefakte mit ein paar Bild- und Tonfetzen. mit 3.1.9 läufts

Ich glaube, ich muss Dir die Benutzung von Bugzilla nicht erklären, oder?

Nein. Bin aber noch nicht dazu gekommen. Hab heute auch nochmal den nvidia-Treiber auf die 290.10 Version aus dem nvidia-Repo runtergezogen, nur um das auszuschließen, hatte ein paar Artefakte, das dürfte aber an der HW gelegen haben. Oder dem Mesa-Update heute. *GNORF* Das mit dem Kernel 3.3 war aber vor o.g. nur bis ich nen nvidia-Treiber unter 3.3 am Laufen hatte (naja, der Patch ist zum Glück einfach, ich kipp den hier einfach schonmal ab, der gilt AFAIK schon seit dem 270er Treiber, spätestens seit dem 290er, nur hat man vom RPM halt nicht das .spec + Patches): ==== diff -x '*~' -x '*.o' -urN NVIDIA-Linux-x86_64-295.33/kernel/conftest.sh NVIDIA-Linux-x86_64-295.33.dh/kernel/conftest.sh --- NVIDIA-Linux-x86_64-295.33/kernel/conftest.sh 2012-03-17 22:55:27.000000000 +0100 +++ NVIDIA-Linux-x86_64-295.33.dh/kernel/conftest.sh 2012-04-02 10:57:07.000000000 +0200 @@ -127,6 +127,7 @@ if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include -I$SOURCES/arch/x86/include/generated" + CFLAGS="$CFLAGS -I$OUTPUT/arch/x86/include -I$OUTPUT/arch/x86/include/generated" elif [ "$ARCH" = "ARMv7" ]; then CFLAGS="$CFLAGS -I$SOURCES/arch/arm/include -I$SOURCES/arch/arm/include/generated" fi ==== Die Folgefehler aus den fehlenden Includes sind teilweise extrem irreführend (und mit make -j > 1 hat man verloren ;) Achso, ja, der Patch sollte auch für kleinere Versionen passen, 290.10, und auch 270er. Evtl. noch älter. Verd....e Ka... hab ich da lange rumprobiert mit dem Krams bis ich auf obiges im conftest.sh gekommen bin. Kernel 'make *prepare', Argumente für den installer und und und und und. Hab mich schon beim überletzten Kernelupdate mit rumgeschlagen, und irgendwann aufgegeben und das 290er RPM installiert (was erfreulicherweise funktionierte). Den 295er mit 3.1.9er Kernel (der 12.1) hab ich noch nicht getestet. Das mach ich wohl als erstes. Und dann mal gucken ob der 290er mit dem Patch auch auf dem 3.3 läuft. Ist eben sehr zeitaufwendig, zumal wenn wie die Tage noch ein Mesa Update mal wieder an libGL.so* rummacht.

...

(und ich dachte schon fast, meine TV-Karte verreckt schon wieder).

Ging mir bei meinem internen Cardreader mit dem Kernel der 12.1 ähnlich - nur dass der mit dem 3.3er Kernel wieder geht.

Na denn :) -dnh, der den 3.3 wg. dem wohl verbesserten I/O Verhalten auf z.B. USB Krams mal testen will -- *pieps* Die Verkehrshinweise: Im Netzwerkkabel von Marc 100 MB Stau wegen einer Vollsperrung der Ausfahrt Festplatte. Bitte warten Sie auf dem Rasthof FTP-Server. *pieps* -- C. Boltz -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org