Version haut débit de: wwF - Forum
Aide - Rechercher - Membres

A propos du binaire du serveur wwf*

Madtree (09 Mai 2007, 14:25)
Je passe dans le coin pour communiquer aux gens qui s'occupent de maintenir le serveur wwf (P'tit Nico ?) 2-3 instructions, pour le build du seveur sur un machine de type kimsufi :).

Voila la procédure que j'ai suivi pour faire le build que j'ai fait pour vous y'a deux semaines (je ne sait pas si vous l'utilisez toujours):

La compilation se fait sous linux

1- Récuperation des sources de tremulous, dans la version SVN qui va bien :

Citation
# svn co svn://svn.icculus.org/tremulous/trunk tremulous-svn -r 901


2- Récuperation du PierreF's patchset, parce que je le vaut bien ;).

Citation


3- Patchage des sources (le truc chiant) :
Citation

# cd tremulous-svn/
# cat ../patches/wraths/svn901/999.all_in_one-037.patch | patch -p1
(patchs principaux)
# cat ../patches/wraths/svn901/998.pierre.training_freefunds_fastbuild_nobaseattack.patch | patch -p1
(pour les trucs de training, comme le nom l'indique)
# cat ../patches/svn901/002.pierref.deco_exploding_sd.patch | patch -p1
# cat ../patches/svn901/003.madtree.risujin_donate_improved.patch | patch -p1
(deux patchs ajoutés tardivement)


4- Modification du Makefile : (Y'a deux trois trucs a modifier)

Au début:

Citation
BUILD_CLIENT = 0
BUILD_CLIENT_SMP = 0
BUILD_SERVER = 1
BUILD_GAME_SO = 1
BUILD_GAME_QVM = 0


Et un peu plus loin:
Citation

#############################################################################
# SETUP AND BUILD -- LINUX
#############################################################################

## Defaults
VM_PPC=

LIB=lib

INSTALL=install
MKDIR=mkdir

ifeq ($(PLATFORM),linux)

CC=gcc

ifeq ($(ARCH),alpha)
ARCH=axp
else
ifeq ($(ARCH),x86_64)
LIB=lib64
else
ifeq ($(ARCH),ppc64)
LIB=lib64
else
ifeq ($(ARCH),s390x)
LIB=lib64
endif
endif
endif
endif

BASE_CFLAGS = -march=pentium4 -Os -fomit-frame-pointer -Wall -fno-strict-aliasing -Wimplicit -Wstrict-prototypes -pipe

ifeq ($(USE_OPENAL),1)
BASE_CFLAGS += -DUSE_OPENAL=1
ifeq ($(USE_OPENAL_DLOPEN),1)
BASE_CFLAGS += -DUSE_OPENAL_DLOPEN=1
endif
endif

ifeq ($(USE_CODEC_VORBIS),1)
BASE_CFLAGS += -DUSE_CODEC_VORBIS=1
endif

ifeq ($(USE_SDL),1)
BASE_CFLAGS += -DUSE_SDL_VIDEO=1 -DUSE_SDL_SOUND=1 $(shell sdl-config --cflags)
GL_CFLAGS =
else
GL_CFLAGS = -I/usr/X11R6/include
endif

OPTIMIZE = -Os -march=pentium4 -ffast-math -funroll-loops -fomit-frame-pointer

ifeq ($(ARCH),x86_64)
OPTIMIZE = -O3 -fomit-frame-pointer -ffast-math -funroll-loops \
-falign-loops=2 -falign-jumps=2 -falign-functions=2 \
-fstrength-reduce
# experimental x86_64 jit compiler! you need GNU as
HAVE_VM_COMPILED = true
else
ifeq ($(ARCH),x86)
OPTIMIZE = -Os -march=pentium4 -fomit-frame-pointer -ffast-math \
-funroll-loops -falign-loops=2 -falign-jumps=2 \
-falign-functions=2 -fstrength-reduce
HAVE_VM_COMPILED=true
else
ifeq ($(ARCH),ppc)
BASE_CFLAGS += -maltivec
ifneq ($(VM_PPC),)
HAVE_VM_COMPILED=true
endif
endif
endif
endif

ifneq ($(HAVE_VM_COMPILED),true)
BASE_CFLAGS += -DNO_VM_COMPILED
endif

DEBUG_CFLAGS = $(BASE_CFLAGS) -g -O0

RELEASE_CFLAGS=$(BASE_CFLAGS) -DNDEBUG $(OPTIMIZE)

SHLIBEXT=so
SHLIBCFLAGS=-fPIC
SHLIBLDFLAGS=-shared $(LDFLAGS)

THREAD_LDFLAGS=-lpthread
LDFLAGS=-ldl -lm

ifeq ($(USE_SDL),1)
CLIENT_LDFLAGS=$(shell sdl-config --libs)
else
CLIENT_LDFLAGS=-L/usr/X11R6/$(LIB) -lX11 -lXext -lXxf86dga -lXxf86vm
endif

ifeq ($(USE_OPENAL),1)
ifneq ($(USE_OPENAL_DLOPEN),1)
CLIENT_LDFLAGS += -lopenal
endif
endif

ifeq ($(USE_CODEC_VORBIS),1)
CLIENT_LDFLAGS += -lvorbisfile -lvorbis -logg
endif

ifeq ($(ARCH),x86)
# linux32 make ...
BASE_CFLAGS += -m32
LDFLAGS+=-m32
endif

else # ifeq Linux


5- Ensuite y'a plus qu'a compiler :
Citation

# make -j4



Voila, normalement ca devrais tourner avec cela... J'ai oublié un des CFLAGS que j'avais ajouté, mais de toute manière, il étais assez inutile :roll: .

Je vous conseille d'utiliser un .so plutôt qu'un game.qvm, car j'ai constaté (sur 2 serveurs, mais je ne peut pas verifier plus) que le .so consome un peu moins de ressources, mais le .qvm est toujours possible en modifiant le Makefile en fonction.

Notez que si vous avez besoin de faire un autre build, y'a toujours moyen de me contacter par mail ou par IRC (quand je suis la).
P'tit Nico ;-) (09 Mai 2007, 17:54)
Hello Madtree :)

Un grand merci pour toutes ces explications détaillés ! :good:
Effectivement nous utilions toujours le binaire que tu m'avais fourni il y a quelque temps, tout semble rouler mis à part des maps comme Nexu6 qui fait ramer le serv et que j'ai du supprimer de la rotation :( (visiblement Greudin l'avait viré de Brico pour les mêmes raisons).

Ma question est la suivante : y a t il des différences entre le binaire que tu m'as déjà fourni et celui que tu me propose de compiler ? Ai je un intérêt à le compiler sur le serv ? Ça sera encore mieux ?

Sinon encore merci pour l'actuel binaire, le serv se comporte déjà mieux qu'avant.

:flowers:
Madtree (09 Mai 2007, 18:10)
Y'aurais aucune difference avec le binaire actuel, j'ai juste posté ça pour que tu puisses le refaire sans moi au besoin :).
Pour ce qui est de le compiler sur le serv lui même, tout dépends de ta version de GCC ainsi que de l'arch sous lequel il a été compilé (CHOST). Si le serv est sous debian, il se peut que tu y perdes un petit peu, étant donné que gcc a été compilé pour i386 (et pas 686 comme sur mon petit GCC personnel de roxor :p ), mais ça reste à verrifier.
P'tit Nico ;-) (09 Mai 2007, 21:35)
Merci pour toutes ces précisions, je reste avec mon binaire actuel alors. ;)

:beer:
P'tit Nico ;-) (26 Mai 2007, 18:24)
Après moult essais il semblerait bien que le binaire actuel et un léger soucis, au bout d'un jour d'uptime le binaire perd des paquets, le serv lag même sans joueurs dessus (flagrant au lagometre). Si je tue le serveur et que je le relance de suite le lagometre est plat. :huh:

Je viens à l'instant de mettre un nouveau binaire fourni par Azrael, on va tester pour voir. :unsure:
gunzip (26 Mai 2007, 19:02)
un cron qui tue et relance le tremded tout les matins vers 5h :)
P'tit Nico ;-) (27 Mai 2007, 2:35)
Ah pas con comme idée ça. ;)
Mais dans l'absolu il devrait pas y avoir ce genre de problème du tout. :(


Hésitez pas à venir poster ici pour dire si vous remarquez des changements dans le comportement du serveur.
gunzip (27 Mai 2007, 6:36)
plus l'uptime est long et plus le server a du mal on dirait (pcq il mangeait pas trop mal "transit" pendant qu'on le testais (luci spam, repeater partout, grenade script, pulse etc...)

Faudrait voir si tremded prend pas de plus en plus de ram au grès du temps, et si y'a pas autre chose qui pompe de la ram, voir faire une petite cure au server lui meme :) j'suis sur y'a des trucs a virer (meme sur une debian de base y'a des trucs a virer (aussi bien pour une workstation qu'un server)
Elaum (27 Mai 2007, 8:05)
Les lags qui apparaissent au cours du temps ça pourrais venir de la ram virtuelle si le disque est beaucoup fragmenté. Ou d'un manque de ram tout simplement.
mikael (27 Mai 2007, 9:01)
Sur nunux il y a des prob' de fragmentation?



Pour une fois, j'croi que Gz a raison... :-°
gunzip (27 Mai 2007, 11:24)
Les lags qui apparaissent au cours du temps ça pourrais venir de la ram virtuelle si le disque est beaucoup fragmenté. Ou d'un manque de ram tout simplement.


l'Ext3 ca fragmente pas ;) (enfin, trop peu pour avoir la moindre incidence sur les performances)

sinon, ouais, 256mo de ram, c'est short, faudrait voir si en condition de jeu FFA avec 12 personnes combien ca consomme, si ya d'la ram libre, ou si tout simplement (comme quand infos-du-net.com etait que sur un seul serveur dédié) le server utilise pas de préférence le swap que la ram... =)

mais vu que le server repart bien si tremded est relancé, ca doit surment venir de l'utilisation d'la ressource mémoire ;) (qui a parlé de leak of memory ? :p)

dernier recours après avoir néttoyer un bon coup le serveur => priorité plus grande pour tremded ;)

sinon ptit nico, file moi le server (binaire + .cfg (sans logs ni maps off course) j'laisserai mon pc tourné 1-2jours avec le server lancé dessus pour voir si c'est le binaire en lui meme qu'a du mal =/

@mika : j'ai toujours raison :)
Elaum (27 Mai 2007, 13:04)
J'avait oublié que c'était sous linux. Je pensais encore à de la FAT32 donc :D
gunzip (27 Mai 2007, 13:30)
:D fat16 = bouse, fat32= engrais bio, ntfs=terreau :p
DaTosstt (27 Mai 2007, 14:26)
Perso j'utilise les mêmes patchs. Mais pas de modification particulière du Makefile (pour les options de compilation) sous GNU/debian etch.

Remarque pour les modifications des variables du Makefile il suffit de creer un fichier Makefile.local et de les mettres dedans.

Idee:
- recompiler sans les options precisant l'architecture.
- essayer avec les options de limitation de memoire

afficher un top (cpu/mem etc)

J'ai tenter un strace sur le binaire mais c'est une horreur ;-)

Rapidement votre,
Madtree (27 Mai 2007, 14:38)
Merci DaTosstt, mais ce que tu proposes correspond exactement à ce que j'ai fais :).

Par contre je vais tenter un mtrace, histoire de partir à la chasse des fuites mémoire...
DaTosstt (28 Mai 2007, 12:36)
Je connaissai pas mtrace.
Si j'ai bien lu les logs du chan ton mtrace n'a rien donné.
Il y a aussi valgrind mais je ne l'ai jamais utilisé.

Il faut peut-etre considérer que le problème ne vient pas que de tremulous, mais peut-etre de processus qui tourne au meme moment...

Un problème de mémoire, ou de swap.

Exemple de scénario:
- lancement du serveur tremu, chargement en memoire
- lancement d'autres process plus actif
- manque de ram
- passage des processus les moins utilisés en swap (dont tremu)
- utilisation d'un partie du swap qui se trouve comme par hazard dans une zone deffectueuse du disque
- probleme, lenteur, crash, ...


Autre idee, lancer le serveur avec des "ulimit" plus resctrictif. S'il y a fuite de mémoire ou explosion de resource le binaire se fera tuer ou crashera faute d'avoir ce qu'il veux. Mais au moins vous aurez un résultat rapidement.

Sinon jle redis, essayer avec une compil en x83 (non optimisé pour l'architecture courante)
et/ou essayer avec d'autres version du compilo (gcc 3.x et 4.x)
PierreF (04 Septembre 2007, 14:25)
Madtree : noob XD

Trop compliquer ta version pour prendre les sources !! :p

Si on veux un serveur avec tous les patchs Duck'n Car (trem.yi.org), le plus simple c'est :

svn co https://trem.yi.org/svn/ mon_dossier
cd mon_dossier
python scripts/do_all.py --out dossier_src


et voila, on a dans dossier_src les sources avec tous ce qu'il faut :)

On peut reprendre le 4 de Madtree

le do_all.py peut prendre quelque options, un --help fait semblent de donner un peu de doc :)

En fait on a 3 sources de patch:
- wrath
- other
- my
(appliqué dans cette ordre)
Donc trois options pour do_all :
--wraths
--other
et --my

Par defaut wraths vaut all et 998, other vaut all et my vaut all.

Les valeur possible sont :
- x,y,... (applique le patch n° x et n°y)
- x-y (applique du n°x au n°y
- all (applique de 0 à 899)

on peut en donner plusieur (ex: do_all.py --out coin --my 1-2 --my 3,4 --my 5

Si on veux aucun patch d'une source on ne met rien :) (ex: do_all.py --other).

voila un doc presque completement pourite :)