397 liens privés
Petit voyage à travers le code de PostgreSQL, avec des commentaires sur la structure et le cheminement pour retrouver le code responsable des requêtes.
Moving down; this is it, looks like we've found the core algorithm for making a query:
...
This is good code. Internally, it seems PostgreSQL refers to select as 'scan,' not 'select,' and there are several different ways to select.
Configuration calculator for PostgreSQL
Pour se donner un ordre d'idée, le mieux étant d'utiliser pgtune directement et de RTFM le sens de chaque directive.
Ce qu'il faut globalement savoir:
Structure de la mémoire sous PostgreSQL :
• Zone de mémoire partagée:
• Shared Buffers
• Wal Buffers
• Données de session
• Verrous
• FSM ( < 8.4 )
• Par processus:
• Work Mem
• Maintenance Work Mem
• Temp BuffersA propos de effective_cache_size ...
Un cache supplémentaire est disponible pour PostgreSQL: celui du système
d'exploitation. Il est donc intéressant de préciser à PostgreSQL la taille
approximative du cache, ou du moins de la part du cache qu'occupera
PostgreSQL. Le paramètre effective_cache_size n'a pas besoin d'être très
précis, mais il permet une meilleure estimation des coûts par le moteur. On le
paramètre habituellement aux alentours des 2/3 de la taille du cache du
système d'exploitation, pour un serveur dédié.Voir aussi: https://jeekajoo.eu/links/?searchtags=postgresql+tuning
Un tuto très simple qui explique comment utiliser l'excellent pgbadger.
C'est un script perl qui analyse les logs postgres, hors connexion.
Il génère une page html (avec tout le contenu statique nécessaire "inliné") qui présente tout un tas de statistiques dont les fameux histogrammes des requêtes lentes, etc..
Plus d'informations sur l'outil: http://dalibo.github.io/pgbadger/ + https://github.com/dalibo/pgbadger/
Encore un bel outil postgres, signé Dalibo: http://www.dalibo.com/ <3
Un article qui explique comment Postgres stocke ses données.
via https://n.survol.fr/n/introduction-to-postgresql-physical-storage
Issu du dernier GNU Linux Mag: http://boutique.ed-diamond.com/home/874-gnulinux-magazine-184.html#/format_du_magazine-magazine_papier
Bon, le tuto utilise la version 9.1 de pgsql mais ça reste d'actualité car les changements majeurs pour la répli sont intervenus avec cette version.
Via collègue, merci!
"""
Les premiers tests avec pgbouncer donnent des temps de réponses médians de 285ms avec un 99th percentile à 1650ms, toutes les requêtes sont traitées avec succès
Si on débranche pgbouncer le temps de réponses médian croit à 14487ms et surtout le max dépasse 60126ms ce qui donne un nombre croissant de requête en timeout sur la fin du test quand on arrive à pleine charge.
(...)
PgBouncer peut apparaître comme un outil compliqué quand on a pas l'habitude des bases de données, mais il est fort à parier que votre DBA le connait déjà, alors si l'utilisation de vos API croît ayez le réflex PgBouncer !
"""
un exemple de state saltstack pour postgresql avec un tuning dynamique suivant la taille de la mémoire de la machine. C'est basé sur les conventions de pgtune (http://pgfoundry.org/projects/pgtune/).
dans la continuité de mon précédent shaarlink, cloudflare explique pourquoi ils ont forké postgresql pour leurs besoins de stockage d'évènements nginx..
"""
CitusDB has also maintained compatibility with PostgreSQL, not by forking the code base like other vendors, but by extending it to plan and execute distributed queries. Furthermore, CitusDB used the concept of many logical shards so that if we were to add new machines to our cluster, we could easily rebalance the shards in the cluster by calling a simple PostgreSQL user-defined function.
With CitusDB, we could replicate logical shards to independent machines in the cluster, and automatically fail over between replicas even during queries. In case of a hardware failure, we could also use the rebalance function to re-replicate shards in the cluster.
"""
via dotscale.io
outils de migration mysql -> pgsql
Open PostgreSQL Monitoring par dalibo (des frenchies qui sont vraiment très compétents dans ce qu'ils font).
on leur doit aussi POWA: http://dalibo.github.io/powa/
un outil complémentaire aux outils de monitoring traditionnels.
c'est pas mal pour analyser les requêtes lentes dans le temps, car on peut zoomer sur le graph et voir les requêtes associées à cet instant t.
Cet article souligne des problèmes de performances de postgresql liés à sa conception mais aussi à celle du kernel linux. On parle notamment de la gestion des I/O et des fsync().
Note perso: Il n'en reste pas moins que c'est une excellente base de données du niveau de ce que fait Oracle dans le monde du propriétaire. Je ne parle pas de MySQL car on parle ici de bdd sûres à destination des professionnels.
<3 stackoverflow est toujours là pour répondre à mes questions <3
autre source de réponse: http://www.postgresql.org/message-id/445FFF4A-1FD7-410B-A1EB-DB66AFF57C79@seespotcode.net