Bonnes pratiques pour

la configuration et
l’exploitation de
l’infrastructure
informatique
Sage X3

Stéphane POULON
01 2020

Page 1 de 14
Sommaire
OBJECTIF .............................................................................................................................................. 3

I - SYSTEME D’EXPLOITATION WINDOWS ...................................................................................... 4

I.1 - RECOMMANDATIONS ..................................................................................................................... 4

II - VIRTUALISATION ........................................................................................................................... 5

II.1 - BIOS .......................................................................................................................................... 5

II.2 - RÉSEAU ...................................................................................................................................... 5
II.3 - HYPER-THREADING ..................................................................................................................... 6

III - SERVEURS ET STOCKAGE ......................................................................................................... 7

III.1 - MISES À JOUR ............................................................................................................................ 7

III.2 - TECHNOLOGIE SSD .................................................................................................................... 7
III.3 - TAILLE UNITÉ D’ALLOCATION ........................................................................................................ 7
III.4 - TAUX D’OCCUPATION DISQUE ...................................................................................................... 7
III.5 - DÉFRAGMENTATION .................................................................................................................... 7
III.6 - RÉSEAU ..................................................................................................................................... 8

IV - DOSSIERS ET APPLICATION X3................................................................................................. 9

IV.1 - RECOMMANDATIONS .................................................................................................................. 9

V - BASE DE DONNEES SQL SERVER............................................................................................ 10

V.1 - RECOMMANDATIONS ................................................................................................................. 10

VI - BASE DE DONNEES ORACLE ................................................................................................... 12

VI.1 - RECOMMANDATIONS ................................................................................................................ 12

VII - POSTE DE TRAVAIL .................................................................................................................. 14

VII.1 - PC W INDOWS ......................................................................................................................... 14

Bonnes pratiques de configuration des composants de l’architecture système Page 2 de 14

Conventions
Les idéogrammes employés dans ce document sont :

Commentaire

Mémo, Remarque, Note

Attention, Important

Voir aussi

 Action

Objectif
L’objet de ce document est de présenter un récapitulatif des bonnes pratiques et principales
recommandations techniques à mettre en place pour optimiser les performances de
fonctionnement d’une solution applicative de la gamme Sage X3 :
 X3 ERP
 X3 PEOPLE
 GEODE.
Ces recommandations et bonnes pratiques sont regroupées par élément constituant
l'architecture du système (logiciels et/ou matériels) :
 SYSTEME D’EXPLOITATION WINDOWS
 VIRTUALISATION
 SERVEURS
 BASE DE DONNEES SQL SERVER
 DOSSIERS X3
L’éditeur Sage peut vous aider à auditer l’infrastructure informatique de vos clients pour la
comparer avec les bonnes pratiques présentées dans ce document afin de mettre en évidence
des axes d’optimisation en vue d’améliorer les performances des applications Sage installées.

Bonnes pratiques de configuration des composants de l’architecture système Page 3 de 14

I - Système d’exploitation Windows
I.1 - Recommandations
Allouer 1,5x la quantité de la mémoire RAM au fichier d’échange

Mettre à jour régulièrement des Hot Fix et autres mises à jour de sécurité Windows

Bonnes pratiques de configuration des composants de l’architecture système Page 4 de 14

II - Virtualisation
II.1 - BIOS
La latence peut être introduite dans un environnement physique en raison de paramètres liés
à la gestion de l'alimentation, disponibles au niveau matériel (BIOS) et système d’exploitation.
Les paramètres liés à la gestion de l'alimentation permettent de réduire la consommation
d'énergie de différents composants, tels que la CPU, mémoire, disque et réseau ; ce qui peut
agir de façon néfaste sur les performances en raison d’une latence supplémentaire.
La latence peut être améliorée en optimisant le réglage des paramètres au niveau du serveur
hôte physique ESX et individuellement au niveau de chaque machine virtuelle (VM).
Le profil système positionné à "Maximum Performance" au niveau du BIOS de la machine
physique (ESX) permet de positionner automatiquement certains paramètres :
o L’activation de la technologie "Turbo Boost" qui permet de dépasser la fréquence
nominale tout en respectant la température des processeurs.
o La désactivation des états "C-States" qui permet de ne pas contrôler le niveau de mise
en veille des coeurs de processeur (C0 à C6) en cas d’inactivité
o La désactivation du support C1E qui empêche le processeur de basculer à un état de
performances minimales lorsqu’il est inactif
Les valeurs recommandées sont les suivantes :

Ressource Configuration Par défaut Recommandée

Intel Turbo Boost Enable Enable
CPU C-states Enable Disable
C1E Enable Disable

Exemple d’options "Power Management" applicables sur les serveurs HP ProLiant :

Ressource Configuration Par défaut

HP Power Profile Maximum Performance
POWER HP Power Regulator HP Static High
Performance Mode
Minimum Processor Idle Power Core State No C State
Minimum Processor Idle Power Package State No Package State
Energy/Performance Bias Maximum Performance
CPU
Intel QPI Link Power Management Disable
Collaborative Power Control Disable
Power Capping Support Disable
DIMM Voltage Preference Optimized Performance
Memory Power Savings Mode Maximum Performance
MEMORY
Dynamic Power Capping Functionality Disable
Memory Refresh Rate 1x

II.2 - Réseau
Pour obtenir de meilleures performances en multi-tiers, il est primordial d’utiliser des
adaptateurs réseau virtuelles de type "VMXnet3" (et non de type "E1000") sachant que
"Vmware Tools" doit être installé et à jour sur les machines virtuelles (>= 10.0).
Le réseau physique (backbone) auxquels sont reliés les systèmes hôtes ESX doit être
impérativement en 10 Gigabit.

Bonnes pratiques de configuration des composants de l’architecture système Page 5 de 14

II.3 - Hyper-Threading
S’assurer également que la technologie Hyper-Threading est bien activée au niveau BIOS
des machines physiques (ESX).
L’Hyper-Threading des processeurs s’active au niveau de(s) serveur(s) physique(s) et permet
d’améliorer les performances de calcul dans un microprocesseur en créant pour chaque cœur
du processeur physique 2 processeurs virtuels. Ce qui revient à doubler le nombre de
processeurs logiques (LCPU)

Bonnes pratiques de configuration des composants de l’architecture système Page 6 de 14

III - Serveurs et stockage
III.1 - Mises à jour
Mettre à jour régulièrement les dernières mises à jour de BIOS, pilotes, micrologiciels et
autres applications propres au modèle de vos serveurs

III.2 - Technologie SSD

Pour l’environnement de production les disques durs hébergeant l’application et la base de
données ou les machines virtuelles doivent être en full SSD cette technologie offre une
durabilité améliorée et surtout un niveau de performance bien supérieur aux disques durs
HDD.

III.3 - Taille unité d’allocation

Les partitions disques (volumes logiques) devant héberger les fichiers data et log de la base
de données SQL Server (.mdf, ndf, ldf) y compris les fichiers des bases de données systèmes
notamment tempdb , doivent être formatées avec des unités d’allocation de 64Ko (par
défaut, la taille étant généralement de 4Ko).
Cette recommandation s'applique uniquement aux volumes disques devant contenir les
fichiers de données et journaux de transactions SQL, et ne s'applique pas aux autres
partitions destinées à Windows et aux objets applicatifs Sage.
Sources Microsoft : Considérations sur la conception de SQL Server du 20/07/2018

III.4 - Taux d’occupation Disque

D’une manière générale il faut absolument éviter de dépasser un taux d’occupation de l’ordre
de 2/3 (67%) de la capacité disque. En effet, en cours d’exploitation, la base de données
évolue et occupe donc une place de plus en plus grande sur disque, plus le disque se rempli
et plus les temps d’accès sont longs. Le phénomène n’est pas linéaire, à partir de 67% le
temps de latence du disque est multiplié par 3 et à 92% il est multiplié par 10, autrement dit
il devient quasiment inexploitable.
Pour prévenir ce risque, il convient de définir 3 niveaux d’alerte dans la supervision :
 Premier niveau : taux de remplissage 65%
 Il convient de faire le ménage sur le disque
 Second niveau : taux de remplissage 70%
 Il convient de planifier l’ajout d’un disque ou le remplacement de l’existant par
un disque de plus grande capacité et aux performances accrues
 Troisième niveau : taux de remplissage > 80%
 Le remplacement de l’existant par un disque de plus grande capacité est
impératif

III.5 - Défragmentation
Lancer régulièrement les mécanismes d’optimisation et/ou de défragmentation des volumes
disques. Lors que l’exécution de ces fonctions il est recommandé d’arrêter les services de
base de données.

Bonnes pratiques de configuration des composants de l’architecture système Page 7 de 14

III.6 - Réseau
Le cœur de réseau local chargée d'établir la liaison entre les différents serveurs hébergeant
des composants Sage X3 de l'environnement de production doit être configuré avec des
Cartes réseau Ethernet de 10 Gbit/s.

Bonnes pratiques de configuration des composants de l’architecture système Page 8 de 14

IV - Dossiers et Application X3
IV.1 - Recommandations
Lors de la création des dossiers applicatifs il convient de créer un groupe de fichier de manière
à séparer les tables data des index. Ce qui en cas de nécessité par la suite permettra de
déplacer ces fichiers de données sur les partitions distincts afin d’optimiser les performances.

Installer régulièrement les dernières versions de composants technologiques (Syracuse,

MongoDB, ElasticSearch, serveur d’édition, Runtime, etc.) délivrées par l’éditeurs Sage

Intégrer régulièrement les nouvelles listes de patch applicatives

Chaque semaine nous conseillons d’épurer le contenu des tables temporaires suivantes :
o ALISTER
o AREPORTM
o ATMPTRA

Vérifier régulièrement s’il n’y a pas de défaillance d’index via la fonction prévue à cet effet
Développement> Utilitaires> Vérifications> Base de données> Recherche index et si besoin
procéder à une validation forcée des tables en défaut

Procéder aux épurations nécessaires dans les différents répertoires des serveurs Sage pour
libérer un maximum d’espace disque dans les répertoires : TRA, TMP, Logs, Temp, etc.

Supprimer les dossiers qui ne sont plus utilisés

Dédier l’environnement de production aux dossier X3 applicatifs de production. Prévoir un

second environnement hors production pour y héberger les autres dossiers de paramétrage,
formation, test, recette, etc.

Adapter le nombre de nœuds Syracuse en fonction du nombre de sessions Web ouvertes

simultanément.

Limiter au maximum l’usage de la fonction Requêteur X3 afin d’éviter les ralentissements et

blocages en cas de lancement de requêtes non optimisées et potentiellement très
consommatrices de ressources I/O. La fonction standard Requêteur X3 est destinée à des
opération de très petits volumes et non à se substituer à une sorte de 'Business
Intelligence'. Il faut savoir que cette fonction fait des INSERT très volumineux dans la table
ALISTER en effet le nombre d'enregistrements en INSERT est égal au nombre de Champs
de chaque ligne * le nombre de Lignes ramenées par la Requête. Donc cette fonction
utilisée à mauvais escient peut générer un nombre d'enregistrements très important qui
peut amener à une explosion du fichier Log.
 Seule solution : ne plus utiliser les fonctions de requêteur X3 pour un usage pour lequel
elles n’ont pas été conçues.

Surveillance des verrous des tables de la base de données. Selon les informations relevées
il conviendra dans un premier temps, de valider de manière forcée certaines tables (opération
à réaliser lorsque tous les utilisateurs sont déconnectés). Si des blocages se reproduisent, il
faudra déclarer certains index en mode cluster et si besoin abaisser le taux de remplissage
de ces index.

Bonnes pratiques de configuration des composants de l’architecture système Page 9 de 14

V - Base de données SQL Server
V.1 - Recommandations
La base Tempdb de l’instance de production doit être stockée sur une partition dédiée a son
usage et être configurée avec un nombre de fichier proportionnel au nombre de cœurs de
processeur disponibles sur la machine si le serveur est dédié à la base de données sinon il
doit correspondre à la moitié des cœurs disponibles si ce serveur héberge également
l’application X3

Adapter Les valeurs minimales et maximales de mémoire pour l’instance SQL Server en
fonction de la quantité de mémoire physique RAM présente sur le serveur et prévue pour le
moteur de base de données. Nos recommandations en la matière sont les suivantes :

a) Allouer en mémoire physique RAM pour l’instance SQL Server de production 15 à 25%
de la taille des fichiers de données (DATA+INDEX)
25% si DATA + INDEX > 30 Go
20% si DATA + INDEX > 80 Go
15% si DATA + INDEX > 150Go
b) Dimensionner la taille du Journal des Transactions de l’instance SQL Server de
production à 50% de la taille des fichiers de données (DATA+INDEX)
c) Dimensionner la taille de la base Tempdb de l’instance SQL Server de production à 25%
de la taille des fichiers de données (DATA+INDEX)

Le moteur SQL Server peut faire exécuter une requête coûteuse par plusieurs processeurs de
la machine sur laquelle il est installé, ce qui permet en principe de diminuer le temps
d'exécution de la requête. Le paramètre degré maximum de parallélisme 'max degree of
parallelism' gère ce fonctionnement. La valeur doit être comprise entre 0 et 8. La valeur à 0
(par défaut), signifie que l’on autorise SQL à exploiter tous les processeurs, ce qui peut amener
une saturation de la CPU. Pour éviter ce phénomène, nous recommandons de ne pas
dépasser la moitié du nombre de cœur

Afin de permettre à l’instance SQL Server d’avoir toujours accès directement à ses pages de
données résidante en mémoire physique, plutôt qu’en mémoire paginée dans le fichier
d’échange sur disque, l’activation du « Lock Pages In Memory » peut s’avérer bénéfique.

Activer l’option SQL "Optimiser les charges de travail ad hoc" afin de conserver le plan
d'exécution en cache uniquement pour les requêtes réexécutées et améliorer ainsi l’efficacité
du plan de cache SQL
o Pour rappel, SQL Server maintient un cache de plans d’exécution permettant à
l'optimiseur SQL de ne pas procéder à une nouvelle analyse pour déterminer le plan
d'exécution dès la deuxième exécution d'une requête SQL
o Ce principe est valable aussi bien pour les procédures stockées que pour les requêtes
"ad-hoc" c’est-à-dire celles qui sont générées dans le code de l’application avec des
valeurs littérales
o L'option "optimize for adhoc workloads" au niveau instance modifie le comportement
de SQL Server de la manière suivante : lorsqu’un plan de requête ad-hoc est calculé,
il n’est plus directement stocké dans le cache mais sous forme d'un plan compilé (stub)
qui permettra de l'identifier lors de la prochaine exécution. Si le même plan doit être
calculé une deuxième fois, il sera cette fois gardé en cache

Pour des performances optimales l’éditeur SAGE recommande que l’instance SQL Server
propriétaire des bases master et tempdb soit dans la même collation que la base de données
de l’application X3 -> Latin1_General_BIN

Assurez-vous que le journal des transactions se vide régulièrement

Bonnes pratiques de configuration des composants de l’architecture système Page 10 de 14

 Configuration de 4 plans de maintenance hebdomadaire pour l’optimisation de la base de
données :
o Vérification de l'intégrité des données
o Rebuild des index pour ceux dont le taux de fragmentation > 30%
o Réorganisation des index pour ceux dont le taux de fragmentation > 15%
o Mise à jour des statistiques

A noter : ne pas prévoir de Shrink de la base de données, c’est contre performant car on
essaie de réduire les bases dont les fichiers sont par nature en croissance automatique

Assurez-vous que les plans de maintenance d’optimisation s’exécutent régulièrement

Installer proactivement la dernière mise à jour cumulative (CUnn) du moteur de base de

données SQL Server

Bonnes pratiques de configuration des composants de l’architecture système Page 11 de 14

VI - Base de données Oracle
VI.1 - Recommandations
Répartir physiquement les fichiers de données (datafiles) de la base sur des volumes disques
(partitions ou filesystems) séparés (DATA, INDEX, REDOLOG, UNDO, TEMP, SYSTEM,
etc.)

Collecter quotidiennement manuellement les statistiques sur les tables, index et colonnes
(histogrammes) pour l’ensemble des schémas applicatifs afin de conserver des performances
optimales :
Exemple :
begin
dbms_stats.gather_schema_stats(
ownname => 'DEMO',
estimate_percent => dbms_stats.auto_sample_size,
method_opt => 'for all columns size auto',
cascade => true,
degree => 4);
end;
/

Vérifier et ajuster la taille des fichiers REDOLOG en fonction de la fréquence de rotation. La

recommandation de l’éditeur Oracle : le nombre de rotation ne doit pas excéder en moyenne
5 par heure (soit une toutes les 15 minutes)

Paramétrage, liste des principaux paramètres Oracle à positionner dans l’instance de

production :

Libellé Valeur

AUDIT_FILE_DEST /home/oracle/admin/<SID>/adump
AUDIT_TRAIL DB
DB_NAME X3PROD
INSTANCE_NAME X3PROD
COMPATIBLE (Selon la version d’X3)
DB_BLOCK_SIZE 8192
DB_FILES 50
CHARACTER_SET AL32UTF8
DIAGNOSTIC_DEST /opt/oracle
LOG_BUFFER 524288
MAX_DUMP_FILE_SIZE 10240
MEMORY_MAX_TARGET 20G (à ajuster)
MEMORY_TARGET 16G (à ajuster)
NBR_SORT BINARY
OPTIMIZER_INDEX_CACHING 0
OPTIMIZER_INDEX_COST_ADJ 100
OPTIMIZER_MODE
ALL_ROWS
(first_rows_n[1,10,100 ou 1000]/ first_rows/all_rows)
OPEN_CURSORS (nombre curseurs) 300
PGA_AGGREGATE_LIMIT 5G

Bonnes pratiques de configuration des composants de l’architecture système Page 12 de 14

 PROCESSES 1000
SESSIONS 600
RECYCLEBIN OFF
REMOTE_LOGIN_PASSWORDFILE EXCLUSIVE
SEC_CASE_SENSITIVE_LOGON FALSE
UNDO_MANAGEMENT AUTO
UNDO_RETENTION 10800
UNDO_TABLESPACE UNDOTBS1

Adapter Les valeurs minimales et maximales de mémoire pour l’instance ORACLE

(MEMORY_MAX_TARGET et MEMORY_TARGET) en fonction de la quantité de mémoire
physique RAM disponible du serveur et prévue pour le moteur de base de données

Bonnes pratiques de configuration des composants de l’architecture système Page 13 de 14

VII - Poste de travail
VII.1 - PC Windows
Vérifier que le browser web utilisé par les utilisateurs finaux soit bien celui préconisé par votre
organisation et qu’il soit à jour de la dernière version disponible (Google Chrome V79)

Bonnes pratiques de configuration des composants de l’architecture système Page 14 de 14