Context switch overhead is discussed and thread states are introduced.

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 Buffers

A 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

Benchmark qui compare Amazon Aurora et du Percona installé sur des instances EC2 avec des différents types de stockages (general purpose ssd, provisionned iops ssd 2000/3000).

"""
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
"""
Excellent cet article.
J'ai découvert pidstat (provient du paquet sysstat), mpstat, et je ne savais pas que sar permettait d'analyser la bande passante par interface réseau.

"""
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 !
"""

"""
In case the number of tomcat threads and acceptCount values are set to be too high, a sudden increase in traffic will fill up the OS queues and make all the worker threads busy. When more requests than that can be handled by the system are sent to the machines, this "queuing" of requests is inevitable and will lead to increased busy threads, causing cpu starvation eventually. Hence, the crux of the solution is to avoid too much queuing of requests at multiple points (OS and tomcat threads) and fail fast (return http status 503) as soon the application's maximum capacity is reached. Here is a recommendation for doing this in practice:

Fail fast in case the system capacity for a machine is hit.
"""

Me gusta mucho!

Sysdig permet d'afficher un spectrogram coloré avec la latence des différents appels systèmes (par ex. open, close, read, write, socket…) pour un programme donné. Cela permet directement de voir, de manière élégante et sans serveur X, dans quel frange de temps de réponse se situent les syscalls qu'on analyse.

Pour mettre en valeur cet outil, l'auteur montre un cas pratique avec un benchmark des différents type de stockage qu'offre EC2: ssd local à l'instance, ebs magnetic, ebs ssd.

Ernie Souhrada, DBA chez Pinterest, explique comment il a drastiquement amélioré les perfs mysql sans changer de hardware.
"""
When we enable all of the optimizations, we find we can achieve roughly 500 percent more read and write throughput at both 16 and 32 threads while simultaneously reducing p99 latency by over 500ms in both directions. On the read side, we go from approximately 4100 – 4600 QPS to just over 22000 – 25000, depending on concurrency. On the write side, we go from approximately 1000 QPS to 5100 – 6000 QPS. These are massive gains in headroom and performance achieved with just a few simple changes.
"""
sur du i2.4xlarge (de la grosse instance ec2 de porc), percona-server-5.6, ubuntu 12.04.

Voir aussi http://www.slideshare.net/denshikarasu/all-your-iops-are-belong-to-us-a-pinteresting-case-study-in-mysql-performance-optimization
qui va plus dans les détails, avec les tests sysbench pour les différents disques, versions de kernel, modifs my.cnf, irqbalance, options de montage, etc... qui ont permi de tirer les conclusions.

On apprend notamment que le kernel en version 3.18 montre de meilleurs perfs IO qu'en 3.13.

Très pointu.

"""
First of all, we retrieve all PHPUnit groups by running a container with the phpunit --list-group command.

Next the gnu parallel command helps us to run tests for each group in parallel. Each task is launched by one core of your processor. If you've got a large cruiser with 8 core then you can run 8 tests group simultaneously.
"""

c'est cool la commande parallel.
exemple:
"""
$ cat test
30
20
40
$ cat test | parallel sleep {}
"""
ça lance simultanément un
"""
$ sleep 20
$ sleep 30
$ sleep 40
"""
xargs peut faire la même chose mais c'est plus chiant parce que faut indiquer '-P' (max-procs):
"""
$ echo {1..5} | xargs -n 1 -P 5 sleep
"""

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.
"""

• Comment bien indexer, pourquoi?
• Qu'est-ce qu'un plan d'éxécution?

Voila quelques questions auxquelles vous trouverez une réponse dans ce site.

• Existe aussi en français
• Issu d'un bouquin: http://sql-performance-explained.com/

par un gars de chez netflix

slides: http://fr.slideshare.net/brendangregg/performance-tuning-ec2-instances

"""
Work is just a game for Oracle. A game in which HR tracks your every move.
"""

outils pour aider à tunner un mysql
http://mysqltuner.pl/ (https://github.com/major/MySQLTuner-perl)
http://day32.com/MySQL/
http://www.mysqlcalculator.com/
lire aussi
http://www.khankennels.com/presentations/pdf/performance_tuning.pdf

Comme on a aucune idée de connaitre les perfs disque et réseau des instances ec2 (sauf en testant par soi-même), certains on fait des benchs.
Les résultats de ces benchs, qui testent les perfs réseau, montrent qu'on a intérêt à faire attention dans les choix d'instance....
"""
In our experiment we saw that the network performance of m1.large was lower than that of m1.medium. As per AWS documentation, the network performance of both m1.medium and m1.large is ‘moderate’ so we expected it to be similar. We also see that the network bandwidth of m3.medium is less than that of m1.small even though AWS documentation says that the network performance m3.medium is ‘moderate’ while that of m1.small is ‘low’. Network performance often depends on various scenarios like the network load on the actual hardware on which the VM is running. This might be a possible reason for this anomaly.
"""

voir aussi https://jeekajoo.eu/links/?GblCKw pour des comparaisons perf cpu/mem/disk

"""
By using this tool you can easily spot disk bottlenecks, measure the IO subsystem and identify how much IOPS your drive can handle (i.e. disk capacity).
"""
encore un bon outil signé percona.
cet outil fait parti de percona-toolkit: http://www.percona.com/software/percona-toolkit
license: GNU GPL v2

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.