Comment optimiser la base de données pour les E / S lourdes à partir des mises à jour (logiciel et matériel)


20

La situation J'ai une base de données postgresql 9.2 qui est assez fortement mise à jour tout le temps. Le système est donc lié aux E / S, et j'envisage actuellement de faire une autre mise à niveau, j'ai juste besoin de quelques indications pour commencer à améliorer.

Voici une image de la situation au cours des 3 derniers mois:

entrez la description de l'image ici

Comme vous pouvez le voir, les opérations de mise à jour représentent la majeure partie de l'utilisation du disque. Voici une autre image de la situation dans une fenêtre plus détaillée de 3 heures:

entrez la description de l'image ici

Comme vous pouvez le voir, le taux d'écriture de pointe est d'environ 20 Mo / s

Logiciel Le serveur exécute ubuntu 12.04 et postgresql 9.2. Les types de mises à jour sont de petite taille, généralement mis à jour sur des lignes individuelles identifiées par ID. Par exemple UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id. J'ai supprimé et optimisé les index autant que je pense possible, et la configuration des serveurs (noyau Linux et conf postgres) est également assez optimisée.

Matériel Le matériel est un serveur dédié avec 32 Go de RAM ECC, 4 disques SAS de 600 Go à 15 000 tr / min dans une matrice RAID 10, contrôlé par un contrôleur RAID LSI avec BBU et un processeur Intel Xeon E3-1245 Quadcore.

Des questions

  • Les performances vues par les graphiques sont-elles raisonnables pour un système de ce calibre (lecture / écriture)?
  • Dois-je donc me concentrer sur une mise à niveau matérielle ou approfondir le logiciel (ajustement du noyau, confs, requêtes, etc.)?
  • Si vous effectuez une mise à niveau matérielle, le nombre de disques est-il essentiel aux performances?

------------------------------MISE À JOUR------------------- ----------------

J'ai maintenant mis à niveau mon serveur de base de données avec quatre SSD Intel 520 au lieu des anciens disques SAS 15k. J'utilise le même contrôleur de raid. Les choses se sont beaucoup améliorées, comme vous pouvez le voir ci-dessous, les performances d'E / S de pointe se sont améliorées environ 6 à 10 fois - et c'est génial! entrez la description de l'image ici Cependant, je m'attendais à quelque chose de plus comme une amélioration de 20 à 50 fois selon les réponses et les capacités d'E / S des nouveaux SSD. Voici donc une autre question.

Nouvelle question Y a - t-il quelque chose dans ma configuration actuelle qui limite les performances d'E / S de mon système (où est le goulot d'étranglement)?

Mes configurations:

/etc/postgresql/9.2/main/postgresql.conf

data_directory = '/var/lib/postgresql/9.2/main'
hba_file = '/etc/postgresql/9.2/main/pg_hba.conf'
ident_file = '/etc/postgresql/9.2/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/9.2-main.pid'
listen_addresses = '192.168.0.4, localhost'
port = 5432
unix_socket_directory = '/var/run/postgresql'
wal_level = hot_standby
synchronous_commit = on
checkpoint_timeout = 10min
archive_mode = on
archive_command = 'rsync -a %p postgres@192.168.0.2:/var/lib/postgresql/9.2/wals/%f </dev/null'
max_wal_senders = 1
wal_keep_segments = 32
hot_standby = on
log_line_prefix = '%t '
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
default_statistics_target = 100
maintenance_work_mem = 1920MB
checkpoint_completion_target = 0.7
effective_cache_size = 22GB
work_mem = 160MB
wal_buffers = 16MB
checkpoint_segments = 32
shared_buffers = 7680MB
max_connections = 400 

/etc/sysctl.conf

# sysctl config
#net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
# ipv6 settings (no autoconfiguration)
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.default.accept_dad=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.accept_ra_defrtr=0
net.ipv6.conf.default.accept_ra_rtr_pref=0
net.ipv6.conf.default.accept_ra_pinfo=0
net.ipv6.conf.default.accept_source_route=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_dad=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.accept_ra_defrtr=0
net.ipv6.conf.all.accept_ra_rtr_pref=0
net.ipv6.conf.all.accept_ra_pinfo=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.forwarding=0
# Updated according to postgresql tuning
vm.dirty_ratio = 10
vm.dirty_background_ratio = 1
vm.swappiness = 0
vm.overcommit_memory = 2
kernel.sched_autogroup_enabled = 0
kernel.sched_migration_cost = 50000000

/etc/sysctl.d/30-postgresql-shm.conf

# Shared memory settings for PostgreSQL
# Note that if another program uses shared memory as well, you will have to
# coordinate the size settings between the two.
# Maximum size of shared memory segment in bytes
#kernel.shmmax = 33554432
# Maximum total size of shared memory in pages (normally 4096 bytes)
#kernel.shmall = 2097152
kernel.shmmax = 8589934592
kernel.shmall = 17179869184
# Updated according to postgresql tuning

Sortie de MegaCli64 -LDInfo -LAll -aAll

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 446.125 GB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 446.125 GB
State               : Optimal
Strip Size          : 64 KB
Number Of Drives per span:2
Span Depth          : 2
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
Is VD Cached: No

(1) .Si les colonnes ne sont pas indexées, vous pouvez profiter de HOT (voir git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/… ). (2). Essayez avec synchronous_commit = off, après avoir lu les documents sur postgresql.org/docs/9.2/static/wal-async-commit.html . (3). À quoi ressemble votre configuration? Par exemple. résultats de cette requête:SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');
bma

@bma Permettez-moi d'ajouter l'avertissement suivant synchronous_commit: «La validation asynchrone est une option qui permet aux transactions de se terminer plus rapidement, au prix de la perte des transactions les plus récentes en cas de panne de la base de données.
dezso

@dezso J'aurais dû être plus explicite sur la section des documents auxquels je faisais référence. Merci pour la clarification. La raison pour laquelle j'ai soulevé cette question est que l'un de nos serveurs sous forte charge (utilisant Hibernate) souffrait, j'ai donc pris la décision éclairée de passer en validation asynchrone et 40% de la charge a pratiquement disparu. Non recommandé pour la plupart des systèmes, mais dans certains cas, il peut vous faire gagner du temps entre les mises à niveau du serveur et les changements d'application.
bma

Réponses:


10

Si vous effectuez une mise à niveau matérielle, le nombre de disques est-il essentiel aux performances?

Oui, car un disque dur - même SAS - a une tête qui prend du temps à bouger.

Vous voulez une mise à niveau HUGH?

Tuez les disques SAS, accédez à SATA. Branchez le SSD SATA - niveau entreprise, comme le Samsung 843T.

Résultat? Vous pouvez faire environ 60 000 IOPS (soit 60 000) par lecteur.

C'est la raison pour laquelle les SSD tuent dans l'espace DB et sont beaucoup moins chers que n'importe quel disque SAS. Le disque en rotation phyiscale ne peut tout simplement pas suivre les capacités IOPS des disques.

Vos disques SAS étaient un choix médiocre au départ (trop gros pour obtenir beaucoup d'IOPS) Pour une base de données à utilisation plus élevée (plus de disques plus petits signifieraient beaucoup plus d'IOPS), mais à la fin, les SSD changent la donne ici.

Concernant le logiciel / noyau. Toute base de données décente fera beaucoup d'IOPS et videra les tampons. Le fichier journal doit être ÉCRIT pour que les conditions ACID de base soient garanties. Les seules mélodies du noyau que vous pourriez faire invalideraient votre intégrité transactionnelle - en partie, vous POUVEZ vous en sortir. Le contrôleur Raid en mode réécriture fera cela - confirmera que l'écriture est vidée même si elle ne l'est pas - mais il peut le faire parce que le BBU est supposé sécuriser le jour où l'alimentation est coupée. Tout ce que vous faites plus haut dans le noyau - sachez mieux que vous pouvez vivre avec les effets secondaires négatifs.

À la fin, les bases de données ont besoin d'IOPS, et vous pourriez être surpris de voir à quel point votre configuration est petite par rapport à d'autres ici. J'ai vu des databaes avec plus de 100 disques juste pour obtenir l'IOPS dont ils avaient besoin. Mais vraiment, aujourd'hui, vous achetez des SSD et optez pour la taille sur eux - ils sont tellement supérieurs dans les capacités IOPS, cela n'a aucun sens de combattre ce jeu avec des disques SAS.

Et oui, vos numéros IOPS ne sont pas mauvais pour le matériel. Dans ce que j'attendais.


6

Si vous pouvez vous le permettre, placez pg_xlog sur une paire de disques RAID 1 distincte sur son propre contrôleur avec une RAM sauvegardée par batterie configurée pour la réécriture. Cela est vrai même si vous devez utiliser la rouille tournante pour pg_xlog alors que tout le reste est sur SSD.

Si vous utilisez un SSD, assurez-vous qu'il dispose d'un supercondensateur ou d'un autre moyen pour conserver toutes les données mises en cache en cas de panne de courant.

En général, plus de broches signifie plus de bande passante d'E / S.


Malheureusement, je n'ai que quatre emplacements de disque dur dans le contrôleur de raid. Pourquoi voudriez-vous mettre les pg_xlogs sur un tableau séparé, si tous les autres disques étaient des SSD?
Niels Kristian

2
@NielsKristian Je pense avoir raison quand je dis que dans la plupart des systèmes, le journal des transactions est la chose la plus écrite sur le disque. De plus, l'écriture se fait essentiellement parallèlement à l'écriture des données. Les deux ne peuvent pas être effectués en même temps avec un disque dur car la tête se trouve sur pg_xlog ou sur les dossiers de données. (Alerte de simplification sérieuse!) La séparation des deux tâches répartit la charge d'E / S sur deux disques / baies indépendants.
dezso

2
En plus de ce que @dezso a dit, les disques durs sont OK pour le stockage dédié au WAL car l'accès est presque entièrement séquentiel, donc le temps de recherche est minime ..
kgrittn

1

En supposant que vous exécutez sous Linux, assurez-vous de définir le planificateur d'E / S de disque.

D'après l'expérience passée, le passage à noop vous donnera une accélération assez importante (en particulier pour les SSD).

La modification du planificateur d'E / S peut être effectuée à la volée sans interruption.

c'est à dire. echo noop> / sys / block // file d'attente / ordonnanceur

Voir: http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/ pour plus d'informations.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.