2009-07-21 6 views
13

Nous avons exécuté une applicationg en utilisant MySql. Nous avons trouvé que MySql ne convenait pas à notre application après que nous ayons constaté qu'elle ne supportait pas la fonctionnalité SIG de PostGIS (nota: mysql ne supporte que la recherche de SIG à rectangle à limite minimum). Nous avons donc changé notre DB en PostgreSQL. Nous avons ensuite découvert que Postgresql 8.2 fonctionnant sous Windows est beaucoup plus lent que MySQL 5.1. Par plus lent, je veux dire à environ 4-5 fois plus lent.Pourquoi PostgreSQL est-il si lent sur Windows?

Pourquoi est-ce? Y a-t-il quelque chose dans la configuration que nous devons changer?

J'ai trouvé quelques commentaires d'autres sites tels que this:

MISE À JOUR: Nous avons constaté que la cause de la lenteur est due au blob que nous insérons dans le DB. Nous devons être en mesure d'insérer BLOB à un taux soutenu de 10-15 Mo/s. Nous utilisons lo_read et lo_write de libpq pour chaque BLOB que nous insérons/lisons. Est-ce la meilleure façon? Quelqu'un at-il utilisé Pgsql pour l'insertion de gros BLOB à un taux élevé avant?

EDIT: J'ai entendu dire que PgSql venait tout juste d'être porté sur Windows. Serait-ce l'une des raisons?

+1

1. La dernière version est 8.4 (sortie ce mois-ci) - upgrade, test, report. 2. Cet «autres sites Web» est l'archive officielle de la liste de diffusion du projet PostgreSQL. Mais d'un autre côté, l'article que vous liez est très ancien et mentionne une version très ancienne et non supportée (8.0). –

Répondre

21

Il existe des cas où PostgreSQL sur Windows paie un surcoût supplémentaire par rapport à d'autres solutions, en raison des compromis effectués lors du portage. Par exemple, PostgreSQL utilise un processus par connexion, MySQL utilise un thread. Par exemple, PostgreSQL utilise un processus par connexion. Sur Unix, il ne s'agit généralement pas d'une différence de performance notable, mais sur Windows, la création de nouveaux processus est très coûteuse (en raison de l'absence de l'appel système fork()). Pour cette raison, en utilisant des connexions persistantes ou un pooler de connexion est plus important plus important sur Windows lors de l'utilisation de PostgreSQL. Un autre problème que j'ai vu est que PostgreSQL sur Windows tôt par défaut s'assurera que ses écritures passent par le cache d'écriture - même si elle est soutenue par batterie. AFAIK, MySQL ne fait pas cela, et cela affectera grandement les performances d'écriture. Maintenant, cela est réellement nécessaire si vous avez un matériel non-sûr, comme un lecteur bon marché. Mais si vous avez un cache d'écriture sauvegardé par batterie, vous voulez le remplacer par fsync standard. Les versions modernes de PostgreSQL (certainement 8.3) seront par défaut open_datasync, ce qui devrait supprimer cette différence.

Vous n'avez pas non plus mentionné comment vous avez réglé la configuration de la base de données.Par défaut, le fichier de configuration livré avec PostgreSQL est très conservateur. Si vous n'avez rien changé, vous devez absolument y jeter un coup d'œil. Il y a quelques conseils de réglage disponibles sur le PostgreSQL wiki.

Pour plus de détails, vous devrez fournir plus de détails sur ce qui est lent et comment vous avez réglé votre base de données. Je suggère un courriel à la liste de diffusion pgsql-general.

+0

vous avez raison. Après avoir changé la configuration par défaut un peu, c'est devenu un peu plus rapide. – sivabudh

+0

Comment la dernière version recherche-t-elle Windows pour la performance? Votre réponse changerait-elle beaucoup aujourd'hui? –

+0

Alors que la performance s'est nettement améliorée, les lacunes architecturales demeurent. –

7

Alors que le portage Windows de PostgreSQL est relativement récent, je crois comprendre qu'il fonctionne à peu près aussi bien que les autres versions. Mais c'est définitivement un port; presque tous les développeurs travaillent principalement ou exclusivement sur Unix/Linux/BSD.

Vous ne devriez vraiment pas tourner 8.2 sous Windows. À mon avis, 8.3 était la première version de Windows qui était vraiment prête pour la production; 8.4 est encore mieux. 8.2 est plutôt périmé de toute façon, et vous en retirerez plusieurs avantages si vous réussissez à mettre à jour.

Une autre chose à considérer est le réglage. PostgreSQL nécessite plus de réglages que MySQL pour obtenir des performances optimales. Vous voudrez peut-être envisager de poster à l'un des mailing lists pour obtenir de l'aide avec plus de réglages de base.

+1

PostgreSQL nécessite plus de réglages que MySQL: en fait, il a souffert d'une configuration d'utilisation de la mémoire très conservatrice par défaut. Je ne sais pas si c'est toujours le cas, mais c'est généralement le premier suspect. –

0

PostgreSQL est déjà plus lent que MySQL jusqu'à un certain point (il est en fait plus rapide quand vous avez une base de données ridiculement grande). Juste pour votre information, cela ne cause pas votre problème mais gardez cela à l'esprit.

Questions connexes