[PROPOSTA]ai player per la lag

[Puch]

Originally posted by Sole Nero
Una cosa è certa: se si possono fare dei test drastici è meglio farli alla svelta, finché ci sono relativamente pochi utenti loggati.
Io ad esempio metterei su il server con gli script così come erano prima che la lag iniziasse. Visto che i cosiddetti test in locale non consentono agli scripter di capire la ragione della lag, probabilmente si tratta di interazioni fra gli script e il server vero e proprio.

Esattamente.

[Ospite]

Concordo quando arriveranno altri pg a fine estate sara + problematica la cosa

[guren]

Non so se qualcuno di voi gioca anche di notte ma posso dirvi che negli orari notturni il problema non esiste.

In condizioni di pg in numero limitato la lag è minima o forse nulla, quindi per me il problema non sta in script nuovi ce vanno in loop o cose simili, ma sta nelle TROPPE informazioni che di pomeriggio con 500-600 pg connessi superano la banda disponibile o almeno qualcosa del genere.

In quanto ai nuovi scripter non bisogna far altro che elogi dato che abbiamo visto cambiare il server in modo quasi totale e( da programmatore che sono, non di c# ma c e c++), vi posso dire che implementando nuovi script è cosa solita andare in conflitto con altre, ma se ci fate caso le risolvono giorno per giorno.

Stanno facendo un ottimo lavoro!!!

Ora è risultato un enorme problema che è la lag.
E soprattutto TESTARLA e DEBUGGARLA è cosa assai ardua.

La proposta era almeno per aiutarli nel limitare il paccheeto informazioni da controllare (se il problema è li).
Se non è così.... bhe , almeno una cosa possiamo scartarla.

Le cose da controllare sono troppe.
Forse avete ragione nel dire che potrebbe essere uno script che va in loop e si fa sentire quando i loop cominciano ad essere molti , forse avete ragione nel dire che è stata messa qualche free in meno, o forse c'è qualche puntatore che punta a *****, chissà.

Ma se non diamo una mano anche noi nel semplificare le cose non arriveremo a capo a nulla.

Ultimo appello ai GM:
FORZA RAPSODY !!! FORZA KOPER!!! DAJE ANGELUS!!! che je la fate!!!!

Ultimo appello ai PG:
Controllare tra 50 thread che mi generano lag o controllare tra 5 il tempo di risoluzione cambia decisamente!!! Aiutiamo i GM che vi ricordo : LAVORANO PER IL NOSTRO DIVERTIMENTO!!!

[isterico]

fila come a wow per loggare?
oddio speriamo trovino la soluzione ;_;

[Famous]

bah ragazzi io mi sn accorto ke la lag è cominciata dal momento in cui è stato attivato tokuno i gm però dicono ke quella nn è la causa.... il problema però e ke di mattina quando ci sn poki utenti online il server nn lagga poi quando si arriva alle 11-12 nn si può + stare.....





BUG COLOSSALE???? KI LO SA.......

[InsomNiaitaly]

Se la gente la smettesse di spammare ******te a nastro a luna si giocherebbe meglio secondo me. La banca di luna è INGIRABILE

[gabrie]

Ci sono 5 mondi...io a Luna ci vado pochissimo,fai cosi anche tu.

[Stormcrow]

La disponibilità di banda non c'entra nulla con il problema del lag. Neppure l'ipotesi del deadlock mi pare credibile altrimenti il server si bloccherebbe permanentemente.
RunUO ha un peccato originale di essere scritto in C# che è basato sul framework .NET.
Programmando in questo ambiente lo sviluppatore non ha il controllo reale sull'uso della memoria, i programmi ne usano moltissima e non la liberano mai esplicitamente.

La memoria viene liberata da un entità che si chiama "Garbage Collector", questo coso esamina lo stato della memoria e decide quali parti possono essere liberate e rese di nuovo disponibili all'applicazione. Quando questo garbage collector entra in funzione si verifica quel lag che noi tutti così tanto amiamo.

Le soluzioni a questo problema non sono semplici e neppure immediate, fra le cose fattibili:

• Uso di un framework .NET a 64 bit che dovrebbe consentire al server di girare in uno spazio d'indirizzamento virtuale superiore ai 2GB, mi risulta che il team di RunUO lo abbia già sperimentato. Il maggior spazio di memoria allevierebbe il problema della frammentazione, anche il GC interverrebbe meno spesso.
  Se ricordo bene, il normale .NET a 32 bit non vede più di 2GB di memoria anche se nel sistema ne sono presenti molti di più (vado un pò a leggere lo MSDN al riguardo).
• Ricodifica parziale degli script per ridurre l'uso di oggetti dinamici, staticizzando le strutture dati per quanto possibile (lungo e problematico per il debug).

La mia opinione è che una semprice new posta in un punto del codice frequentemente eseguito può provocare il problema che conosciamo, suggerirei di controllare tutte le allocazioni di oggetti aggiunte sul runuo originale e chiedersi: ma questa allocazione mi serve proprio ? posso staticizzarla ? posso muoverla in un punto meno critico.

Ovviamente i nostri power scripter tutto questo lo sanno già

Edit: Una domanda, il server usa WinXP a 64 bit per caso ? in tal caso si potrebbe provare la beta del framework .NET a 64bit.

[helix]

Originally posted by Restless Soul

..Ok, banale ma sapete com'e': quando non si trova una cosa magari e' proprio nel posto piu' in vista

E' quasi sempre così, cmq magari ad agosto perchè non provate a staccare tokuno per qualche ora?

[gabrie]

Originally posted by helix



E' quasi sempre così, cmq magari ad agosto perchè non provate a staccare tokuno per qualche ora?

Lo hanno già fatto...e laggava uguale

[Cugio]

Cleaning Resources....

[Stormcrow]

Ho trovato degli articoli interessanti su MSDN su questo tipo di problematiche, ci sono un sacco di raccomandazioni per evitare o ridurre i problemi sul tipo del nostro "lag".

La lista sintetica delle raccomandazioni è la seguente:

The .NET garbage collector provides a high-speed allocation service with good use of memory and no long-term fragmentation problems, however it is possible to do things that will give you much less than optimal performance.

To get the best out of the allocator you should consider practices such as the following:

• Allocate all of the memory (or as much as possible) to be used with a given data structure at the same time.
  Remove temporary allocations that can be avoided with little penalty in complexity.
• Minimize the number of times object pointers get written, especially those writes made to older objects.
  Reduce the density of pointers in your data structures.
• Make limited use of finalizers, and then only on "leaf" objects, as much as possible. Break objects if necessary to help with this.

A regular practice of reviewing your key data structures and conducting memory usage profiles with tools like Allocation Profiler will go a long way to keeping your memory usage effective and having the garbage collector working its best for you.

Pare che specialmente i finalizer siano un grosso problema in quanto costringono i GC a passare gli oggetti da finalizzare ad un thread apposito che effettua la finalizzazione. Inoltre la finalizzazione differita comporta un operazione di GC non ottimale.

[Lordcainzero]

Originally posted by Raoul
Se riduceste la ***** che schiaffate dentro le case il server non laggherebbe questo ve lo do per certo.

Io nel mio account avrò avuto 1000 stone tra tutti i pg e pure dentro casa.

Se tutti voi foste messi così il server non laggherebbe.

Il problema sono i pvm che si tengono anche la spada +1 Snorky Slayer e l'anello -2 taming.

non posso che uppare in pieno.
se avete troppa roba vendetela.
se è invendibile cestinatela.
lo so anche io che è bello conservare tutto come faceva la nonna con i vs. giocattolini, ma tenere una casa piena zeppa di roba inutile.

[Ospite]

Originally posted by Mastro Lani
Ho trovato degli articoli interessanti su MSDN su questo tipo di problematiche, ci sono un sacco di raccomandazioni per evitare o ridurre i problemi sul tipo del nostro "lag".

La lista sintetica delle raccomandazioni è la seguente:



Pare che specialmente i finalizer siano un grosso problema in quanto costringono i GC a passare gli oggetti da finalizzare ad un thread apposito che effettua la finalizzazione. Inoltre la finalizzazione differita comporta un operazione di GC non ottimale.

Parebbe...

La cosa da osservare sarebbe inoltre la differenza tra un processo Cleaning Resouces normale e uno "forzato".

Controllate eventuali differenze di status delle risorse in entrambi i casi: potrebbe essere decisivo.

In ogni caso questo cleaning resources non mi pare efficacissimo, ma a dire il vero prima di tokuno non mi sembrava facesse sti gran danni. Impressione mia? No perche' in tal caso (se avessi ragione io) si dovrebbe perlomeno controllare solo la parte relativa a tokuno. In alternativa, TUTTO il codice O_o'

p.s. un deadlock non risulta sempre in uno stallo permanente del sistema :>, ma a maggior ragione della mia ipotesi mi risulta che si possa ovviare "forzosamente" al deadlock nella maggioranza o totalita' dei casi in due modi: riavvio o liberazione forzata delle risorse. Dato che quando si fa il cleaning forzato da comando, tutto torna normale entro un buon lasso di tempo, cio' mi fa intuire che potrebbe essere un problema del tipo.

[Alessandro81]

Re: [PROPOSTA]ai player per la lag

Originally posted by Arioch

La proposta quindi è semplice:
1. un po' più di attenzione quando si esce a mostri(del tipo evitare di buttare a terrà oggetti non presi e di raccogliere ogni tanto qualcosa di troppo a terra per far mantenere lo scenario + pulito possibile)
2. tenere il + pulita possibile l'abitazione mettendo gli oggetti in casse

ATTENZIONE: non dico di stressarsi a pulire lo spawn o di non arredare casa, propongo solo di stare + attenti tutti!!!!
!

direi che sono proposte sensate chi dice che nn serve forse nn pensa a quant players giocano su dreams e a quante case ci sono cominicamo tutti a fare qualcosa di concreto invece di lamentarsi sempre per la lag, riavviare il server è solo una soluzine temporanea