Re: Lenteurs inexpliquées

Le Tue, 06 Jun 2006 16:06:58 +0200
julien WICQUART <j(dot)wicquart(at)newtech(dot)fr> a écrit:

> Bonjour,
>
> j'utilise un serveur postgresql 7.4 (2 serveurs en mode
> actif/secours) travaillant sur une partition en raid réseau pour les
> datas et le WAL (mode fsync)
.
Je ne suis pas un EXPERT mais le seul souvenir de "lenteurs" qui arrivaient
à rendre un serveur presque inutilisable était du à des query pas "clearés".
La doc indique quelque part que l'utilisateur (ou le progammeur) doit
fermer ses queries, faute de quoi ils s'entassent et finissent par saturer
la mémoire, jusqu'à deconnexion de l'utilisateur.
A part ça, avec une carte SCSI-Raid Mylex DAC960 et deux disques en raid-1,
ça va bien plus vite qu'avec du SCSI ordinaire et je ne connais pas drbd ...
Seul autre problème, postgres fait volontier des recherches sequentielles,
ce qui peut être desactivé dans postgresql-conf "enable_seqscan=false"
mais ceci ne doit jouer que sur les recherches, pas les mises à jour, où
le problème pourrait provenir des "sync" que ferait faire drbd ... ?

>
> Descriptif des serveurs :
> - bi-xéon 3,4Ghz
> - 3Go DDRAM
> - disque système : 18Go ultra320 SCSI 10000tr/mn
> - disque data et WAL postgres : 146Go ultra320 SCSI 15000tr/mn
> (c'est sur ce disque qu'est montée la partition drbd)
> - interfaces réseau 1Gbps
> - debian sarge
> - kernel 2.6.8-3-686-smp
> - postgresql 7.4 (7.4.7) - je n'ai pas la possibilité de passer en
> version 8.1 (du fait de l'ancienneté des clients utilisés).
> - drbd 0.7 (0.7.10)
>
> Le raid réseau est assuré par le logiciel drbd (0.7) en mode
> synchrone avec un lien point à point 1 gigabits entre les serveurs.
> Les benchs disponibles sur le net et mes tests montrent une lenteur
> apportée par la couche DRBD en écriture. Celle-ci n'est néanmoins
> pas significative et n'explique pas le problème suivant.
>
>
> J'ai environ 1000cnx/mn sur une base de 45 tables dont les plus
> grosses n'exédent pas 1,5 millions de lignes.
> Je n'ai pas activé les traces donc je ne sais pas quelles sont les
> tables les plus utilisées. Je ne maitrise pas les clients, je ne
> peux donc pas minimiser le nombre d'ouverture et de fermeture de
> session (si ce n'est par l'ajout d'un proxy).
>
> Mon problème est le suivant :
> certains insert peuvent prendre jusqu'à 90s et ceci :
> - alors que la majorité des insert prennent un temps correct (moins
> d'1 seconde) - aléatoirement dans le temps (aucune corrélation
> possible avec des traitements) - aléatoirement sur les tables (pas
> une table en particuliers) - sans lock utilisé sur les tables
> - alors qu'un vacuum analyze est fait toutes les nuits
> - alors qu'autovacuum fonctionne (j'ai bien validé que ce n'était
> pas autovacuum qui crée ces problèmes) - alors qu'un reindex des
> tables système est fait toutes les semaines - alors qu'un reindex
> des tables système et des tables de données est fait tous les mois
>
>
> A la vue de ces informations, avez-vous une idée des principaux
> problèmes pouvant causé ces lenteurs à l'insertion ?
>
>
> Voici ci joint la conf de postgresql adaptée en fonction du site de
> Varlena :
>
> tcpip_socket = true
> max_connections = 1000
> shared_buffers = 56250
> sort_mem = 5120
> vacuum_mem = 300000
> max_fsm_pages = 200000
> max_fsm_relations = 10000
> wal_buffers = 256
> checkpoint_segments = 16
> checkpoint_timeout = 1800
> commit_delay = 100000
> effective_cache_size = 243750
> default_statistics_target = 1000
> syslog = 0
> log_error_verbosity = default
> log_min_error_statement = error
> log_min_duration_statement = 1000
> silent_mode = false
> log_connections = true
> log_pid = true
> log_timestamp = true
> stats_start_collector = true
> stats_row_level = true
> datestyle = 'SQL,European'
> dynamic_library_path =
> '/usr/share/postgresql:/usr/lib/postgresql:/usr/lib/postgresql/lib'
> deadlock_timeout = 2000
>
>
>
> ---------------------------(end of
> broadcast)--------------------------- TIP 5: don't forget to
> increase your free space map settings
>

--
Alain Lucari (Eurlix)