Güncellemelerden (yazılım ve donanım) ağır G / Ç için veritabanı optimizasyonu


20

Durum oldukça ağır her zaman güncellenen bir postgresql 9.2 veritabanı var. Sistem bu nedenle G / Ç bağlı ve şu anda başka bir yükseltme yapmayı düşünüyorum, sadece nerede geliştirmeye başlamak için bazı yönlere ihtiyacım var.

Durumun son 3 ayda nasıl göründüğünün bir resmi:

resim açıklamasını buraya girin

Gördüğünüz gibi güncelleme işlemleri disk kullanımının çoğunu açıklar. Durumun daha ayrıntılı bir 3 saatlik pencerede nasıl göründüğünün başka bir resmi:

resim açıklamasını buraya girin

Gördüğünüz gibi, en yüksek yazma hızı 20MB / s civarında

Yazılım Sunucu ubuntu 12.04 ve postgresql 9.2 çalıştırıyor. Güncelleme türleri genellikle kimlikle tanımlanan ayrı satırlarda güncellenir. Örn UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id. Mümkün olduğu kadar dizinleri kaldırdım ve optimize ettim ve sunucu yapılandırması (hem linux çekirdeği hem de postgres conf) de oldukça optimize edildi.

Donanım Donanım , 32 GB ECC ram, bir RAID 10 dizisinde 4x 600GB 15.000 rpm SAS diskli, BBU'lu bir LSI raid denetleyicisi ve Intel Xeon E3-1245 Quadcore işlemci ile kontrol edilen özel bir sunucudur.

Sorular

  • Grafiklerde görülen performans, bu kalibreli bir sistem için (okuma / yazma) makul mü?
  • Bu yüzden bir donanım yükseltmesi yapmaya veya yazılımın daha derinlemesine araştırılmasına odaklanmalı mıyım (çekirdek tweaking, confs, sorgu vb.)?
  • Donanım yükseltmesi yapıyorsanız, disk sayısı performansın anahtarı mıdır?

------------------------------GÜNCELLEME------------------- ----------------

Veritabanı sunucumu eski 15k SAS diskler yerine dört intel 520 SSD ile yükselttim. Aynı baskın denetleyicisini kullanıyorum. Aşağıdakilerden de görebileceğiniz gibi işler oldukça gelişti, en yüksek G / Ç performansı 6-10 kat arttı - ve bu harika !. resim açıklamasını buraya girin Ancak, yeni SSD'lerin cevaplarına ve I / O özelliklerine göre 20-50 kat daha fazla iyileşme bekliyordum. İşte başka bir soru.

Yeni soru Mevcut yapılandırmamda, sistemimin G / Ç performansını sınırlayan bir şey var mı (darboğaz nerede)?

Konfigürasyonlarım:

/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

Çıktı 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) .Sütunlar dizine eklenmemişse, HOT değerinden yararlanabilirsiniz (bkz. Git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/… ). (2). Postgresql.org/docs/9.2/static/wal-async-commit.htmlsynchronous_commit = off adresindeki dokümanları okuduktan sonra deneyin . (3). Konfigürasyonunuz nasıl görünüyor? Örneğin. bu sorgunun sonuçları:SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');
bma

@bma Şu konuda uyarı ekleyeyim synchronous_commit: 'Zaman uyumsuz kesinleştirme, veritabanının çökmesi gerektiğinde en son işlemlerin kaybolması pahasına, işlemlerin daha hızlı tamamlanmasını sağlayan bir seçenektir.'
dezso

@dezso Bahsettiğim belgelerin bölümü hakkında daha açık olmalıydım. Açıklama için teşekkürler. Bunu gündeme getirmemizin nedeni, yüksek yük altındaki (Hibernate kullanan) sunucularımızdan birinin acı çekmesiydi, bu yüzden async taahhüdüne geçmek için bilinçli bir karar verdim ve yükün% 40'ı neredeyse kayboldu. Çoğu sistem için önerilmez, ancak bazı durumlarda sunucu yükseltmeleri ile uygulama değişiklikleri arasında size zaman kazandırabilir.
bma

Yanıtlar:


10

Donanım yükseltmesi yapıyorsanız, disk sayısı performansın anahtarı mıdır?

Evet, sabit disk - hatta SAS bile - taşınması zaman alan bir kafaya sahip.

HUGH yükseltmesi mi istiyorsunuz?

SAS disklerini öldürün, SATA'ya gidin. Samsung 843T gibi SATA SSD - kurumsal düzeyde takın.

Sonuç? Sürücü başına yaklaşık 60.000 (yani 60 bin) IOPS yapabilirsiniz.

SSD'nin DB alanındaki katiller olmasının ve herhangi bir SAS sürücüden çok daha ucuz olmasının nedeni budur. Fiziksel eğirme diski, disklerin IOPS yeteneklerine ayak uyduramaz.

SAS diskleriniz başlamak için vasat bir seçimdi (çok fazla IOPS almak için çok büyük) Daha yüksek kullanımlı bir veritabanı için (daha küçük diskler çok daha fazla IOPS anlamına gelir), ancak sonunda SSD burada oyun değiştirici.

Yazılım / çekirdek ile ilgili. İyi bir veritabanı çok fazla IOPS yapacak ve tamponları temizleyecektir. Temel ASID koşullarının garanti altına alınması için günlük dosyasının YAZILMASI gerekir. Yapabileceğiniz tek çekirdek ezgileri işlemsel bütünlüğünüzü geçersiz kılabilir - kısmen bundan kurtulabilirsiniz. Geri yazma modunda Raid denetleyicisi bunu yapacaktır - yazılmasa bile yazmayı temizlenmiş olarak onaylayın - ancak bunu yapabilir, çünkü BBU'nun güç kesildiği günü güvence altına aldığı varsayılır. Çekirdekte daha yüksek yaptığınız her şey - olumsuz yan etkilerle yaşayabileceğinizi daha iyi bilirsiniz.

Sonunda, veritabanlarının IOPS'ye ihtiyacı vardır ve kurulumunuzun burada diğerlerine kıyasla ne kadar küçük olduğunu görmek sizi şaşırtabilir. Sadece ihtiyaç duydukları IOPS'u almak için 100+ diskli databaes gördüm. Ama gerçekten, bugün, SSD satın alıyorsunuz ve boyutlarını artırıyorsunuz - IOPS yeteneklerinde çok üstündürler, bu oyunda SAS sürücülerle savaşmanın bir anlamı yok.

Ve evet, IOPS numaralarınız donanım için kötü görünmüyor. Ne beklenir içinde.


6

Ödeyebiliyorsanız, geri yazma için yapılandırılmış pil destekli RAM ile kendi denetleyicisindeki ayrı bir RAID 1 çift sürücüye pg_xlog koyun. Her şey SSD üzerindeyken pg_xlog için eğirme pas kullanmanız gerekse bile bu doğrudur.

SSD kullanıyorsanız, güç arızasıyla ilgili tüm önbelleğe alınmış verileri devam ettirmek için süper kapasitör veya başka yollara sahip olduğundan emin olun.

Genel olarak, daha fazla iğ daha fazla G / Ç bant genişliği anlamına gelir.


Ne yazık ki, baskın denetleyicide sadece dört hdd yuvası var. Diğer tüm diskler SSD'lerse neden pg_xlog'ları ayrı bir diziye koydunuz?
Niels Kristian

2
@NielsKristian Çoğu sistemde işlem günlüğünün disk üzerindeki en çok yazılan şey olduğunu söylediğimde haklı olduğumu düşünüyorum. Ayrıca, yazma işlemi temelde veri yazma ile paralel olarak gerçekleşir. İkisi bir diskle aynı anda yapılamaz, çünkü kafa pg_xlog'da veya veri klasörlerinde bulunur. (Ciddi basitleştirme uyarısı!) İki görevin ayrılması, IO yükünü iki bağımsız disk / diziye böler.
dezso

2
@Dezso söylediklerine ek olarak, erişim neredeyse tamamen sıralı olduğu için sabit diskler WAL'a adanmış depolama için uygundur, bu yüzden arama süresi çok azdır ..
kgrittn

1

Linux'ta çalıştığınızı varsayarsak, disk GÇ zamanlayıcısını ayarladığınızdan emin olun.

Geçmiş deneyimlerden, noop'a geçmek size oldukça önemli bir hız kazandıracaktır (özellikle SSD için).

G / Ç zamanlayıcısının değiştirilmesi, kesinti olmadan anında gerçekleştirilebilir.

yani. echo noop> / sys / block // kuyruk / zamanlayıcı

Daha fazla bilgi için, bkz. Http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/ .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.