Croûtage dans les règles d'un serveur : Paramétrage d'Oracle ?

Croûtage dans les règles d'un serveur : Paramétrage d'Oracle ? - SQL/NoSQL - Programmation

Marsh Posté le 25-01-2006 à 15:49:23    

Salut,
 
Semaine dernière : un module de l'ERP qui tourne chez un de nos client part en sucette. Ayant 40 utilisateurs en train de boire des cafés à côté de la salle serveur tout en déplorant l'incompétence notable du service informatique (:sweat:) j'ai pas trop cherché à creuser sur le coup, puisque c'était la première fois que ça plantait. J'ai donc arrêté proprement ce qui tournait encore, rebooté le serveur, et tout est reparti normalement.
 
Lundi matin : badaboum. Même scénario. Sauf que là moi j'étais pas là, du coup c'est la cliente qui a rebooté le serveur, et j'ai pas vraiment eu l'occasion de creuser cette fois là non plus.
 
Ce matin : A ma demande, un technicien réseau/système vient auditer le réseau pour voir si on n'a pas des problème (l'erreur concernait la création d'un "serveur rpc", j'en avais déduit à la va vite une instabilité réseau). Coup de pot (enfin, façon ce parler) bananage à nouveau, mais cette fois un bon gros bananage de chez bananage. CPU bloqué à 100% pendant plus de 30 minutes, Oracle explosé à coup de process // dans tous les sens, et interface de contrôle de l'ERP plantée et impossible à redémarrer. On a attendu que ça se calme, et on a rebooté le serveur.
Depuis ça marche, mais on s'attends à ce que ça repète d'ici peu.
 
Après un appel à un collègue expert de l'ERP en question, il m'indique que les erreurs qu'on a obtenu sont généralement liées à des problèmes de manque de ressources. Si le nombre d'utilisateurs n'a pas changé, on a effectivement un changement notable dans la charge de la base Oracle, puisque j'ai écrit un intranet qui consulte la base Oracle en // de l'ERP.
 
Ayant écrit la chose en .NET, avec des évènements (databound sur des datagrid), je pense que le site génère joyeusement des requêtes en // à chaque page. Et notamment sur une page, je dois éxécuter environ 100 requêtes... Alors à la queue leue leue, pas de souci, ce sont des requêtes simples et rapides. Mais en // ça peut aisément être une source possible de problèmes dans Oracle.
 
Le collègue en question m'a indiqué que sur la version Unix de l'ERP (là on est sous Windows), il avait à plusieurs reprises résolu ce problème en augmentant le nombre de sémaphores du kernel Unix, et en augmentant le nombre de processes Oracles.
 
Seulement, là on est sous Windows, et si je ne m'abuse, y'a pas de sémaphores. Doit y avoir un autre truc par contre. Genre me semble-t-il une clé dans la base de registres qui permet de changer le nombre de process // et de threads.
Et pour la config d'Oracle, il n'a pas su me dire dans quel fichier c'était, ni encore moins quelle valeur mettre. Et vu que je suis pas plus DBA que lui, je sais pas non plus.
 
Donc la question est :
Où trouve-je les paramètres en question ? (Windows 2000 / Oracle 8.1.7)
Voyez-vous d'autres explications ?

Reply

Marsh Posté le 25-01-2006 à 15:49:23   

Reply

Marsh Posté le 25-01-2006 à 20:36:47    

as-tu des traces pertinentes dans le répertoire des traces ? (généralement <ORACLE_HOME>\database\SID\trace de mémoire)
Quelle est l'appli qui est à la base de ton intranet ? Si c'est PHP, ca fait appel à OCI, qui je crois utilise des cursors pour gérer sa partie privée
 
Regarde ton paramètre OPEN_CURSORS

Code :
  1. SQL> show parameters open_cursors


Regarde la taille de ta share pool
 
Mais ca se trouve on cherche pas là où il faudrait, vaut mieux analyser les logs plutôt que d'augmenter à tout hasard des paramètres qui pourrait écrouler la machine

Reply

Marsh Posté le 25-01-2006 à 22:50:11    

Salut,
 
Merci pour ta réponse !
 
Tout d'abors, je viens de passer 3 heures à revoir le code de l'appli intranet, afin de vérifier que je ferme correctement toutes les connections.
 
En effet, au départ la destruction des objets merdait, et j'avais déjà tout remodifié.
J'avais donc rechangé, histoire de bien tout fermer comme il faut.
 
Mais là, en ajoutant des logs sur mon objet de connection, je me suis apperçu que les objets mettaient trois plombes à se détruire... Et du coup une connection ouverte restait ouverte 300 secondes, même si elle n'était plus du tout utilisée.
 
Après re-modifications, je force bien la fermeture de chaque connection "à la main".
Seulement, la plupart du temps j'ai des erreurs "NullReferenceException", ce qui indique que mon ancien code marchait... parfois ! Un coup de try de goret, et maintenant ça doit être bon. J'espère juste que ça ferme pour de bon... Pas moyen de monitorer ADO malheureusement (ou alors je ne connais pas le moyen de le faire, et je suis preneur d'une suggestion ! :))
 
Sinon, le langage utilisé pour l'intranet, c'est C#/.NET
J'avais déjà posté ma détresse sur le sujet des connexions la semaine dernière.
 
 
Pour ce qui est des paramètres :


 
SQL*Plus: Release 8.1.7.0.0 - Production on Wed Jan 25 22:27:28 2006
 
(c) Copyright 2000 Oracle Corporation.  All rights reserved.
 
 
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.1 - Production
With the Partitioning option
JServer Release 8.1.7.4.1 - Production
 
SQL> select 1 from dual;
 
         1
----------
         1
 
SQL> show parameters open_cursors
ORA-00942: table or view does not exist
 
 
SQL> show parameters open_cursors;
ORA-00942: table or view does not exist
 
 
SQL>  


 
Hmmm... Faut être SYSTEM pour les voir ? Si c'est le cas, on est mal barrés, j'ai pas ce login, et la société qui a installé la base étant coulée depuis, je vois pas trop comment récupérer le mot de passes :sweat:
 
Arf !


SQL> connect system/manager
Connected.
SQL> show parameters open_cursors
 
NAME                                 TYPE    VALUE
------------------------------------ ------- ------------------------------
open_cursors                         integer 300
SQL>  


300 ça me semble pas trop mal déjà... A moins que les curseurs restent ouverts pendant qu'on se balade dans le jeu de résultat ?
 
Sinon, pour les logs, y'a rien dans le répertoire que tu indiques... Enfin... Il n'existe pas :D
 
Le "initSID.ora :


#  
##################################################################
#(2)                   -------Installation/Database Size------   #
#                      SMALL           MEDIUM           LARGE    #
#  Block         2K    4500K            6800K           17000K   #
#  Size          4K    5500K            8800K           21000K   #
#                                                                #
# Oracle 8i                                                      #
##################################################################
#                                    
#  
db_name = "SID"
instance_name = SID
service_names = SID
db_files = 1024
control_files = (d:\oracle\ora81\DATABASE\ctl1SID.ora)
control_files = (d:\generix\serveur\data\ctl2SID.ora)
#        
open_cursors = 300  
max_enabled_roles = 30  
db_file_multiblock_read_count = 8  
db_block_buffers = 8110  
shared_pool_size = 52428800  
large_pool_size = 15728640  
#java_pool_size = 0  
# sk 15/12/2003  avant =
optimizer_mode=RULE
#        
log_checkpoint_interval = 10000  
log_checkpoint_timeout = 1800  
#        
processes = 200 # sk 15/12/2003  avant =150  
parallel_max_servers = 5  
log_buffer = 32768  
#        
max_dump_file_size = 10240  
#        
global_names = true  
oracle_trace_collection_name =""  
user_dump_dest=%DIR_RDBMS%\trace  
db_block_size = 8192  
#        
background_dump_dest=%DIR_RDBMS%\trace  
remote_login_passwordfile = exclusive  # shared      
os_authent_prefix =""  
distributed_transactions = 10  
sort_area_size = 65536  
sort_area_retained_size = 65536  
#  
rollback_segments = (roll_1)          
rollback_segments = (roll_2)          
compatible = 8.1.5.0.0  
UTL_FILE_DIR=* \



 
A noter que "RULES" est déprecated, mais l'ERP a été écrit à l'origine pour obtenir de meilleurs perfs avec ce mode. Dans la doc technique, il est stipulé que sur les 9i et 10g ils préconisent maintenant STATISTICS, mais mettent en garde contre l'importance du tunning afin de ne pas avoir des perfs catastrophiques, et préconisent donc toujours RULES pour les sociétés qui n'ont pas un DBA sous la main (c'est le cas chez ce client)
 
Voici le "SQLNet.log" :


***********************************************************************
Fatal NI connect error 12640, connecting to:
 (DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oraclegnx)(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=gnx)(CID=(PROGRAM=d:\oracle\ora81\bin\ORACLE.EXE)(HOST=SRVBCI)(USER=SYSTEM))))
 
  VERSION INFORMATION:
 TNS for 32-bit Windows: Version 8.1.7.4.0 - Production
 Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version 8.1.7.4.0 - Production
  Time: 25-JAN-2006 12:25:12
  Tracing not turned on.
  Tns error struct:
    nr err code: 0
    ns main err code: 12640
    TNS-12640: Authentication adapter initialization failed
    ns secondary err code: 0
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
 
 
***********************************************************************
Fatal NI connect error 12640, connecting to:
 (DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oraclegnx)(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=gnx)(CID=(PROGRAM=d:\oracle\ora81\bin\ORACLE.EXE)(HOST=SRVBCI)(USER=SYSTEM))))
 
  VERSION INFORMATION:
 TNS for 32-bit Windows: Version 8.1.7.4.0 - Production
 Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version 8.1.7.4.0 - Production
  Time: 25-JAN-2006 12:25:12
  Tracing not turned on.
  Tns error struct:
    nr err code: 0
    ns main err code: 12640
    TNS-12640: Authentication adapter initialization failed
    ns secondary err code: 0
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0


 
A noter que ces erreurs sont quelques instants après le reboot, à priori des requêtes en spool qui se sont faites gicler du moteur qui s'arrêtait (3 minutes avant le reboot du serveur, sâchant qu'il était planté depuis au moins 30 minutes)
 
-- Edit : En fait, en regardant bien, cette erreur se produit quelques instants après chaque reboot. Ca doit correspondre au message d'erreur qu'on a au moment du chargement de l'ERP : il essaie de démarrer la base, qui est déjà démarrée...
M'enfin c'est pas bien grave, puisque la base est déjà démarrée :D
 
A noter que dans l'EventLog de Windows, à part des tas d'alerts "PerfLog" indiquant des délais exprirés dans les prises de mesures des perfs système, y'a aucun truc étrange avant le reboot. Ces messages sont explicables par la charge CPU de 100% pendant 30 minutes.
 
Le "SIDALRT.log" est normal :


Thread 1 advanced to log sequence 25867
  Current log# 3 seq# 25867 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG3GNX.DBF
Wed Jan 25 11:27:19 2006
Thread 1 advanced to log sequence 25868
  Current log# 4 seq# 25868 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG4GNX.DBF
Wed Jan 25 11:36:33 2006
Thread 1 advanced to log sequence 25869
  Current log# 1 seq# 25869 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF
Wed Jan 25 11:57:38 2006
Thread 1 advanced to log sequence 25870
  Current log# 2 seq# 25870 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG2GNX.DBF
Dump file d:\oracle\ora81\RDBMS\trace\gnxALRT.LOG
Wed Jan 25 12:28:58 2006
ORACLE V8.1.7.4.1 - Production vsnsta=0
vsnsql=f vsnxtr=3
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Starting up ORACLE RDBMS Version: 8.1.7.4.1.
System parameters with non-default values:
  processes                = 200
  shared_pool_size         = 52428800
  large_pool_size          = 15728640
  control_files            = d:\oracle\ora81\DATABASE\ctl1gnx.ora, d:\generix\serveur\data\ctl2gnx.ora
  db_block_buffers         = 8110
  db_block_size            = 8192
  compatible               = 8.1.5.0.0
  log_buffer               = 32768
  log_checkpoint_interval  = 10000
  log_checkpoint_timeout   = 1800
  db_files                 = 1024
  db_file_multiblock_read_count= 8
  rollback_segments        = roll_1, roll_2
  max_enabled_roles        = 30
  remote_login_passwordfile= EXCLUSIVE
  global_names             = TRUE
  distributed_transactions = 10
  instance_name            = gnx
  service_names            = gnx
  sort_area_size           = 65536
  sort_area_retained_size  = 65536
  db_name                  = gnx
  open_cursors             = 300
  os_authent_prefix        =  
  optimizer_mode           = RULE
  utl_file_dir             = *
  parallel_max_servers     = 5
  background_dump_dest     = %DIR_RDBMS%\trace
  user_dump_dest           = %DIR_RDBMS%\trace
  max_dump_file_size       = 10240
  oracle_trace_collection_name=  
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
Wed Jan 25 12:29:02 2006
alter database mount exclusive  
Wed Jan 25 12:29:09 2006
Successful mount of redo thread 1, with mount id 1200376725.
Wed Jan 25 12:29:09 2006
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Wed Jan 25 12:29:09 2006
alter database open
Beginning crash recovery of 1 threads
Wed Jan 25 12:29:11 2006
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 1 Seq 25869 Reading mem 0
  Mem# 0 errs 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF
Recovery of Online Redo Log: Thread 1 Group 2 Seq 25870 Reading mem 0
  Mem# 0 errs 0: D:\GENERIX\SERVEUR\DATA\LOG2GNX.DBF
Wed Jan 25 12:29:13 2006
Thread recovery: finish rolling forward thread 1
Thread recovery: 278 data blocks read, 89 data blocks written, 3594 redo blocks read
Crash recovery completed successfully
Wed Jan 25 12:29:14 2006
Thread 1 advanced to log sequence 25871
Thread 1 opened at log sequence 25871
  Current log# 3 seq# 25871 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG3GNX.DBF
Successful open of redo thread 1.
Wed Jan 25 12:29:14 2006
SMON: enabling cache recovery
SMON: enabling tx recovery
Wed Jan 25 12:29:16 2006
Completed: alter database open
Wed Jan 25 14:01:04 2006
Thread 1 advanced to log sequence 25872
  Current log# 4 seq# 25872 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG4GNX.DBF
Wed Jan 25 14:28:25 2006
Thread 1 advanced to log sequence 25873
  Current log# 1 seq# 25873 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF
Wed Jan 25 14:42:58 2006
Thread 1 advanced to log sequence 25874
  Current log# 2 seq# 25874 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG2GNX.DBF
Wed Jan 25 15:10:12 2006
Thread 1 advanced to log sequence 25875
  Current log# 3 seq# 25875 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG3GNX.DBF
Wed Jan 25 15:30:41 2006
Thread 1 advanced to log sequence 25876
  Current log# 4 seq# 25876 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG4GNX.DBF
Wed Jan 25 15:49:45 2006
Thread 1 advanced to log sequence 25877
  Current log# 1 seq# 25877 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF
Wed Jan 25 16:46:58 2006
Thread 1 advanced to log sequence 25878
  Current log# 2 seq# 25878 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG2GNX.DBF
Wed Jan 25 17:10:21 2006
Thread 1 advanced to log sequence 25879
  Current log# 3 seq# 25879 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG3GNX.DBF
Wed Jan 25 21:04:25 2006
Thread 1 advanced to log sequence 25880
  Current log# 4 seq# 25880 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG4GNX.DBF
Wed Jan 25 22:09:40 2006
Thread 1 advanced to log sequence 25881
  Current log# 1 seq# 25881 mem# 0: D:\GENERIX\SERVEUR\DATA\LOG1GNX.DBF


=> Les rotations de logs ne sont pas plus rapides avant qu'après reboot.
 
Et rien de particulier dans le listner.log


25-JAN-2006 12:07:17 * service_update * gnx * 0
25-JAN-2006 12:07:19 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4354)) * establish * gnx * 0
25-JAN-2006 12:08:04 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=C:\Program Files\Quest Software\TOAD\TOAD.exe)(HOST=METAFRAME01)(USER=MARYSE))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.0.198)(PORT=4861)) * establish * gnx * 0
25-JAN-2006 12:13:37 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4356)) * establish * gnx * 0
25-JAN-2006 12:16:47 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4358)) * establish * gnx * 0
25-JAN-2006 12:17:18 * service_update * gnx * 0
25-JAN-2006 12:23:07 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4360)) * establish * gnx * 0
25-JAN-2006 12:25:13 * service_died * gnx * 12547
TNS-12547: TNS:lost contact
 
TNSLSNR for 32-bit Windows: Version 8.1.7.4.0 - Production on 25-JAN-2006 12:28:54
 
(c) Copyright 1998 Oracle Corporation.  All rights reserved.
 
System parameter file is d:\oracle\ora81\network\admin\listener.ora
Log messages written to d:\oracle\ora81\network\log\listener.log
Trace information written to d:\oracle\ora81\network\trace\listener.trc
Trace level is currently 0
 
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=srvbci.BCI.local)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC0ipc)))
TIMESTAMP * CONNECT DATA [* PROTOCOL INFO] * EVENT [* SID] * RETURN CODE
25-JAN-2006 12:29:02 * service_register * gnx * 0
25-JAN-2006 12:29:11 * service_update * gnx * 0
25-JAN-2006 12:29:24 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4363)) * establish * gnx * 0
25-JAN-2006 12:32:34 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4365)) * establish * gnx * 0
25-JAN-2006 12:33:53 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4367)) * establish * gnx * 0
25-JAN-2006 12:35:44 * (CONNECT_DATA=(SERVICE_NAME=gnx)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=WEB)(USER=SERVICE?R?SEAU))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.1.11)(PORT=4369)) * establish * gnx * 0
25-JAN-2006 12:39:11 * service_update * gnx * 0


Message édité par Arjuna le 25-01-2006 à 22:56:50
Reply

Marsh Posté le 25-01-2006 à 23:43:38    

au vu de ton init, les traces sont dans ton ORACLE_HOME\trace
 
ton share pool n'est pas énorme, mais ptet que l'ERP n'a pas besoin de plus
 
pour ce qui est du plan d'exécution, effectivement le mieux est de mettre un mode CHOOSE plutôt que RULES, et récolter les stats de manière périodique (package dbms_stats je crois)
pas besoin d'un DBA, juste besoin d'un mec qui le met en place via l'ordonnaceneur de la boîte ou via le plannificateur de tâche windows, ou via l'ordonnanceur interne d'oracle (package dbms_jobs je crois)
Mais bon si l'éditeur de l'ERP dit qu'il ne faut pas, mieux ne vaut pas s'amuser à changer des trucs en prod. sans en mesurer les réelles impacts, car en activant les stats il peut arriver que l'on perd en perf.
Mais cela ne résoudra pas ton problème
 
au vu du listener.log il n'y pas tant de connexions parallèles que ca, mais j'avoue que voir un Oracle planter sans raisons apparentes, c'est assez rare, même en ayant des connexions mal déconnectées, normalement Oracle les déconnecte proprement
 
j'aime pas trop l'option "compatible = 8.1.5.0.0" mais bon on n'y peut rien :D
 
tu n'as plus qu'à espérer un vrai DBA expérimenté traîne ici =)
As-tu regarder les alertes systèmes du serveur ? Parfois des choses intéressantes peuvent apparaîtres dans l'event viewer de windows
 
bon courage

Reply

Marsh Posté le 25-01-2006 à 23:54:53    

Justement, y'a rien dans l'eventlog de Windows. Juste des alertes "perflib".
 
Ceci dit, on n'est pas sûrs que c'est Oracle qui part en live... En effet, l'ERP et Oracle sont sur le même serveur, et quand la charge était de 100%, aucun process ne dépassait 5% d'utilisation CPU, du coup c'est un service ou un process "caché" qui est parti en couille, et impossible de savoir lequel :sweat:

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed