forked from gleu/pgdocs_fr
-
Notifications
You must be signed in to change notification settings - Fork 0
/
runtime.xml
1888 lines (1676 loc) · 84.9 KB
/
runtime.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<chapter id="runtime">
<title>Configuration du serveur et mise en place</title>
<para>
Ce chapitre discute de la configuration, du lancement du serveur de bases de
données et de ses interactions avec le système d'exploitation.
</para>
<sect1 id="postgres-user">
<title>Compte utilisateur <productname>PostgreSQL</productname></title>
<indexterm>
<primary>utilisateur postgres</primary>
</indexterm>
<para>
Comme avec tout autre démon serveur accessible au monde externe, il est
conseillé de lancer <productname>PostgreSQL</productname> sous un compte
utilisateur séparé. Ce compte devrait seulement être le propriétaire des
données gérées par le serveur et ne devrait pas être partagé avec d'autres
démons (par exemple, utiliser l'utilisateur <literal>nobody</literal> est
une mauvaise idée). Il n'est pas conseillé de changer le propriétaire des
exécutables par cet utilisateur car les systèmes compromis pourraient alors
se voir modifier leur propres binaires.
</para>
<para>
Pour ajouter un compte utilisateur Unix, jetez un œil à la commande
<command>useradd</command> ou <command>adduser</command> de votre système.
Le nom de l'utilisateur <systemitem>postgres</systemitem> est souvent utilisé
et l'est sur tout le livre, mais vous pouvez utiliser un autre nom si vous le
souhaitez.
</para>
</sect1>
<sect1 id="creating-cluster">
<title>Créer un groupe de base de données</title>
<indexterm>
<primary>groupe de bases de données</primary>
</indexterm>
<indexterm>
<primary>emplacement des données</primary>
<see>groupe de bases de données</see>
</indexterm>
<para>
Avant de faire quoi que ce soit, vous devez initialiser un emplacement de
stockage pour la base de données. Nous appelons ceci un <firstterm>groupe de
bases de données</firstterm> (<acronym>sql</acronym> utilise
le terme de groupe de catalogues). Un groupe de bases de données est une
collection de bases données et est géré par une seule instance d'un
serveur de bases de données en cours d'exécution. Après initialisation, un
groupe de bases de données contiendra une base de données nommée
<literal>postgres</literal>, qui a pour but d'être la base de données par
défaut utilisée par les outils, les utilisateurs et les applications
tiers. Le serveur de la base de données lui-même ne requiert pas la présence
de la base de données <literal>postgres</literal> mais beaucoup d'outils
supposent son existence. Une autre base de données est créée à l'intérieur
de chaque groupe lors de l'initialisation. Elle est appelée
<literal>template1</literal>. Comme le nom le suggère, elle sera utilisée
comme modèle pour les bases de données créées après ; elle ne devrait
pas être utilisée pour un vrai travail (voir le <xref
linkend="managing-databases"/> pour des informations sur la création de
nouvelles bases de données dans le groupe).
</para>
<para>
En terme de système de fichiers, un groupe de bases de données sera un
simple répertoire sous lequel les données seront stockées. Nous l'appelons le
<firstterm>répertoire de données</firstterm> ou l'<firstterm>emplacement des
données</firstterm>. Le choix de cet emplacement vous appartient complètement.
Il n'existe pas de valeur par défaut bien que les emplacements tels que
<filename>/usr/local/pgsql/data</filename> ou
<filename>/var/lib/pgsql/data</filename> sont populaires. Pour initialiser un
groupe de bases de données, utilisez la commande <xref
linkend="app-initdb"/>,<indexterm><primary>initdb</primary></indexterm> installée avec
<productname>PostgreSQL</productname>. L'emplacement désiré sur le groupe de
fichier est indiqué par l'option <option>-d</option>, par exemple
<screen><prompt>$</prompt> <userinput>initdb -d /usr/local/pgsql/data</userinput></screen>
Notez que vous devez exécuter cette commande en étant connecté sous le compte
de l'utilisateur <productname>PostgreSQL</productname> décrit dans la section
précédente.
</para>
<tip>
<para>
Comme alternative à l'option <option>-d</option>, vous pouvez initialiser
la variable d'environnement <envar>pgdata</envar>.
<indexterm><primary><envar>pgdata</envar></primary></indexterm>
</para>
</tip>
<para>
<command>initdb</command> tentera de créer le répertoire que vous avez
spécifié si celui-ci n'existe pas déjà. Il est possible qu'il n'ait pas le
droit de le faire (si vous avez suivi notre conseil et créé un compte sans
droits). Dans ce cas, vous devez créer le répertoire vous-même (en tant que
root) et modifier le propriétaire pour qu'il corresponde à l'utilisateur
<productname>PostgreSQL</productname>. Voici comment réaliser ceci :
<screen>root# <userinput>mkdir /usr/local/pgsql/data</userinput>
root# <userinput>chown postgres /usr/local/pgsql/data</userinput>
root# <userinput>su postgres</userinput>
postgres$ <userinput>initdb -d /usr/local/pgsql/data</userinput></screen>
</para>
<para>
<command>initdb</command> refusera de s'exécuter si le répertoire des données
semble être déjà initialisé.</para>
<para>
Comme le répertoire des données contient toutes les données stockées par
le système de bases de données, il est essentiel qu'il soit sécurisé par
rapport à des accès non autorisés. Du coup, <command>initdb</command>
supprimera les droits d'accès à tout le monde sauf l'utilisateur
<productname>PostgreSQL</productname>.
</para>
<para>
Néanmoins, bien que le contenu du répertoire soit sécurisé, la configuration
d'authentification du client par défaut permet à tout utilisateur local de se
connecter à la base de données et même à devenir le super-utilisateur de
la base de données. Si vous ne faites pas confiance aux utilisateurs
locaux, nous vous recommandons d'utiliser une des options <option>-w</option> ou
<option>--pwprompt</option> de la commande <command>initdb</command> pour
affecter un mot de passe au super-utilisateur de la base de
données <indexterm><primary>mot de passe</primary><secondary>du
super-utilisateur</secondary></indexterm>. De plus, spécifiez <option>-a md5</option> ou
<option>-a mot_de_passe</option> de façon à ce que la méthode d'authentification
<literal>trust</literal> par défaut ne soit pas utilisée ; ou modifiez le fichier
<filename>pg_hba.conf</filename> généré après l'exécution
d'<command>initdb</command> (d'autres
approches raisonnables incluent l'utilisation de l'authentification
<literal>ident</literal> ou les droits du système de fichiers pour
restreindre les connexions. Voir le <xref
linkend="client-authentication"/> pour plus d'informations).
</para>
<para>
<command>initdb</command> initialise aussi la
locale<indexterm><primary>locale</primary></indexterm> par défaut du groupe de bases de
données. Normalement, elle prends seulement le paramétrage local dans
l'environnement et l'applique à la base de données initialisée. Il est
possible de spécifier une locale différente pour la base de données ;
la <xref linkend="locale"/> propose plus d'informations là-dessus.
L'ordre de tri utilisé par défaut pour ce cluster de bases de données est
initialisé par <command>initdb</command> et, bien que vous pouvez créer de
nouvelles bases de données en utilisant des ordres de tris différents, l'ordre
utilisé dans les bases de données modèle que initdb a créé ne peut pas être
modifié sans les supprimer et les re-créer. Cela a aussi un impact sur les
performances pour l'utilisation de locales autres que <literal>c</literal>
ou <literal>posix</literal>. Du coup, il est important de faire ce choix
correctement la première fois.
</para>
<para>
<command>initdb</command> configure aussi le codage par défaut de l'ensemble
de caractères pour le groupe de bases de données. Normalement, cela doit
être choisi pour correspondre au paramétrage de la locale. Pour les détails,
voir la <xref linkend="multibyte"/>.
</para>
<sect2 id="creating-cluster-nfs">
<title>Systèmes de fichiers réseaux</title>
<indexterm zone="creating-cluster-nfs">
<primary>Systèmes de fichiers réseaux</primary>
</indexterm>
<indexterm><primary><acronym>NFS</acronym></primary><see>Systèmes de fichiers réseaux</see></indexterm>
<indexterm><primary>Network Attached Storage (<acronym>NAS</acronym>)</primary><see>Systèmes de fichiers réseaux</see></indexterm>
<para>
Beaucoup d'installations créent les clusters de bases de données sur des
systèmes de fichiers réseau. Parfois, cela utilise directement par
<acronym>NFS</acronym>. Cela peut aussi passer par un <acronym>NAS</acronym>
(acronyme de <foreignphrase>Network Attached Storage</foreignphrase>),
périphérique qui utilise <acronym>NFS</acronym> en interne.
<productname>PostgreSQL</productname> ne fait rien de particulier avec les
systèmes de fichiers <acronym>NFS</acronym>, ceci signifiant que
<productname>PostgreSQL</productname> suppose que
<acronym>NFS</acronym> se comporte exactement comme les lecteurs connectés
en local (<acronym>DAS</acronym>, acronyme de <foreignphrase>Direct
Attached Storage</foreignphrase>). Si les implémentations du client et du
serveur <acronym>NFS</acronym> ont une sémantique non standard,
cela peut poser des problèmes de fiabilité (voir <ulink
url="http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html"></ulink>).
En particulier, des écritures asynchrones (décalées dans le temps) sur le
serveur <acronym>NFS</acronym> peuvent poser des soucis de fiabilité. Si
possible, montez les systèmes de fichiers <acronym>NFS</acronym> en
synchrone (autrement dit sans cache) pour éviter cela. De même, le montage
<acronym>NFS</acronym> n'est pas recommandé. Les <acronym>SAN</acronym>
utilisent un protocole de communication bas-niveau plutôt que
<acronym>NFS</acronym>.
</para>
</sect2>
</sect1>
<sect1 id="server-start">
<title>Lancer le serveur de bases de données</title>
<para>
Avant qu'une personne ait accès à la base de données, vous devez démarrer le
serveur de bases de données. Le programme serveur est appelé
<command>postgres</command><indexterm><primary>postgres</primary></indexterm>. Le
programme <command>postgres</command> doit savoir où trouver les données qu'il est
supposé utiliser. Ceci se fait avec l'option <option>-d</option>. Du coup, la
façon la plus simple de lancer le serveur est :
<screen>$ <userinput>postgres -d /usr/local/pgsql/data</userinput></screen>
qui laissera le serveur s'exécuter en avant plan. Pour cela, vous devez être
connecté en utilisant le compte de l'utilisateur
<productname>PostgreSQL</productname>. Sans l'option <option>-d</option>, le serveur
essaiera d'utiliser le répertoire de données nommé par la variable
d'environnement <envar>pgdata</envar>. Si cette variable ne le fournit pas
non plus, le lancement échouera.
</para>
<para>
Habituellement, il est préférable de lancer <command>postgres</command> en tâche
de fond. Pour cela, utilisez la syntaxe shell habituelle :
<screen>$ <userinput>postgres -d /usr/local/pgsql/data >journaux_trace 2>&1 &</userinput></screen>
Il est important de sauvegarder les sorties <systemitem>stdout</systemitem> et
<systemitem>stderr</systemitem> du serveur quelque part, comme montré ci-dessus. Cela
vous aidera dans des buts d'audits ou pour diagnostiquer des problèmes (voir
la <xref linkend="logfile-maintenance"/> pour une discussion plus détaillée
de la gestion de journaux de trace).
</para>
<para>
Le programme <command>postgres</command> prend aussi un certain nombre d'autres
options en ligne de commande. Pour plus d'informations, voir la page de
référence <xref linkend="app-postmaster"/> ainsi que le <xref
linkend="runtime-config"/> ci-dessous.
</para>
<para>
Cette syntaxe shell peut rapidement devenir ennuyante. Donc, le programme
d'emballage <xref linkend="app-pg-ctl"/><indexterm><primary>pg_ctl</primary></indexterm>
est fourni pour simplifier certaines tâches. Par exemple :
<programlisting>pg_ctl start -l journaux_trace</programlisting>
lancera le serveur en tâche de fond et placera les sorties dans le journal
de trace indiqué. L'option <option>-d</option> a la même signification ici
que pour <command>postgres</command>. <command>pg_ctl</command> est aussi
capable d'arrêter le serveur.
</para>
<para>
Normalement, vous lancerez le serveur de bases de données lors du
démarrage de l'ordinateur <indexterm><primary>démarrage</primary><secondary>au
lancement du serveur</secondary></indexterm>. Les scripts de lancement automatique sont
spécifiques au système d'exploitation. Certains sont distribués avec
<productname>PostgreSQL</productname> dans le répertoire
<filename>contrib/start-scripts</filename>. En installer un demandera les
droits de root.
</para>
<para>
Différents systèmes ont différentes conventions pour lancer les démons au
démarrage. La plupart des systèmes ont un fichier
<filename>/etc/rc.local</filename> ou
<filename>/etc/rc.d/rc.local</filename>. D'autres utilisent les répertoires
<filename>rc.d</filename>. Quoi que vous fassiez, le serveur doit être exécuté par le
compte utilisateur <productname>PostgreSQL</productname> <emphasis>et non pas
par root</emphasis> ou tout autre utilisateur. Donc, vous devriez
probablement former vos commandes en utilisant <literal>su postgres -c '...' </literal>.
Par exemple :
<programlisting>su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'</programlisting>
</para>
<para>
Voici quelques suggestions supplémentaires par système d'exploitation
(dans chaque cas, assurez-vous d'utiliser le bon répertoire d'installation et
le bon nom de l'utilisateur où nous montrons des valeurs génériques).
<itemizedlist>
<listitem>
<para>
Pour <productname>freebsd</productname>, regardez le fichier
<filename>contrib/start-scripts/freebsd</filename> du répertoire des
sources de <productname>PostgreSQL</productname>.
<indexterm><primary>freebsd</primary><secondary>script de
lancement</secondary></indexterm>
</para>
</listitem>
<listitem>
<para>
Sur <productname>openbsd</productname>, ajoutez les lignes suivantes à
votre fichier <filename>/etc/rc.local</filename> :
<indexterm><primary>openbsd</primary><secondary>script de
lancement</secondary></indexterm>
<programlisting>if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data'
echo -n ' PostgreSQL'
fi</programlisting>
</para>
</listitem>
<listitem>
<para>
Sur les systèmes <productname>linux</productname>, soit vous ajoutez
<indexterm><primary>linux</primary><secondary>script de lancement</secondary></indexterm>
<programlisting>/usr/local/pgsql/bin/pg_ctl start -l journaux_trace -D /usr/local/pgsql/data</programlisting>
à <filename>/etc/rc.d/rc.local</filename> soit vous jetez un œil à
<filename>contrib/start-scripts/linux</filename> dans le répertoire des
sources de <productname>PostgreSQL</productname>.
</para>
</listitem>
<listitem>
<para>
Sur <productname>netbsd</productname>, vous pouvez utiliser les scripts
de lancement de <productname>freebsd</productname> ou de
<productname>linux</productname> suivant vos préférences.
<indexterm><primary>netbsd</primary><secondary>script de lancement</secondary></indexterm>
</para>
</listitem>
<listitem>
<para>
Sur <productname>solaris</productname>, créez un fichier appelé
<filename>/etc/init.d/PostgreSQL</filename> et contenant la ligne
suivante :
<indexterm><primary>solaris</primary><secondary>script de
lancement</secondary></indexterm>
<programlisting>su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l journaux_trace -D /usr/local/pgsql/data"</programlisting>
Puis, créez un lien symbolique vers lui dans <filename>/etc/rc3.d</filename> de
nom <filename>s99PostgreSQL</filename>.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Tant que le serveur est lancé, son
<acronym>pid</acronym> est stocké dans le fichier
<filename>postmaster.pid</filename> du répertoire de données. C'est utilisé
pour empêcher plusieurs instances du serveur d'être exécutées dans le même
répertoire de données et peut aussi être utilisé pour arrêter le processus
le serveur.
</para>
<sect2 id="server-start-failures">
<title>Échecs de lancement</title>
<para>
Il existe de nombreuses raisons habituelles pour lesquelles le serveur
échouerait au lancement. Vérifiez le journal des traces du serveur ou
lancez-le manuellement (sans redirection des sorties standard et d'erreur)
et regardez les messages d'erreurs qui apparaissent. Nous en expliquons
certains ci-dessous parmi les messages d'erreurs les plus communs.
</para>
<para>
<screen>LOG: could not bind IPv4 socket: Address already in use
HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL: could not create TCP/IP listen socket</screen>
Ceci signifie seulement ce que cela suggère : vous avez essayé de lancer
un autre serveur sur le même port où un autre est en
cours d'exécution. Néanmoins, si le message d'erreur du noyau
n'est pas <computeroutput>address already in use</computeroutput> ou une
quelconque variante, il pourrait y avoir un autre problème. Par
exemple, essayer de lancer un serveur sur un numéro
de port réservé pourrait avoir ce résultat :
<screen>$ <userinput>postgres -p 666</userinput>
LOG: could not bind IPv4 socket: Permission denied
HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL: could not create TCP/IP listen socket</screen>
</para>
<para>
Un message du type
<screen>FATAL: could not create shared memory segment: Invalid argument
DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).</screen>
signifie probablement que les limites de votre noyau sur la taille de
la mémoire partagée est plus petite que l'aire de fonctionnement que
<productname>PostgreSQL</productname> essaie de créer (4011376640 octets
dans cet exemple). Ou il pourrait signifier que vous n'avez pas du tout
configuré le support de la mémoire partagée de type System-V dans votre
noyau. Comme contournement temporaire, vous pouvez essayer de lancer le
serveur avec un nombre de tampons plus petit que la normale
(<xref linkend="guc-shared-buffers"/>). Éventuellement, vous pouvez
reconfigurer votre noyau pour accroître la taille de mémoire partagée
autorisée. Vous pourriez voir aussi ce message en essayant d'exécuter
plusieurs serveurs sur la même machine si le total de l'espace qu'ils
requièrent dépasse la limite du noyau.
</para>
<para>
Une erreur du type
<screen>FATAL: could not create semaphores: No space left on device
DETAIL: Failed system call was semget(5440126, 17, 03600).</screen>
ne signifie <emphasis>pas</emphasis> qu'il vous manque de l'espace disque.
Elle signifie que la limite de votre noyau sur le nombre de sémaphores
<systemitem class="osname">system v</systemitem> est inférieure au nombre que
<productname>PostgreSQL</productname> veut créer. Comme ci-dessus, vous
pouvez contourner le problème en lançant le serveur avec un nombre
réduit de connexions autorisées (<xref linkend="guc-max-connections"/>)
mais vous voudrez éventuellement augmenter la limite du noyau.
</para>
<para>
Si vous obtenez une erreur <quote>illegal system call</quote>, il est probable
que la mémoire partagée ou les sémaphores ne sont pas du tout supportés par
votre noyau. Dans ce cas, votre seule option est de reconfigurer le noyau
pour activer ces fonctionnalités.
</para>
<para>
Des détails sur la configuration des capacités <acronym>ipc</acronym> <systemitem
class="osname">System V</systemitem> sont donnés dans la <xref linkend="sysvipc"/>.
</para>
</sect2>
<sect2 id="client-connection-problems">
<title>Problèmes de connexion du client</title>
<para>
Bien que les conditions d'erreurs possibles du côté client sont assez
variées et dépendantes de l'application, certaines pourraient être en
relation direct avec la façon dont le serveur a été lancé. Les conditions
autres que celles montrées ici devraient être documentées avec
l'application client respective.
</para>
<para>
<screen>psql: could not connect to server: Connection refused
Is the server running on host "server.joe.com" and accepting
TCP/IP connections on port 5432?</screen>
Ceci est l'échec générique <quote>je n'ai pas trouvé de serveur à qui
parler</quote>. Cela ressemble au message ci-dessus lorsqu'une connexion
TCP/IP est tentée. Une erreur commune est d'oublier de configurer le
serveur pour qu'il autorise les connexions TCP/IP.
</para>
<para>
Autrement, vous obtiendrez ceci en essayant une communication de type
socket de domaine Unix vers un serveur local :
<screen>psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?</screen>
</para>
<para>
La dernière ligne est utile pour vérifier si le client essaie de se
connecter au bon endroit. Si aucun serveur n'est exécuté ici, le
message d'erreur du noyau sera typiquement soit <computeroutput>connection
refused</computeroutput> soit <computeroutput>no such file or
directory</computeroutput>, comme ce qui est illustré (il est important de
réaliser que <computeroutput>connection refused</computeroutput>, dans ce
contexte, ne signifie <emphasis>pas</emphasis> que le serveur a obtenu une
demande de connexion et l'a refusé. Ce cas produira un message différent
comme indiqué dans la <xref linkend="client-authentication-problems"/>).
D'autres messages d'erreurs tel que <computeroutput>connection timed
out</computeroutput> pourraient indiquer des problèmes plus fondamentaux
comme un manque de connexion réseau.
</para>
</sect2>
</sect1>
<sect1 id="kernel-resources">
<title>Gérer les ressources du noyau</title>
<para>
Une installation importante de <productname>PostgreSQL</productname> peut rapidement
épuiser les limites des ressources du système d'exploitation (Sur certains
systèmes, les valeurs par défaut sont trop basses que vous n'avez même pas
besoin d'une installation <quote>importante</quote>.). Si vous avez rencontré ce
type de problème, continuez votre lecture.
</para>
<sect2 id="sysvipc">
<title>Mémoire partagée et sémaphore</title>
<indexterm zone="sysvipc">
<primary>mémoire partagée</primary>
</indexterm>
<indexterm zone="sysvipc">
<primary>sémaphores</primary>
</indexterm>
<para>
La mémoire partagée et les sémaphores sont nommés collectivement
<quote><acronym>ipc</acronym> <systemitem class="osname">system v</systemitem></quote>
(ensemble avec les queues de messages, qui n'ont pas d'importance pour
<productname>PostgreSQL</productname>). Pratiquement, tous les systèmes d'exploitation
modernes fournissent ces fonctionnalités mais, parmi elles, toutes ne sont pas
activées ou dimensionnées suffisamment par défaut, spécialement les systèmes
ayant l'héritage BSD (Sur <systemitem class="osname">windows</systemitem>,
<productname>PostgreSQL</productname> fournit sa
propre implémentation de remplacement de ces fonctionnalités, du coup, ce qui suit peut être ignoré).
</para>
<para>
Le manque complet de fonctionnalités est généralement manifesté par
une erreur <errorname>illegal system call</errorname> au lancement du serveur. Dans
ce cas, il n'y a rien à faire à part reconfigurer votre noyau.
<productname>PostgreSQL</productname> ne fonctionnera pas sans.
</para>
<para>
Quand <productname>PostgreSQL</productname> dépasse une des nombreuses limites
<acronym>ipc</acronym>, le serveur refusera de s'exécuter et lèvera un
message d'erreur instructif décrivant le problème rencontré et que faire
avec (voir aussi la <xref linkend="server-start-failures"/>). Les
paramètres adéquats du noyau sont nommés de façon cohérente parmi les
différents systèmes ; le <xref linkend="sysvipc-parameters"/> donne un
aperçu. Néanmoins, les méthodes pour les obtenir varient. Les suggestions
pour quelques plateformes sont données ci-dessous. Attention, il est souvent
nécessaire de redémarrer votre machine, voire même de recompiler le noyau,
pour changer ces paramétrages.
</para>
<table id="sysvipc-parameters">
<title>Paramètres <systemitem class="osname">system v</systemitem> <acronym>ipc</acronym></title>
<tgroup cols="3">
<colspec colnum="1" colwidth="0.3*"/>
<colspec colnum="2" colwidth="1.5*"/>
<colspec colnum="3" colwidth="1.2*"/>
<thead>
<row>
<entry>Nom</entry>
<entry>Description</entry>
<entry>Valeurs raisonnables</entry>
</row>
</thead>
<tbody>
<row>
<entry><varname>shmmax</varname></entry>
<entry>taille maximum du segment de mémoire partagée (octets)</entry>
<entry>au moins plusieurs mo (voir texte)</entry>
</row>
<row>
<entry><varname>shmmin</varname></entry>
<entry>taille minimum du segment de mémoire partagée (octets)</entry>
<entry>1</entry>
</row>
<row>
<entry><varname>shmall</varname></entry>
<entry>total de la mémoire partagée disponible (octets ou pages)</entry>
<entry>si octets, identique à <varname>shmmax</varname> ; si pages,
<literal>ceil(shmmax/page_size)</literal></entry>
</row>
<row>
<entry><varname>shmseg</varname></entry>
<entry>nombre maximum de segments de mémoire partagée par
processus</entry>
<entry>seul un segment est nécessaire mais la valeur par défaut est
bien plus importante</entry>
</row>
<row>
<entry><varname>shmmni</varname></entry>
<entry>nombre maximum de segments de mémoire partagée pour
tout le système</entry>
<entry>comme <varname>shmseg</varname> plus la place pour les autres
applications</entry>
</row>
<row>
<entry><varname>semmni</varname></entry>
<entry>nombre maximum d'identifiants de sémaphores (c'est-à-dire
d'ensembles)</entry>
<entry>au moins <literal>ceil((max_connections + autovacuum_max_workers) / 16)</literal></entry>
</row>
<row>
<entry><varname>semmns</varname></entry>
<entry>nombre maximum de sémaphores répartis dans le système</entry>
<entry><literal>ceil((max_connections + autovacuum_max_workers) / 16) * 17</literal> plus la place
pour les autres applications</entry>
</row>
<row>
<entry><varname>semmsl</varname></entry>
<entry>nombre maximum de sémaphores par ensemble</entry>
<entry>au moins 17</entry>
</row>
<row>
<entry><varname>semmap</varname></entry>
<entry>nombre d'entrées dans la carte des sémaphores</entry>
<entry>voir le texte</entry>
</row>
<row>
<entry><varname>semvmx</varname></entry>
<entry>valeur maximum d'un sémaphore</entry>
<entry>au moins 1000 (vaut souvent par défaut 32767, ne pas changer
sauf si vous êtes forcé.)</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
<indexterm><primary>shmmax</primary></indexterm> le paramètre de mémoire
partagé le plus important est <varname>shmmax</varname>, la taille maximum, en
octets, d'un segment de mémoire partagée. Si vous obtenez un message
d'erreur à partir de <function>shmget</function> comme <errorname>invalid
argument</errorname>, il est possible que cette limite soit dépassée.
La taille du segment de mémoire partagée requis dépend de plusieurs
paramètres de configuration de <productname>PostgreSQL</productname>, comme indiqué
dans le <xref linkend="shared-memory-parameters"/> (tout message
d'erreur obtenu incluera la taille exacte utilisée dans la requête
d'allocation qui a échoué). Temporairement, vous pouvez
baisser certains de ces paramètres pour éviter un échec. Alors qu'il est possible d'obtenir de
<productname>PostgreSQL</productname> qu'il fonctionne avec un <varname>shmmax</varname>
de 2 Mo, vous avez besoin de bien plus pour obtenir
des performances acceptables. Les paramètrages désirables sont plutôt de
l'ordre de dizaines voire de centaines de Mo.
</para>
<para>
Certains systèmes ont aussi une limite sur le nombre total de mémoire partagée
dans le système (<varname>shmall</varname>). Assurez-vous que cela soit suffisamment
important pour <productname>PostgreSQL</productname> et quelque autres applications
utilisant des segments de mémoire partagée (attention :
<varname>shmall</varname> est mesuré en pages plutôt qu'en octets sur beaucoup de
systèmes).
</para>
<para>
La taille minimum des segments de mémoire partagée (<varname>shmmin</varname>) est
moins sensible aux problèmes. Elle devrait être au plus à environ
500 Ko pour <productname>PostgreSQL</productname> (il est habituellement à 1). Le
nombre maximum de segments au travers du système (<varname>shmmni</varname>) ou par
processus (<varname>shmseg</varname>) a peu de chances de causer un problème sauf
s'ils sont configurés à zéro sur votre système.
</para>
<para>
<productname>PostgreSQL</productname> utilise un sémaphore par connexion
autorisée (<xref linkend="guc-max-connections"/>) et par processus
autovacuum autorisé (<xref linkend="guc-autovacuum-max-workers"/>), le
tout par ensemble de 16. Chacun de ces
ensembles contiendra aussi un 17è sémaphore qui contient un <quote>nombre
magique</quote> pour détecter la collision avec des ensembles de sémaphore
utilisés par les autres applications. Le nombre maximum de sémaphores dans le
système est initialisé par <varname>semmns</varname>, qui en conséquence doit être
au moins aussi haut que <varname>max_connections</varname> plus
<varname>autovacuum_max_workers</varname> plus un extra de chacune
des 16 connexions autorisées et des processus autovacuum (voir la formule dans le <xref
linkend="sysvipc-parameters"/>). Le paramètre <varname>semmni</varname> détermine la
limite sur le nombre d'ensembles de sémaphores qui peuvent exister sur le
système à un instant précis. Donc, ce paramètre doit être au moins égal à
<literal>ceil((max_connections + autovacuum_max_workers) / 16)</literal>. Baisser le nombre de connexions
autorisées est un contournement temporaire pour les échecs qui sont
habituellement indiqués par le message <errorname>no space left on
device</errorname>, à partir de la fonction <function>semget</function>.
</para>
<para>
Dans certains cas, il pourrait être nécessaire d'augmenter
<varname>semmap</varname> pour être au moins dans l'ordre de <varname>semmns</varname>. Ce
paramètre définit la taille de la carte de ressources de sémaphores, dans
laquelle chaque bloc contigü de sémaphores disponibles ont besoin d'une
entrée. Lorsqu'un ensemble de sémaphores est libéré ou qu'il est enregistré
sous une nouvelle entrée de carte. Si la carte est pleine, les sémaphores
libérés sont perdus (jusqu'au redémarrage). La fragmentation de l'espace
des sémaphores pourrait amener dans le temps à moins de sémaphores
disponibles.
</para>
<para>
La paramètre <varname>semmsl</varname>, qui détermine le nombre de sémaphores dans
un ensemble, pourrait valoir au moins 17 pour <productname>PostgreSQL</productname>.
</para>
<para>
D'autres paramètres en relation avec l'<quote>annulation de sémaphores</quote>,
tels que <varname>semmnu</varname> et <varname>semume</varname>, ne concernent pas
<productname>PostgreSQL</productname>.
</para>
<variablelist>
<varlistentry>
<term><systemitem class="osname">AIX</systemitem></term>
<listitem>
<indexterm><primary>AIX</primary><secondary>configuration IPC</secondary></indexterm>
<para>
À partir de la version 5.1, il ne doit plus être nécessaire de faire
une configuration spéciale pour les paramètres tels que
<varname>SHMMAX</varname>, car c'est configuré de façon à ce que toute
la mémoire puisse être utilisée en tant que mémoire partagée.
C'est le type de configuration habituellement utilisée pour d'autres
bases de données comme <application>DB/2</application>.</para>
<para>
Néanmoins, il pourrait être nécessaire de modifier l'information
globale <command>ulimit</command> dans
<filename>/etc/security/limits</filename> car les limites en dur par
défaut pour les tailles de fichiers (<varname>fsize</varname>) et
les nombres de fichiers (<varname>nofiles</varname>) pourraient être
trop bas.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="osname">bsd/os</systemitem></term>
<listitem>
<indexterm><primary>bsd/os</primary><secondary>configuration ipc</secondary></indexterm>
<formalpara>
<title>Mémoire partagée</title>
<para>
Par défaut, seulement 4 Mo de mémoire partagée est supportée.
Gardez en tête que la mémoire partagée n'est pas paginable ; elle
est verrouillée en RAM. Pour accroître la mémoire partagée supportée
par votre système, ajoutez ce qui suit à la configuration de votre
noyau. Une valeur de 1024 pour <varname>shmall</varname> représente 4 mo
de mémoire partagée. Pour argumenter la mémoire partagée supportée par
votre système, ajoutez quelque chose comme ceci à votre configuration
du noyau :
<programlisting>options "SHMALL=8192"
options "SHMMAX=\(SHMALL*PAGE_SIZE\)"</programlisting>
<varname>shmall</varname> est mesuré en pages de 4 Ko, donc une valeur
de 1024 représente 4 Mo de mémoire partagée. Du coup, la
configuration ci-dessus augmente l'aire de mémoire partagée à 32 Mo.
Pour ceux utilisant une version 4.3 ou ultérieure, vous aurez
probablement besoin d'augmenter <varname>kernel_virtual_mb</varname> au-dessus
de la valeur par défaut, <literal>248</literal>. Une fois tous les changements
effectués, recompilez le noyau et redémarrez.
</para>
</formalpara>
<para>
Pour ceux utilisant une version 4.0 ou antérieures, utilisez
<command>bpatch</command> pour connaître la valeur <varname>sysptsize</varname> dans
le noyau actuel. Elle est calculée dynamiquement au démarrage.
<screen>$ <userinput>bpatch -r sysptsize</userinput>
<computeroutput>0x9 = 9</computeroutput></screen>
Ensuite, ajoutez <varname>sysptsize</varname> comme valeur codée en dur dans
le fichier de configuration du noyau. Augmentez la valeur que vous
trouvez en utilisant <command>bpatch</command>. Ajoutez 1 pour chaque
4 Mo supplémentaire de mémoire partagée que vous souhaitez.
<programlisting>options "SYSPTSIZE=16"</programlisting>
<varname>sysptsize</varname> ne peut pas être modifié
avec <command>sysctl</command>.
</para>
<formalpara>
<title>Sémaphores</title>
<para>
Vous voudrez probablement aussi augmenter le nombre de sémaphores ;
la somme totale par défaut du système (60) n'autorisera seulement que
50 connexions <productname>PostgreSQL</productname>. Initialisez les
valeurs que vous souhaitez dans le fichier de configuration du
noyau :
<programlisting>options "SEMMNI=40"
options "SEMMNS=240"</programlisting>
</para>
</formalpara>
</listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="osname">freebsd</systemitem></term>
<listitem>
<indexterm><primary>freebsd</primary><secondary>configuration ipc</secondary></indexterm>
<para>
Les paramètres par défaut sont seulement acceptables pour de petites
installations (par exemple, la valeur par défaut de
<varname>shmmax</varname> est de 32 mo). Les modifications se font
via les interfaces <command>sysctl</command> ou
<command>loader</command>. Les paramètres suivants peuvent être configurés
en utilisant <command>sysctl</command> :
<screen><prompt>$</prompt> <userinput>sysctl -w kern.ipc.shmall=32768</userinput>
<prompt>$</prompt> <userinput>sysctl -w kern.ipc.shmmax=134217728</userinput>
<prompt>$</prompt> <userinput>sysctl -w kern.ipc.semmap=256</userinput></screen>
Pour que ces paramètres persistent après les redémarrages, modifiez
<filename>/etc/sysctl.conf</filename>.
</para>
<para>
Les paramètres restant, concernant les sémaphores, sont en lecture seule
en ce qui concerne <command>sysctl</command> mais peuvent être modifiés
avant le redémarrage en utilisant l'invite <command>loader</command> :
<screen><prompt>(loader)</prompt> <userinput>set kern.ipc.semmni=256</userinput>
<prompt>(loader)</prompt> <userinput>set kern.ipc.semmns=512</userinput>
<prompt>(loader)</prompt> <userinput>set kern.ipc.semmnu=256</userinput></screen>
De façon similaire, ils peuvent être sauvegardés entre les redémarrages
dans <filename>/boot/loader.conf</filename>.
</para>
<para>
Vous pourriez aussi vouloir configurer votre noyau pour verrouiller la
mémoire partagée en RAM et l'empêcher d'être envoyé dans la swap. Ceci
s'accomplit en utilisant le paramètre
<literal>kern.ipc.shm_use_phys</literal> de <command>sysctl</command>.
</para>
<para>
En cas d'exécution dans une cage FreeBSD en activant
<literal>security.jail.sysvipc_allowed</literal> de <application>sysctl</application>,
les <application>postmaster</application> exécutés dans différentes cages
devront être exécutés par différents utilisateurs du système d'exploitation.
Ceci améliore la sécurité car cela empêche les utilisateurs non root
d'interférer avec la mémoire partagée ou les sémaphores d'une cage
différente et cela permet au code de nettoyage des IPC PostgreSQL de
fonctionner correctement (dans FreeBSD 6.0 et ultérieurs, le code de
nettoyage IPC ne détecte pas proprement les processus des autres
cages, empêchant les postmaster en cours d'exécution d'utiliser le
même port dans différentes cages).
</para>
<para>
Les <systemitem class="osname">FreeBSD</systemitem>, avant la 4.0, fonctionnent
comme <systemitem class="osname">OpenBSD</systemitem> (voir ci-dessous).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="osname">NetBSD</systemitem></term>
<indexterm><primary>netbsd</primary><secondary>configuration ipc</secondary></indexterm>
<listitem>
<para>
Avec <systemitem class="osname">NetBSD</systemitem> 5.0 et
ultérieur, les paramètres IPC peuvent être ajustés en utilisant
<command>sysctl</command>. Par exemple :
<screen>
<prompt>$</prompt> <userinput>sysctl -w kern.ipc.shmmax=16777216</userinput>
</screen>
Pour que ce paramètrage persiste après un redémarrage, modifiez
le fichier <filename>/etc/sysctl.conf</filename>.
</para>
<para>
Vous pourriez aussi vouloir configurer votre noyau pour verrouiller
la mémoire partagée en RAM et l'empêcher d'être mise dans le swap.
Cela peut se faire en utilisant le paramètre
<literal>kern.ipc.shm_use_phys</literal> de <command>sysctl</command>.
</para>
<para>
Les versions de <systemitem class="osname">NetBSD</systemitem>
antérieures à la 5.0 fonctionnent comme <systemitem
class="osname">OpenBSD</systemitem> (voir ci-dessous), sauf que
les paramètres doivent être configurés avec le mot clé
<literal>options</literal>, et non pas <literal>option</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="osname">OpenBSD</systemitem></term>
<listitem>
<indexterm><primary>netbsd</primary><secondary>ipc configuration</secondary></indexterm>
<indexterm><primary>openbsd</primary><secondary>configuration ipc</secondary></indexterm>
<para>
Les options <varname>sysvshm</varname> et <varname>sysvsem</varname> doivent être
activées à la compilation du noyau (ils le sont par défaut). La taille
maximum de mémoire partagée est déterminée par l'option
<varname>shmmaxpgs</varname> (en pages). Ce qui suit montre un exemple de
l'initialisation des différents paramètres :
<programlisting>option SYSVSHM
option SHMMAXPGS=4096
option SHMSEG=256
option SYSVSEM
option SEMMNI=256
option SEMMNS=512
option SEMMNU=256
option SEMMAP=256</programlisting>
</para>
<para>
Vous pourriez aussi vouloir configurer votre noyau pour verrouiller la
mémoire partagée en RAM et l'empêcher d'être paginée en swap. Ceci se
fait en utilisant le paramètre <literal>kern.ipc.shm_use_phys</literal> de
<command>sysctl</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="osname">hp-ux</systemitem></term>
<listitem>
<indexterm><primary>hp-ux</primary><secondary>configuration ipc</secondary></indexterm>
<para>
Les paramètres par défaut tendent à suffire pour des installations
normales. Sur <productname>hp-ux</productname> 10, la valeur par défaut de
<varname>semmns</varname> est 128, qui pourrait être trop basse pour de gros
sites de bases de données.
</para>
<para>
Les paramètres <acronym>ipc</acronym> peuvent être initialisés dans
<application>system administration manager</application> (<acronym>sam</acronym>) sous
<menuchoice><guimenu>kernel configuration</guimenu><guimenuitem>configurable
Parameters</guimenuitem></menuchoice>. Allez sur <guibutton>create a new kernel</guibutton> une fois
terminée.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="osname">linux</systemitem></term>
<listitem>
<indexterm><primary>linux</primary><secondary>configuration ipc</secondary></indexterm>
<para>
La taille maximale du segment par défaut est de 32 Mo, ce qui
n'est adéquat que pour les petites installations de
<productname>PostgreSQL</productname>.
Néanmoins, les paramètres restants sont assez généreusement configurés
et ne requièrent pas habituellement de modifications. La taille du
segment maximum de mémoire partagé peut être modifiée via l'interface <command>sysctl</command>.
Par exemple, pour autoriser 128 Mo et pour configurer explicitement
la taille de la mémoire partagée à 2097152 pages (la valeur par
défaut) :
<screen><prompt>$</prompt> <userinput>sysctl -w kernel.shmmax=134217728</userinput>
<prompt>$</prompt> <userinput>sysctl -w kernel.shmall=2097152</userinput></screen>
De plus, ces paramètrages peuvent être conservés entre les redémarrages
dans <filename>/etc/sysctl.conf</filename>.
</para>
<para>
Les anciennes distributions pourraient ne pas disposer du programme
<command>sysctl</command> mais des modifications équivalentes peuvent
se faire en manipulant le système de fichiers
<filename>/proc</filename> :
<screen><prompt>$</prompt> <userinput>echo 134217728 >/proc/sys/kernel/shmmax</userinput>
<prompt>$</prompt> <userinput>echo 2097152 >/proc/sys/kernel/shmall</userinput></screen>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="osname">macos x</systemitem></term>
<listitem>
<indexterm><primary>macos x</primary><secondary>configuration ipc</secondary></indexterm>
<para>
Avec OS X 10.2 et antérieures, éditez le fichier
<filename>/system/library/startupitems/systemtuning/systemtuning</filename>
et modifiez les valeurs avec les commandes suivantes :
<programlisting>sysctl -w kern.sysv.shmmax
sysctl -w kern.sysv.shmmin
sysctl -w kern.sysv.shmmni
sysctl -w kern.sysv.shmseg
sysctl -w kern.sysv.shmall</programlisting>
</para>
<para>
Avec OS X 10.3 et les versions suivantes, ces commandes ont été
déplacées dans <filename>/etc/rc</filename> et doivent être éditées là-bas.
Notez que <filename>/etc/rc</filename> est habituellement surchargé par les
mises à jour d'OS X (comme celle de 10.3.6 à 10.3.7) donc vous devez
vous attendre à avoir à refaire votre édition après chaque mise à jour.
</para>
<para>
Sous OS X 10.3.9 et les versions ultérieures, au lieu de modifier
<filename>/etc/rc</filename>, vous pouvez créer un fichier nommé
<filename>/etc/sysctl.conf</filename> contenant des affectations de
variables comme :
<programlisting>kern.sysv.shmmax=4194304
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
kern.sysv.shmall=1024
</programlisting>
Cette méthode est préférée à la modification de <filename>/etc/rc</filename>
car vos modifications seront préservées y compris après les mises à jour
du système. Notez que <emphasis>les cinq</emphasis> paramètres de mémoire
partagée doivent être configurés dans <filename>/etc/sysctl.conf</filename>,
sinon les valeurs seront ignorées.
</para>
<para>
Attention au fait que les versions récentes d'OS X ignorent les tentatives
de configuration de <varname>SHMMAX</varname> à une valeur qui n'est pas
un multiple exact de 4096.
</para>
<para>
<varname>SHMALL</varname> est mesuré en page de 4 Ko sur cette
plateforme.