Hi, ich hab seit vielleicht ein bis 2 Wochen das Problem, dass ein 
pacman -Syu
extrem lange braucht. Am längsten brauchts bei "Starte komplette Systemaktualisierung..." - da rattert meine Festplatte wie blöde und braucht etwa 20 Sekunden oder so bis er damit fertig ist.
Wie gesagt besteht das Problem noch nicht so lange und ich weis nicht recht warum. 
pacman-optimize
Brachte bisher auch nichts. Irgendwelche Ideen worans liegen könnte oder so?
Ist bei mir auch so. Ich rate mal ins Blaue, dass Pacman keine richtige Datenbankengine oder ähnliches hat und die ganzen Informationen beim erstenmal noch von der Platte kratzen muss. Als Nutzer kann man da, schätze ich mal, nichts machen.
Finde ich auch nicht sooo gravierend, denn wie oft macht man schon ein -Syu? Und Multitasking sei dank, kann man währenddessen auch was anders machen.

Bringt pacman-optimize noch überhaupt was? Ich konnte jedenfalls nie ein Geschwindigkeitsvorteil (subjektiv) bemerken.
Also son pacman -Syu mach ich täglich... *g*
Und pacman-optimize mach ich ab und an, aber so ganz was gebracht hats bisher noch cnith so glaub ich - irgendwann kurz nach der Installation von Arch hab ichs mal gemacht da hats was gebracht glaub ich, aber danach nicht mehr so.

  • [gelöscht]

  • Beitrag Nr. 4
Man müsste die Datenbank von pacman an ne MySQL-DB binden können, dass wäre dann schnell *g*.
Ich mache auch pacman -Syu täglich, pacman-optimize einmal im Jahr bzw. nie *g*.

Das dass "Starte komplette Systemaktualisierung..." ziemlich lange da steht, hängt auch häufig von den zu aktualisierenden Paketen ab, was ich beispielsweise oft mitbekommen habe. Je mehr es sind, desto länger.

  • [gelöscht]

  • Beitrag Nr. 5
  • Bearbeitet
same here...und braucht auch dann sehr lange, wenn gar keine Pakete zum aktualisieren gefunden werden.

  • [gelöscht]

  • Beitrag Nr. 6
Kodama schrieb same here...und braucht auch dann sehr lange, wenn gar keine Pakete zum aktualisieren gefunden werden.
Das ist schon sehr komisch. Bei mir zieht der da in 2s komplett durch. Vielleicht stimmt am Dateisystem etwas nicht. Welches nutzt du?

  • [gelöscht]

  • Beitrag Nr. 7
  • Bearbeitet
Lin2Core schrieb Das ist schon sehr komisch. Bei mir zieht der da in 2s komplett durch. Vielleicht stimmt am Dateisystem etwas nicht. Welches nutzt du?
ext4, und er rödelt nur beim "Starte komplette Systemaktualisierung..." so lange rum, auch wenn alles aktuell ist...
Ich kann das beschriebene Verhalten hier bestätigen. Mir scheint, als würde das Aufbauen der Paketlisten bzw. Download-URLs extrem lange dauern.
Im Einsatz: ext3 und 64 Bit.

Pacman auf aria2c (powerpill) oder den internen downloader umzustellen bringt keine Veränderung.

Lg,
Vrob
oje es wir hier rumgemeckert weil pacman nicht schon vorm enter druecken fertig ist. das pacman mit der zeit immer n bischen laenger brucht liegt wohl daran das man ab und zu neue sofware installiert und diese dann auch mitgelesen werden muss. die meissten kommen doch hier von ubuntu (debian) oder? dann vergleicht mal den speed im gegensatz du aptitude. bei euch sind 20-30sec "echt lange"? muss ich nicht verstehen.

ben

  • [gelöscht]

  • Beitrag Nr. 11
Xukashi schrieb oje es wir hier rumgemeckert weil pacman nicht schon vorm enter druecken fertig ist. das pacman mit der zeit immer n bischen laenger brucht liegt wohl daran das man ab und zu neue sofware installiert und diese dann auch mitgelesen werden muss. die meissten kommen doch hier von ubuntu (debian) oder? dann vergleicht mal den speed im gegensatz du aptitude. bei euch sind 20-30sec "echt lange"? muss ich nicht verstehen.

ben
aptitude braucht im Gegensatz zu pacman lange ... Es liegt u.a. an der Anzahl der installierten Software. Je weniger, desto schneller rödelt pacman. Den Effekt bemerkte ich bis gestern auf meinem großen PC (KDE 4.2.4) und meinem Notebook (XFCE4). Der Zeitunterschied bis zum vollständigen fertigen Update lag bei 4s. Für mich nicht lange, denn ich kann dank Multithreading parallel ja noch was anderes machen.

Erfahrungen mit ext4 konnte ich bisher noch nicht sammeln, weshalb ich diesbezgl. auch keine Aussagen machen kann. Ich bleibe bei ReiserFS und ext3 (/boot). Als ich XFS mal nutzte, hatte ich einen ähnlichen Effekt.
Xukashi schrieb oje es wir hier rumgemeckert weil pacman nicht schon vorm enter druecken fertig ist. das pacman mit der zeit immer n bischen laenger brucht liegt wohl daran das man ab und zu neue sofware installiert und diese dann auch mitgelesen werden muss. die meissten kommen doch hier von ubuntu (debian) oder? dann vergleicht mal den speed im gegensatz du aptitude. bei euch sind 20-30sec "echt lange"? muss ich nicht verstehen.
Es geht hier nicht um Jammern oder Meckern oder sonst irgendeine destruktive Art, den Pacman EntwicklerInnen ans sprichwörtliche Bein zu pinkeln.
Einigen UserInnen ist die seltsame Skalierung von Pacman bei vielen upzugradenden Pakete aufgefallen und das soll hier diskutiert werden, indem versucht wird, Gemeinsamkeiten zwischen den Systemen aufzuzeigen, sodass sich möglicherweise ein Aspekt als Verursacher herausstellt.

Damit soll nicht die Leistung der Devs geschmälert, sondern die Erfahrung aller Pacman-UserInnen verbessert werden und wenn jede kritische Diskussion zu einem Programm als "rummeckern" abgetan wird, dann können wir die Entwicklung ja auf Sicherheitspatches beschränken - es ist ja scheinbar alles wunderbar und rosa-rot genug, als dass mensch nichts mehr zu verbessern bräuchte.

Lg,
Vrob
Einigen UserInnen ist die seltsame Skalierung von Pacman bei vielen upzugradenden Pakete aufgefallen und das soll hier diskutiert werden, indem versucht wird, Gemeinsamkeiten zwischen den Systemen aufzuzeigen, sodass sich möglicherweise ein Aspekt als Verursacher herausstellt.
Wo ist es seltsam das ein Paketmanager laenger zum updaten baucht wenns mehr Pakete sind? Sollte doch eigentlich logisch sein oder?
...es ist ja scheinbar alles wunderbar und rosa-rot genug, als dass mensch nichts mehr zu verbessern bräuchte.
Wenns hier mal um ne Verbesserung gehen wuerde. Nein es wird hier rumgejammert und nicht mal selbst drueber nachgedacht warum "in diesem fall pacman" das verhalten zeigt. Es geht hier um n paar sec. die pacman laenger braucht aber es wird sich nicht die Frage gestellt was habe ich in der letzten Zeit alles so mit meinem System gemacht. Es geht hier "und damit meine ich nicht nur dieses Thema sonder um so einige hier im Forum" um Hype und Leet.
Xukashi schrieb Wo ist es seltsam das ein Paketmanager laenger zum updaten baucht wenns mehr Pakete sind? Sollte doch eigentlich logisch sein oder?
Na ja, in dem Zitat auf das du dich beziehst, wird das Wort "Skalierung" verwendet. Das Pacman länger braucht ist unter Umständen unvermeidlich. Aber das pacman skalieren muss, hilft nicht bei der Frage, ob er gut oder schlecht skaliert.
Xukashi schrieb Wenns hier mal um ne Verbesserung gehen wuerde. Nein es wird hier rumgejammert und nicht mal selbst drueber nachgedacht warum "in diesem fall pacman" das verhalten zeigt.
Entschuldigung, aber bis zu deiner Wortmeldung, ging es lediglich um eine Problem- und Ursachenerfassung.
nein es ging um "pacman braucht EXTREM lange zum updaten" naemlich 20sec und das ist rumjammern.
Das ist nur der Threadtitel. Ich finde deine Reaktion übertrieben.
Wenn dich das Diskussionsklima auf dem Forum stört, kannst du dazu einen eigenen Thread aufmachen. Ich jedenfalls finde das Thema hier ehrlich gesagt für zu interessant, um es durch sowas kaputt machen zu lassen.
durch Vrob wird die sache jetzt erst interessant. naemlich sich pacman mal richtig anzuschauen. der eigenliche thread spielt darauf ab das es mal wieder nicht schnell genug sein kann.
pacman -Su profitiert am meisten von einem schnellen FS auf der Partition, auf der /var/lib/pacman/local
liegt. Es müssen dort quasi alle Verzeichnisse(1 pro Paket) plus die desc/depends files) "angefasst"
werden. Ein FS, was gut "mit vielen kleinen Dateien kann" profitiert hier.
Weiterhin hängt es natürlich davon ab, wieviele Pakete (mit jeweils X Abhängigkeiten) updated
werden müssen.

Evtl. lohnt es sich auch mal pacman im Debug-Modus zu starten, um zu sehen ob es ggf. an einzelnen
Paketverzeichnissen in local hängt:
pacman --debug -Syu
(Diese Logfiles muß man aber nicht hier posten <g>)

Evtl. zum Testen/Vergleichen: 
pacman -Sy
pacman -Qu
(ergibt bei mir aktuell 10 Pakete)
time pacman -Su
(ich sage n)
real	0m1.174s
Na ja, in dem Zitat auf das du dich beziehst, wird das Wort "Skalierung" verwendet. Das Pacman länger braucht ist unter Umständen unvermeidlich. Aber das pacman skalieren muss, hilft nicht bei der Frage, ob er gut oder schlecht skaliert.
Danke, das ist nämlich genau der Punkt. Es ist nämlich die Frage, ob 10 Upzugradene Pakete eine Verzögerung von 1 Sekunde (sehr gut) oder 100 Sekunden (sehr schlecht) nach sich ziehen. Je nach dem wie clever Pacman geschrieben ist, kanneben das eine oder andere erreicht werden Ich gehe davon aus, dass die Menschen, die an Pacman arbeiten, sehr guten Code erzeugen und würde hier vielleicht eher auf einen Bug, Unachtsamkeit oder wie GerBra schon anriss, Nebeneffekte abzielen.

Mir ist weiterhin noch aufgefallen, dass das erste Update des Tages wesentlich (gefühlte 2-3x länger) braucht und die HDD stark belastet wird, während alle sukzessiven Updates quasi ungebremst durchlaufen - und das unabhängig wieviele Updates beim ersten pacman -Syu eingespielt werden müssten.
Auch caching-Mechanismen kann ich ausschließen, da ich den Rechner zwischendurch durchaus auch abgeschaltet habe.

Edit:
@GerBra, wenn ich den TE richtig verstanden habe, dann bezieht er sich auf den Abschnitt "Suche nach aktualisierbaren Paketen", der beim Aufruf von pacman -Qu durchgeführt wird, also müsste ein Zeitvergleich dort ansetzen (mir ist klar, dass bei -Su das auch ausgeführt wird, aber je weiter wir es eingrenzen können, desto besser).

Lg,
Vrob
Vrob schrieb @GerBra, wenn ich den TE richtig verstanden habe, dann bezieht er sich auf den Abschnitt "Suche nach aktualisierbaren Paketen", der beim Aufruf von pacman -Qu durchgeführt wird, also müsste ein Zeitvergleich dort ansetzen (mir ist klar, dass bei -Su das auch ausgeführt wird, aber je weiter wir es eingrenzen können, desto besser).
Da hast du recht...
Außerdem ist meine "Zeit" auch sicher eine "gecachte" Angabe... Zuverlässig wäre es wohl nur
nach einem Reboot...