aMule Forum
Deutsch => aMule Hilfe => Topic started by: qwertz2wal on May 23, 2005, 04:30:59 PM
-
Hi,
kann mir jemand sagen wie ich möglichst schmerzfrei von amuled/amuleweb von 2.0.0 auf 2.0.1 upgraden kann? Geht's mit make uninstall, um die 2.0.0-Version loszuwerden und dann mit make install (natürlich nach ./configure und make) die 2.0.1, um die neu drauf zu bekommen?
-
yo, oder du löscht einfach die binary aus /usr/bin oder /usr/local/bin wo auch immer die bei dir sind...
die language dateien werden sowieso geupadtet beim nächsten make install
-
Werden die angefangenen Downloads übernommen, führt amule 2.0.1 nach dem Upgrade die Downloads fort?
BTW: Wo finde ich das Password, das amuleweb beim Start abfragt und wo das PW, das ich beim Anmelden im Browser eingeben muß? Um amuleweb im Hintergrund laufen lassen zu können, muß ich das 1. PW wohl löschen? Das 2. PW kann dann den Zugang regeln.
-
die downloads werden forgesetzt ja, da alle einstellungen in dem user seinem homeverzeichniss liegen unter
.aMule
also deine einstellungen, credits usw gehen nicht verloren.
zum webserver
http://www.amule.org/wiki/index.php/Webserver#Webserver_with_aMule_2.0.0_or_later
in der gui kannst du unter fernsteuerung eigentlich alle optionen setzen, du musst nur ALLE pw setzen, das regelt der amuleweb dann schon ganz allein ;) aber wenn du welche nicht setzt wird er gar nicht erst gestattet, das einzige was du nicht brauchst is der mit dem "beschränkten zugriff"
dann wichtig, tcp-socket enablen, und externe verbindungen aktivieren....das is alles
stefanero
-
Der schmerzfreieste Weg ist amule mit demselben Prefix zu kompilieren und ihn dann einfach drüberzuinstallieren. Läuft bei mir schon seit >100 Installationen ohne Probleme ;)
-
Update hat geklappt.
Aber:
Es laufen 23 Prozesse amuled und die Auslastung des Systems ist 100%. Ich dachte, das wäre das Problem, das mit 2.0.1 behoben wäre?
Mein Server ist übrigens ein 133MHz System (nein, ich habe keine Null vergessen!). Die alte Möhre geniesst als Amule-Server sein Gnadenbrot.
-
hast du andere compileroptionen oder so verwendet?
-
Nur mal so damit wir von gleichen Voraussetzungen ausgehen:
Hattest du früher schonmal amuled auf diesem Rechner laufen? Wenn ja: Welche Systemlast hat es verursacht? Und wieviele Downloads hast du momentan am laufen?
Was configure-Optionen angeht empfehle ich dir für den Rechner auf jeden Fall --disable-debug und --enable-optimize ;)
-
zu dem ob es vorher lief --> ließ mal den thread :P
-
Originally posted by qwertz2wal
Hi,
kann mir jemand sagen wie ich möglichst schmerzfrei von amuled/amuleweb von 2.0.0 auf 2.0.1 upgraden kann?
und
Aber:
Es laufen 23 Prozesse amuled und die Auslastung des Systems ist 100%. Ich dachte, das wäre das Problem, das mit 2.0.1 behoben wäre?
sagt mir beides nur daß er 2.0.0 schonmal draufhatte und wohl damit auch Probleme mit 100% Systemlast hatte. Von früheren Versionen / Betrieb unterhalb der 100% lese ich hier nichts ;)
P.S.:
Ja, ich weiß, Korinthenkacker :þ
-
ziemlich....
-
Hallo Leute,
1.) habe vorher schon 2.0.0 laufen gehabt. Dort hatte ich auch 100% Auslastung (sah ich mit top)
2.) 2.0.1 habe ich genauso konfiguriert und kompiliert wie 2.0.0
3.) derzeit habe ich 7 Downloads laufen, also nicht wirklich viel, denke ich.
Übrigens, auch wenn die Download-Geschwindigkeit 0 ist, ist der Rechner mit 100% ausgelastet. Mein erster Gedanke war, das ich noch 2.0.0 laufen habe, is aber nicht so, bei Einstellungen sagt er mir 2.0.1
-
noch 'ne Ergänzung:
ich hatte 7 Downloads laufen, diese hatten eine Download-Geschindigkeit von 0 kB/s bei einer Systemlast von 100%.
Habe alle amule-Prozesse abgeschossen und amule neu gestartet. Danach habe ich jetzt 2 amule-Prozesse mit einer Downloadgeschindigkeit von 10 kB/s und 60% Systemlast.
Kann es sein, das amule immer mehr Prozesse startet und nicht richtig beendet? So daß sich nach einiger Zeit diese vielen Prozesse nur noch gegenseitig auf den Füssen stehen ohnen etwas zu schaffen?
-
also der daemon code an und für sich ist noch nicht ganz ausgereift...zumindest was den netzwerkteil angeht
der wird gerade wieder etwas überarbeitet, mehr dazu im development forum fals es dich interessiert
zu der cpu auslastung:
bei einem 133mhz kiste wundert es mich nicht das deine cpu auslastung im allgemeinen so hoch ist, sei es 60% oder sei es 100%, es ist zwar ein daemon aber dennoch musst der ne ganze menge machen mit sources suchen, dateien hashen usw...
das eine so uralt kiste da mal schnell überfordet ist, wundert mich net wirklich....
-
Hi,
na macht ja auch nichts wenn das alte Stück noch mal richtig ackern muß. Und da er immer läuft hat er ja auch Zeit. Nur die vielen Prozesse (über 20) wundern mich. Da ist natürlich mit den vielen Context-switches 'ne Menge Overhead.
Grüße
-
hallo an alle :)
ich darf mir hier einfach mal einklinken? habe nämlich ein sehr ähnliches problem wie qwertz2wal...
auf meinem server (duron 1200mhz / 768mb ram) läuft erst seit ca. 3-4 wochen debian (bin ein glücklicher windows-umsteiger). angefangen hab ich mit dem rc8 von amule-2.0, wo der webserver nicht stabil lief (ist AFAIK ein bekanntes problem gewesen). nach dem release der final 2.0.0 hab ich - natürlich - upgedated (bzw. den rc komplett runtergeschmissen und die neue version compiliert (--disable-debug --enable-optimise --enable-webserver --enable-amulecmd --enable-amuled --disable-monolithic....ich glaube, mehr war's ned))
stabilität war gegeben, nur eben auch die volle systemauslastung. wobei bei mir auch bei 100% cpu-last ich noch eine d/l-rate von 40-60k habe. freudig nahm ich dann zur kenntnis, dass dieser bug mit v2.0.1 behoben sein sollte, doch ein update hat leider auch bei mir nicht den gewünschten erfolg gebracht.
direkt nach dem start sieht ein ps -el | grep amule so aus:
kahfau@kahfau2:~$ ps -el | grep amule
0 S 1000 825 824 8 75 0 - 7529 nanosl pts/18 00:00:02 amuled
1 S 1000 827 825 0 69 0 - 7529 poll pts/18 00:00:00 amuled
1 S 1000 828 827 0 69 0 - 7529 select pts/18 00:00:00 amuled
1 S 1000 829 827 0 69 0 - 7529 nanosl pts/18 00:00:00 amuled
1 S 1000 830 827 0 69 0 - 7529 nanosl pts/18 00:00:00 amuled
1 S 1000 831 827 0 69 0 - 7529 select pts/18 00:00:00 amuled
0 S 1000 833 825 0 69 0 - 1834 pause pts/18 00:00:00 amuleweb
1 S 1000 834 827 0 69 0 - 7529 select pts/18 00:00:00 amuled
1 S 1000 835 833 0 69 0 - 1834 poll pts/18 00:00:00 amuleweb
1 S 1000 836 835 0 69 0 - 1834 select pts/18 00:00:00 amuleweb
1 S 1000 845 827 0 69 0 - 7529 select pts/18 00:00:00 amuledmeistens dauert es dann zwischen 6 und 10 stunden, bis die cpu nicht mehr klar kommt und auch deutlich mehr amuled-prozesse laufen. (kann ich später am tage hier ganz genau posten, da ich die mule erst eben gestartet habe)
vielleicht fällt den entwicklichern unter euch etwas dazu ein?
gruß
-kahfau
-
problem an der sache ist das lfroen, der einzige is der wirklich an dem daemon arbeitet, er hat ihn quasie geschaffen und entwickelt ihn nun ständig weiter
also wenn ihr wirklich qualifizierte antworten wollt warum das so viel cpu frießt, am besten auf eng posten ;)
zu den einzellen threads nur soviel:
die wxBase netzwerkimplementierung is an einigen stellen etwas buggy(wird grade von lfroen überarbeitet)
doch diese im moment noch fehlerhafte implementierung, öfnet für jede source einen einzellnen thread, diese poll und select wie man in der tabelle sieht, sind quasie alles quellen wo verwaltet werden.
amuleweb wie man sihet is auch eine "quelle" da beide ja über den externen port kommunizieren.
durch diese noch beschränke implementierung von kommunication in wxBase, ist die cpu last so hoch.
wie gesagt lfroen arbeitet daran, und schreibt grad den netzwerk-teil vom amuled um, kann aber wie immer alles ein wenig dauern ;)
ein weiterer fehler is zb auch das upload sehr unstabil ist oder nicht immer volle teile hochgeladen werden.
wer mehr dazu wissen will, kann gerne im development forum den thread lesen
gruss
stefanero
-
vielen dank für die schnelle antwort.
dass die weiterentwicklung des daemons noch ein wenig dauern kann, ist schon ok. schließlich ist das sicher ein freizeit-projekt und ich _muss_ ja auch nciht dafür bezahlen. also hab ich geduld.
zum cpu-problem: heißt das - einfach ausgedrückt - je weniger quellen ich habe (oder per MaxConnections definiere), desto weniger cpu-last hab ich?
-kahfau
-
in gewisser weise ja...
wollen wir einfach mal hoffen das lfroen die sache schnell fertig bekommt ;)
-
hum schneller als gedacht :)
versucht mal morgen das cvs und schaut ob es besser is...viel spass ;)
-
vielen dank für den hinweis. hab also mein "original" amule-2.0.1 de-installiert (make uninstall) und den cvs-tarball compiliert ... bin jetzt schon ganz gespannt, ob es damit gut funktioniert...
gruß
-kahfau
/edit
hat leider noch nicht gut funktioniert, siehe backtrace forum (http://forum.amule.org/thread.php?threadid=6347&sid=)
-
nachtrag: unterdessen hab ich seit einigen tagen aMule-CVS-20050530.tar.bz2 zu laufen, sowohl als daemon auf'm server als auch fuer die remote gui auf meinem arbeits-pc, und bin sehr zufrieden...
kahfau@kahfau2:~$ ps -el | grep amule
0 R 1000 7450 7449 4 79 0 - 9157 - pts/37 01:20:38 amuled
1 S 1000 7452 7450 0 68 0 - 9157 poll pts/37 00:00:00 amuled
1 S 1000 7453 7452 0 69 0 - 9157 nanosl pts/37 00:00:00 amuled
0 S 1000 7455 7450 0 69 0 - 2404 pause pts/37 00:00:00 amuleweb
1 S 1000 7456 7452 0 69 0 - 9157 nanosl pts/37 00:00:00 amuled
1 S 1000 7457 7455 0 68 0 - 2404 poll pts/37 00:00:00 amuleweb
1 S 1000 7458 7457 0 69 0 - 2404 select pts/37 00:00:00 amuleweb...und keine 100%ige cpu-last nach 10 oder 20 stunden. vielen dank fuer eine ressourcenschonende *mule-version.
zur remote gui: ich weiss, dass die gui noch im entwicklungsstadium ist. trotzdem eine frage: ist es korrekt, das aenderungen zb am dateinamen nicht uebernommen werden, ebenso die einstellungen fuer upload etc? (oder hab ich mal wieder nur ein rechte-problem :) )
-kahfau
-
nope, ausser anzeigen ghet grad wirklich noch nicht viel in der remote-gui, sorry
aber in amuleweb kannst die bandbreite schon ändern
-
vielen dank fuer die schnelle antwort.
das "sorry" hab ich jetzt mal ueberlesen. bei mir muss sich keiner fuer noch nicht implementierte features in komplett freier software entschuldigen... :))
-kahfau
-
schade das net jeder so denkt.... :)
viel spass