Le modèle d'E / S étrange et extrêmement lent que je vois est le suivant (sortie de iostat -dxk 1 /dev/xvdb1):
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
xvdb1 0.00 0.00 0.99 0.99 7.92 3.96 12.00 1.96 2206.00 502.00 99.41
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
xvdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 100.40
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
xvdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 100.40
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
xvdb1 0.00 0.00 0.99 0.00 3.96 0.00 8.00 0.99 2220.00 1004.00 99.41
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
xvdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 100.40
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
xvdb1 0.00 0.99 0.99 0.00 7.92 0.00 16.00 1.14 2148.00 1004.00 99.41
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
xvdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2.01 0.00 0.00 100.40
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
xvdb1 0.00 0.00 1.00 1.00 4.00 8.00 12.00 2.01 1874.00 502.00 100.40
Je ne sais pas pourquoi l'utilisation du disque et l'attente sont si élevées, et les taux de lecture / écriture sont si bas. Quelle pourrait en être la raison?
La table interrogée a simplement plusieurs colonnes varchar uniquement, dont une est last_name, qui est indexée (en fait lower(last_name)est indexée). La requête elle-même est simple:
SELECT * FROM consumer_m WHERE lower(last_name) = 'hoque';
Voici la sortie d'explication:
QUERY PLAN
-------------------------------------------------------------------------------------------------
Bitmap Heap Scan on consumer_m (cost=2243.90..274163.41 rows=113152 width=164)
Recheck Cond: (lower((last_name)::text) = 'hoque'::text)
-> Bitmap Index Scan on consumer_m_last_name_index (cost=0.00..2215.61 rows=113152 width=0)
Index Cond: (lower((last_name)::text) = 'hoque'::text)
Notez également que la base de données est sur auto_vacuum, donc aucun vide / analyse explicite n'a été effectué.
performance
postgresql
hard-drive
iostat
ehsanul
la source
la source
Réponses:
Le fait que votre appareil fonctionne
/dev/xvdb1implique que vous exécutez sous Xen. Comment est configuré votre stockage? Y a-t-il des conflits pour le périphérique sous-jacent, et à quoi celaiostatressemble - t -il ?À moins que vous ne puissiez éliminer cela aussi probablement, c'est là que je vais pointer le tourniquet du blâme de mauvaises performances.
Fondamentalement, l'approche globale pour démêler un problème de performances comme celui-ci consiste à penser à toutes les couches où un goulot d'étranglement pourrait se produire, puis à concevoir des tests pour les éliminer jusqu'à ce que vous isoliez le problème.
la source
iostatsur le disque à partir de dom0 juste pour voir si l'image est similaire? Pouvez-vous faire d'autres tests de référence de disque de base des deux niveaux? Cela aidera au moins à préciser où chercher ensuite.iostatest exécuté? Cela devrait-il être important? Je n'ai pas actuellement d'accès direct à dom0, bien que je puisse l'obtenir. J'essaieraifiopour le benchmarking en attendant.Voici quelques suggestions, dans un ordre plus ou moins aléatoire:
Autovacum n'est pas activé par défaut dans CentOS. Vous devez définir plusieurs paramètres pour l'activer. Revérifiez pour que le processus sous vide s'exécute réellement. Il est facile de manquer l'un des paramètres requis.
Notez que vous devez effectuer une deuxième étape de filtrage pour cette requête, ce qui peut être coûteux en fonction de ce que vous récupérez. Je considérerais un indice tel que:
CREATE INDEX consumer_m_lower_last ON consumer_m (inférieur (nom));
Qui correspondra à votre requête et supprimera la nouvelle vérification.
De plus, comme le souligne mattdm, vous ne pouvez pas faire confiance à iostat dans les environnements virtualisés.
Vous devriez probablement vérifier http://lonesysadmin.net/2008/02/21/elevatornoop/ si vous avez des problèmes d'E / S dans un environnement XEN. Les paramètres de l'ascenseur peuvent avoir un impact, mais pas aussi important.
Le disque sous-jacent utilise-t-il des instantanés LVM? Bien que cela soit très utile du point de vue de la gestion, cela peut tuer les performances d'E / S. Cela est vrai à la fois si le périphérique de bloc que vous utilisez est un instantané et si un instantané a été pris du périphérique de bloc.
la source
/utilise en fait des instantanés LVM, mais pas celui sur lequel la base de données est stockée. Je ne pense donc pas que ce soit ça. Je vais cependant examiner vos autres suggestions!Je doute que ce soit un problème avec PostgreSQL, et plus probablement un problème avec Disk IO. Comme le mentionnent les commentaires d'une autre réponse, s'il s'agit d'un problème d'E / S de disque, vous devez vraiment mesurer à partir de Dom0 afin d'avoir une image de tout ce qui se passe.
J'ai eu un problème très similaire il y a quelque temps et il s'est avéré être un problème avec le contrôleur de disque. L'accès très lent au disque provoquait un goulot d'étranglement du système en attendant les E / S du disque (ce qui s'est révélé comme des moyennes de charge et des temps d'attente très élevés, mais aussi des processus attendant que le disque consomme plus de CPU qu'ils ne le feraient autrement. Il s'est avéré que le noyau ne reconnaissait pas correctement le contrôleur et retombait sur le contrôleur IDE de la vieille école au lieu d'un contrôleur SATA rapide.
Le correctif consistait à démarrer avec
à la fin de la chaîne du noyau dans /etc/grub.conf. (Bien sûr, ajoutez tous les disques dont vous disposez, ala:
hdc=noprobe, hdc=none, hdd=...)la source