Themabewertung:
  • 1 Bewertung(en) - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
OpenSim Bugfix Belastungstestpartys
#21
(09.03.2012, 03:15)Bogus Curry schrieb: Was mir aber noch aufgefallen ist, das nur sehr wenige über HG gekommen sind. Ok die meisten haben wohl eh ein Zuhause im OSGrid. Aber trotzdem, das was man Aurora-Sim angelastet wird, das es nicht hg fähig ist, scheint bei denen im OSGrid egal zu sein. Finde ich irgendwie sehr widersprüchlich, erst recht weil die jetzige HG unterirsich in meinen Augen imme rnoch ist. Kein Profile, kein richtiges IM Versand möglich, von den FL will ich gar nicht erst reden.

Was UBit angeht, ist meine Vermutung, das es daran liegt das er auch viel mit den von Aurora-Sim entwicklern zusammenarbeitet oder hat. Vielleicht nehmen sie das ihm übel, anderseits kann es auch ganz was anderes sein.

Ich habe ja auch mehr oder weniger deutlich gebeten nicht mit HG zu kommen. Glaube an der Party waren etwa 2 Leute mit HG und das sind schon sehr viele! Der Link auf diesen Artikel http://www.mono-project.com/Article:Thre..._Deadlocks ist der erfolgsversprechendste Hineweis, den ich bisher gekriegt habe ... Ich war erstaunt ueber die hohe Anzahl die da im Artikel beschrieben ist. Bis Anhin hatte ich die Einstellung: MONO_THREADS_PER_CPU=150 ... offensichtlich nicht genug. Wuerde auch passen... bin jetzt mal fett reingegangen und habe es auf 1000 gesetzt :-) Handles sind auch genug konfiguriert.

Ubit: Entwickler sind Divas (oder ist Diven die Mehrzahl von Diva?) und sind dann schnell mal betupft. Ich weiss auch nicht was sich da abgespielt hat das Rev sich abgeforkt und Aurora gegruendet hat. Soap Operas sind etwas das laeuft im Abendprogramm des TV gugg ich mir meist nicht an. Egal. Die Threadpool Geschichte ist sicherlich im Moment der vielversprechendere Pfad. Der Anim Patch vom Ubit ist sicherlich weiterhin interessant, insbesondere aus User Experience gesichtspunkten. Ist auch doof wenn die Haelfte der Partyteilnehmer die Avis wie Salzsaeulen rumstehen sieht.



Zitieren
#22
Wie sieht es jetzt Heute aus? HG Gäste freigegeben? Du sagtest ja, nach dem Mittwoch bist du entspannter was die Anreise angeht...

HG ist was IM, Profil und FL angeht immer noch nachbesserungsbedürftig aber die TPs gehen wesentlich besser als im letzten Jahr und man kommt auch meist inkl. Prims an. Hat sich schon was getan finde ich.

Mmhh... Wenn ich das mit den CPU Threads so lese... Also liegt es eher am Mono und mit höher eingestellten Threads gehts besser, oder wie ist das zu interpretieren?
DeReOS Grid - http://dereos.org
Zitieren
#23
(09.03.2012, 11:16)LyAvain schrieb: Wie sieht es jetzt Heute aus? HG Gäste freigegeben? Du sagtest ja, nach dem Mittwoch bist du entspannter was die Anreise angeht...

Wie das leben so spielt ... da will man neue settings austesten ... und als die party so schoen am austarten ist ... bumm sim knallt... das teil startet wieder ... null ahnung wieso es gecrasht ist... Vivi hatte ein problem mit dem inventory und wir waren gerade etwas am testen als es knallte...

okie schnell die anpassung der mono threads rausgenommen man denkt ja sofort, das sei die ursache fuer den crash, weil es das einzige ist, das seit mittwoch geaendert hat... nach dem der sim gestartet ist, kommen von allen Seiten IM: "Hey Aki, der grid spinnt, ich kann nix rezzen. Die Leute welche an der Party erscheinen sind nun ploetzlich alle Glatzkoepfig und auf dem Log seh ich, dass diverse inventory sachen einfach nicht gefunden werden". Schnell ins IRC rein. Andere haben das Problem ebenfalls. Nebadon bringt dann Licht ins Dunkel. Er hat eine Datenbank faelschlicherweise gedroppt und muss sie nun ab dem Backup neu erstellen. Das war so geggen 21:40 Uhr.

OSgrid geht offline. Das heisst niemand kann sich nun mehr einloggen oder herspringen mit Hypergrid. Wir feiern weiter, einfach schoen schauen dass der Viewer nicht crasht. Fazit, wir hatten die geilste Offline Party die es je gegeben hat. Den Abend auswerten ist sinnlos. Doro meinte nur, das koennte Neb immer machen, wenn so 20 Leute da sind, einfach den Grid offline schalten, denn so stabil war die Party schon lange nicht mehr. Kein Lag und gar nix, halt auch keine Prim Attachements wie Haare und so Zeugs.

Druecke Neb den Daumen, dass er die Datenbank wieder hinkriegt !!!
Und ich bin heute abend genau so schlau wie vor dem Abend ...

Wuensche allen ein schoenes Wochenende und hoffe dass ihr grid wenigstens online ist... ich schau mich mal im RL Grid um ... soll auch spannend sein hab ich mir sagen lassen.






(09.03.2012, 11:16)LyAvain schrieb: Mmhh... Wenn ich das mit den CPU Threads so lese... Also liegt es eher am Mono und mit höher eingestellten Threads gehts besser, oder wie ist das zu interpretieren?

Hmm ich versuche es mal zu erklaeren. Hier geht es um IOCP Threads ist eine Microsoft Geschichte die sie im Windows eingebaut haben. Ist zur Beschaffung von Sachen wie Images und aehnliches gar nicht so dumm. IOCP heiss IO Completion Port.
Dies funktioniert etwa so. Nehmen wir mal eine Synchrone Verarbeitung:

Frau braucht Schuhe, ich rufe beim Versandhandel an und bestelle ein Paar Schuhe, die Verkaeuferin am Ende der Leitung sagt: "Bestellung wird gleich geliefert warten sie bitte am Telefon und geben Sie mir Rueckmeldung wenn die Lieferung da ist". Einen Tag spaeter klingelt es und die Schuhe werden geliefert, ich melde der Verkaeuferin, dass die Lieferung erfolgt ist und die Transaktion ist abgeschlossen. Nun kann ich dasselbe fuer die Jeans machen, die ich ebenfalls brauche.

Mit IOCP funktioniert es asynchron. Ich ruf beim Versandhandel an und bestell ein paar Schuhe. Sage der Verkaeuferin, unten vor der Haustuer steht die IOCP Zaki Test1 und wartet auf die Lieferung, geben sie bitte die Schuhe ihr ab. Damit ist die Bestellung abgeschlossen und ich kann gleich die Jeans bestellen, sage in dem Falle: "Bitte geben Sie die Lieferung an IOCP Zaki Test2 ab sie wartet unten am Eingang auf die Lieferung" usw.

Bei dutzenden von Texturen koennen da schon einige IOCP Threads auf Sachen warten und wenn halt zu wenige Threads vorhanden sind und die zusaetzlich noch lange auf die Bestellung warten muessen, muss ich halt mit der naechsten Bestellung warten, bis wieder ein neuer Thread gebildet werden kann, der etwas empfangen kann. Das heisst, zu wenig Threads im Pool, die Wartezeiten steigen bis zum Timeout.

So viel zur Theorie wie ich sie verstanden habe. IOCP ist wie gesagt ein Windows Ding, aber unter Linux gibt es was aehnliches oder die Mono Entwickler haben das einfach nachgebaut.

Was ich bis jetzt noch nicht weiss, ob ich wirklich zu wenige Threads konfiguriert habe, jedes mal wenn ich die Thread statistik anschaue, dann sehe ich die Zahl 0. Die hoechste Zahl die ich gesehen habe, vor dem Crash war 5, also weit weg von irgend einem Engpass. Was mir aber bei der Statistik nicht klar ist, was wuerde ich sehen. Was heisst die Zahl 5 sind das Threads die auf Bestellungen warten also aktiv sind, sind das Threads die alloziert wurden aber nix machen ausser da zu sein um auf Arbeit zu warten usw. Da muss ich noch genauer schauen.

Was ich aber gehoert habe ist, dass mono per default sehr wenige dieser Threads anlegt, deshalb ist das im Sim hart codiert uebersteuert, so dass folgende Zahlen ausgegeben werden: worker 5 (500), port 0 (1000). Was heisst dies jetzt? Hab ich maximal 1500 Threads die ich auf 8 CPU verteilen kann? Das waere dann MONO_TREADS_PER_CPU=200, dann hab ich 1600 Threads konfiguriert. Mit 300 wuerd ich noch ein paar Threads mehr konfiguriert haben hmm scripts benoetigen ja auch Threads insbesondere wenn man das letzte chatlog der Entwicklerversammlung vom Dienstag anschaut, gibt es in dieser Ecke auch noch ein paar Problemchen. Wo ist dann dieser Thread Pool, und wie sehe ich dessen Auslastung. Ein guter Profiler waere halt schon hilfreich. Klar, gibt es die unter Windows, ist aber ein komplett anderes System als mono mit komplett anderen Charakteristiken und wahrscheinlich lassen sich da die Rueckschluesse nicht 1:1 auf mono uebertragen.

Mal guggen und sich etwas schlauer machen ....

Zitieren
#24
Danke für deine anschaulichen Erläuterungen AkiraSmile
Ich wünsche euch von ganzen Herzen,das ihr eure Probleme in denGriff bekommt.

Lieben Gruß
DorenaSmile
Zitieren
#25
Müssten eventuell mal auch in andere Grids gucken, also diesen Test auch woanders als nur im OSgrid zu machen. So kann man eventuell gleich vornerein besser ausschließen das es am OSgrid selbst liegt.
Zitieren
#26
Du machst echt ne super Arbeit Akira ;D Schön das es so Leute noch gibt die noch Geduld aufbringen und das ganze noch erklären und nach Fehler durchschaun. Das mit dem Threads ... hmmm .. keine Ahnung ob es damit zusammehängt aber Aurora-Sim hat glaube ein ähnliches Problem. Vor Monaten, wo ich noch richtig die Dist testen konnte, ist mir aufgefallen, das wenn ich von einer Region zu anderen gehen eine verzögere um die 1000 ms gab. Http base request oder so heisst das. Nun hab sie das schon auf die hälfte reduziert, aber man merkt die Verzögerung durch ein kleines rucken beim AVa. Wenn man bedenkt wie das in SL ist und da segelt, dann kriegt man genau diesen ruck aber noch ein wenig stärker erst recht wenn die Scripts nachladen müssen.

Ich denke eines der Hauptprobleme überhaupt in SL und auch OS, sind die Texturen. Manch einer der Builder achten nicht drauf und benutzen sehr grosse Texturen, die in der Dateigrösse ein MB oder noch grösser sind, nur um damit die TExturen nicht zu pixelig sind. Wenn die richtig bearbeitet würden, könnte man sehr gute Texturen herstellen, die sehr gut aussehen und halt auch in der Dateigrösse nicht so gross sind. Und halt die Scripts, wenn die nicht sauber gecodet werden, dann kommt da Sand ins Getriebe. Ist wie bei einer Webseite. Es gibt schon einen Unterschied, wenn man mit Frontpage eine Webseite erstellt oder halt zu fuss bzw. ein CMS nimmt, was sauberen code erstellt bei dynamischen Seiten.

Hmmm .. bin gestern einmal rausgeflogen, weiss nicht mehr wie spät das war, dann muss es da gewesen sein bevor der Crash war. Hab nebenbei noch gesurft und auch TV geschaut ;D War trotz allem ne schöne Party ;D
Signatur
Have a nice Day ;D

>> BogusMusikRausch jeweils Donnerstag um 20 Uhr in Uwes KeulenBar

Tschöö

Bogus | PinguinsReisen.de | M: @gse@norden.social
Zitieren
#27
Als Nachtrag noch ein kleines Video von gestern abend
http://www.myvideo.de/watch/8469363
Zitieren
#28
Hm,..hier mal was interessantes im Metro-Forum:
Zak schrieb dort:
Zitat:Hallo Lena

auf den ersten Blick sah die Version wirklich gut aus zumindest auf der Simulator Seite. Jetzt scheint es so, als würde der Asset Server von Tag zu Tag langsamer. Die Übertragungsrate ist zwar schnell, aber es gibt eine Menge Paketverlust teilweise bis 30%. Auch auf den eingehängten 0.7.2 Regionen. Irgendwas sammelt sich da an und bremst aus. Vllt. ist es doch besser wieder auf den 0.7.2 Robust zurück zu gehen? Meine 0.7.3 Region hatte ich schon eine ganze Weile laufen die vertragen sich mit 0.7.2 Backend und die Ladezeiten waren auch wesentlich schneller.

Viele Grüße
Zak

Link zum Thread:
http://metropolis.hypergrid.org/forum/vi...f=4&t=1299
Zitieren
#29
Wenn ich das so lese, hab ich ja echt nen Abenteuer verpasst... Also heisst es auf die nächste Woche warten... Dodgy
DeReOS Grid - http://dereos.org
Zitieren
#30
(11.03.2012, 16:47)LyAvain schrieb: Wenn ich das so lese, hab ich ja echt nen Abenteuer verpasst... Also heisst es auf die nächste Woche warten... Dodgy

Hihi hoffe dass es naechste woche nicht wieder dasselbe Abenteuer gibt :-). Ein anderes ok ...


(10.03.2012, 14:41)Bogus Curry schrieb: Du machst echt ne super Arbeit Akira ;D Schön das es so Leute noch gibt die noch Geduld aufbringen und das ganze noch erklären und nach Fehler durchschaun. Das mit dem Threads ... hmmm .. keine Ahnung ob es damit zusammehängt aber Aurora-Sim hat glaube ein ähnliches Problem. Vor Monaten, wo ich noch richtig die Dist testen konnte, ist mir aufgefallen, das wenn ich von einer Region zu anderen gehen eine verzögere um die 1000 ms gab. Http base request oder so heisst das. Nun hab sie das schon auf die hälfte reduziert, aber man merkt die Verzögerung durch ein kleines rucken beim AVa. Wenn man bedenkt wie das in SL ist und da segelt, dann kriegt man genau diesen ruck aber noch ein wenig stärker erst recht wenn die Scripts nachladen müssen.

Ich denke eines der Hauptprobleme überhaupt in SL und auch OS, sind die Texturen. Manch einer der Builder achten nicht drauf und benutzen sehr grosse Texturen, die in der Dateigrösse ein MB oder noch grösser sind, nur um damit die TExturen nicht zu pixelig sind. Wenn die richtig bearbeitet würden, könnte man sehr gute Texturen herstellen, die sehr gut aussehen und halt auch in der Dateigrösse nicht so gross sind. Und halt die Scripts, wenn die nicht sauber gecodet werden, dann kommt da Sand ins Getriebe. Ist wie bei einer Webseite. Es gibt schon einen Unterschied, wenn man mit Frontpage eine Webseite erstellt oder halt zu fuss bzw. ein CMS nimmt, was sauberen code erstellt bei dynamischen Seiten.

Justin hat eine Antowort geschrieben. Die ganze Sache nicht allzu heiss essen. Es gibt da diverese Thread Pools. Er versucht die Situation zu verbessern. Immerhin was.

(10.03.2012, 18:19)Dorena Verne schrieb: Hm,..hier mal was interessantes im Metro-Forum:
Zak schrieb dort:
Zitat:Hallo Lena

auf den ersten Blick sah die Version wirklich gut aus zumindest auf der Simulator Seite. Jetzt scheint es so, als würde der Asset Server von Tag zu Tag langsamer. Die Übertragungsrate ist zwar schnell, aber es gibt eine Menge Paketverlust teilweise bis 30%. Auch auf den eingehängten 0.7.2 Regionen. Irgendwas sammelt sich da an und bremst aus. Vllt. ist es doch besser wieder auf den 0.7.2 Robust zurück zu gehen? Meine 0.7.3 Region hatte ich schon eine ganze Weile laufen die vertragen sich mit 0.7.2 Backend und die Ladezeiten waren auch wesentlich schneller.

Viele Grüße
Zak

Link zum Thread:
http://metropolis.hypergrid.org/forum/vi...f=4&t=1299

Oha, die benutzen den Robust Asset Server... Weiss nicht ob im OSgrid auch dieser verwendet wird, sollten sie eigentlich ( eat your own dog food ). Viele Paketverluste ist auch irgendwie ein deja-vu, glaub ich auch gelesen zu haben in einem Zusammenhang.

Beruhigend sind all diese Meldungen keinesfalls. Hoffe die Situation verbessert sich in Zukunft. Justin denkt schon ueber einen neuen Asset Server nach.

Als Sim Betreuer, die wir natuerlich abhaengig sind vom Asset Server, muessen wir natuerlich schauen, dass wir nicht zu stark in Mitleidenschaft gezogen werden. Wenn der Asset Server Lieferfristen, anstatt Antwortzeiten hat, dann muss das der Sim das verkraften koennen. Ich habe null Probleme ThreadPools bis zum Abwinken bereitzustellen, wuerde aber einfach gerne sehen ob die ueberhaupt verwendet werden.

Bin froh, wenn Justin da etwas Licht ins Dunkel bringt.

Was die Asset Server selber betrifft, kann ich natuerlich nix sagen, da ich selber keinen betreue. Aber Paketverlust toent unschoen.




(10.03.2012, 16:19)Rebekka Revnik schrieb: Als Nachtrag noch ein kleines Video von gestern abend
http://www.myvideo.de/watch/8469363

:-) Danke Rebekka! Inventar, wer braucht das schon... geht ja auch ohne, wzbw. lol sagt gerade die, welche noch einigermassen Haare auf dem Kopf hatte :-)

Das naechste mal hoffentlich mit funktionierenem Inventar und gleichbleibender Performance wie ohne Inventar :-)
Zitieren


Möglicherweise verwandte Themen…
Thema Verfasser Antworten Ansichten Letzter Beitrag
  [Wolf Territories] 1.-30.3.25: OpenSim Worlds Fair Jupiter Rowland 0 386 05.07.2024, 21:57
Letzter Beitrag: Jupiter Rowland
  Opensim-Modenschau 22.10.22 Loru Destiny 23 4.374 31.10.2022, 09:21
Letzter Beitrag: Jupiter Rowland
  Opensim Fest 2022 Dorena Verne 12 3.307 19.07.2022, 16:12
Letzter Beitrag: Xenos Yifu
  Modenschau in opensim Loru Destiny 1 1.047 09.05.2022, 14:24
Letzter Beitrag: Klarabella Karamell
  Best DJ/DJane Opensim gesucht Marina Baer 100 99.792 06.12.2017, 12:19
Letzter Beitrag: Kai Baer

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 3 Gast/Gäste