(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 ....