Journal Postfix + Base SQL

Posté par  .
Étiquettes :
0
21
juin
2006
Salut

J'aimerais avoir (si possible) des retours d'expérience et/ou des avis.
Je vais déployer un "gros" serveur de messagerie (environ 10000 boites mails) : Postfix + Dovecot pour le pop et imap (+ probablement un webmail (SquirrelMail) )
Ma contrainte : utilisation d'une base SQL (pas de LDAP)
Le serveur de mail sera relié a une baie de disque pour le stockage des mails. L'OS sera une Debian Sarge.
Ma question ; je cherche a savoir quel moteur SQL mettre : Mysql ou PostgreSQL. Je suis a l'aise avec les deux donc pas de soucis de ce cote la. Ce qui m'interesses le plus, ce sont bien evidemment les performances (Postfix et Dovecot "taperont" tres frequemment sur la base). Si je devais mettre du MySQL, je pensais le faire via les backports pour bénéficier de la version 5 (qui apparemment est bien plus rapide). Pour ce qui est de PostGreSQL, je ne sais pas : 7.4 ou 8.1 (backports)
Donc si vous avez des retours d'esperience la dessus ou des avis a me donner (mais pas de troll svp), ca m'interesse.

Merci
  • # Expérience avec MySQL

    Posté par  . Évalué à 1.

    Pour un serveur gérant environ 2000 comptes mail, j'ai remarqué que:
    - Postfix utilise une connection MySQL par processus (prévoir d'augmenter le nombre de connection maximum dans MySQL)
    - Postfix "requête" la base de façon inutile (trop de requête de selection) (Patch personnel de Postfix)
    - Le service est stable et relativement performant
    • [^] # Re: Expérience avec MySQL

      Posté par  . Évalué à 1.

      Merci de ton retour. Peux tu m'en dire plus sur ton patch "personnel" de Postfix ?
    • [^] # Re: Expérience avec MySQL

      Posté par  (site web personnel) . Évalué à 1.

      perso, je te conseille de passer par une socket systeme entre le serveur postfix et le mysql, si ils doivent se trouver sur la meme machine. au niveau performance, il n'y a pas photo.
      voila mon retour d'experience...
      bon courage en tout cas :-D
  • # Fais un bench

    Posté par  (site web personnel) . Évalué à 1.

    PostgreSQL car l'asso francophone a des beau tshirts : http://guinness.nah-ko.org/~toffe/pgfr/postgresqlfr.png

    et un beau site web :
    http://postgresqlfr.org/

    Sinon pour répondre à ta question, je te conseillerai de tester les deux et de faire un mini bench avec un script qui injecte des mails en masse:

    http://docs.python.org/lib/SMTP-example.html
  • # Re

    Posté par  (site web personnel) . Évalué à 3.

    Effectivement la solution 'fais un bench' est la plus logique,
    sache quand meme que si tu a bien definie ta DB que tu
    utilise du MyIsam que ta largeur de champ est fixe que tes
    indexes sont bien definis tu aura du mal a battre mysql.

    Ensuite n'oublie pas de configuré le mysql au petits oignions
    mais le gros du gain se fait sur le formatage statique des tables
    (ie pas de TEXT, BLOB, VARCHAR et autre variables de taille dynamiques).

    Pour analyser les perfs du query cache:
    show variables like '%query%';
    show status like 'Qc%';

    Qcache_queries_in_cache => nombre de requetes dans le cache (+ c mieux)
    Qcache_inserts => nombre de mises en cache de requetes (- c mieux)
    Qcache_hits => nombre de requetes en cache demandées (+ c mieux)
    Qcache_lowmem_prunes => nombre de requetes en cache supprimées pour
    cause de low memory (- c mieux)
    Qcache_not_cached => nombre de requetes non cachables (- c mieux)

    Qcache_free_memory
    Qcache_free_blocks
    Qcache_total_blocks => etat de la mémoire reservées au cache.

    Analyse du cache des tables (ouverture/fermeture des fichiers contenant les
    tables).
    show variables like 'table_cache';
    show status like 'Open%_tables';
    il faut que Open_tables soit proche de table_cache et si possible que
    Opened_tables soit proche de Open_table (impossible dans le cadre
    d'un gros serveur DB avec un grand nombre de table).

    Analyse du nombre de connection concurrentes
    show variables like '%conn%';
    show status like 'Max%';


    PostgreSQL est interessant dans le cas de SQL avance,
    de procedures stockées et autres contraintes relationnelles.
    Malheureusement il ne dispose pas comme mysql d'un moteur
    lite (myisam).
    • [^] # Re: Re

      Posté par  (site web personnel) . Évalué à 3.

      Pour de nombreux insert et select concurrent, je pense quand même que InnoDB sera plus efficace que MySAM (lock par ligne / lock par table, 10000 utilisateurs simultanés ça engendre du traffic en RW :).
  • # MySQL

    Posté par  (site web personnel) . Évalué à 2.

    Holà pas d'emballement :
    la version 5 (qui apparemment est bien plus rapide)

    Ça dépend de ce que tu testes... La version 5 est plus rapide si l'on utilise les procédures stockées et les triggers. Sinon, c'est un chouia moins rapide. Je ne peux que te conseiller de tester la version 4.1 contre la version 5.0. Fait gaffe aussi au moteur de DB par défaut (InnoDB/MyISAM).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.