Bagaimana cara mengoptimalkan basis data untuk I / O berat dari pembaruan (perangkat lunak dan perangkat keras)


20

Situasi saya memiliki database postgresql 9.2 yang cukup banyak diperbarui sepanjang waktu. Sistem karenanya terikat I / O, dan saya saat ini sedang mempertimbangkan untuk melakukan peningkatan lain, saya hanya perlu beberapa petunjuk tentang di mana mulai meningkatkan.

Berikut adalah gambaran bagaimana situasi terlihat dalam 3 bulan terakhir:

masukkan deskripsi gambar di sini

Seperti yang Anda lihat, perbarui akun operasi untuk sebagian besar pemanfaatan disk. Berikut adalah gambaran lain tentang bagaimana situasi terlihat dalam jendela 3 jam yang lebih rinci:

masukkan deskripsi gambar di sini

Seperti yang Anda lihat, laju penulisan puncak adalah sekitar 20MB / s

Perangkat Lunak Server menjalankan ubuntu 12.04 dan postgresql 9.2. Jenis pembaruan kecil diperbarui biasanya pada baris individual yang diidentifikasi oleh ID. Misalnya UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id. Saya telah menghapus dan mengoptimalkan indeks sebanyak yang saya pikir mungkin, dan konfigurasi server (baik kernel linux dan postgres conf) juga cukup optimal.

Perangkat Keras Perangkat keras adalah server khusus dengan RAM ECC 32GB, disk SAS 4x60GB 15.000 rpm dalam array RAID 10, dikendalikan oleh pengontrol serangan LSI dengan BBU dan prosesor Intel Xeon E3-1245 Quadcore.

Pertanyaan

  • Apakah kinerja yang dilihat oleh grafik masuk akal untuk sistem kaliber ini (baca / tulis)?
  • Maka apakah saya harus fokus melakukan upgrade perangkat keras atau menyelidiki lebih dalam perangkat lunak (tweaking kernel, confs, query, dll.)?
  • Jika melakukan peningkatan perangkat keras, apakah jumlah disk adalah kunci kinerja?

------------------------------MEMPERBARUI------------------- ----------------

Saya sekarang telah memutakhirkan server basis data saya dengan empat intel 520 SSD bukan disk SAS 15k yang lama. Saya menggunakan pengontrol serangan yang sama. Banyak hal telah meningkat cukup banyak, seperti yang dapat Anda lihat dari mengikuti puncak kinerja I / O telah meningkat sekitar 6-10 kali - dan itu hebat !. masukkan deskripsi gambar di sini Namun, saya mengharapkan sesuatu yang lebih seperti peningkatan 20-50 kali sesuai dengan jawaban dan kemampuan I / O dari SSD baru. Jadi begini pertanyaan lain.

Pertanyaan baru Apakah ada sesuatu dalam konfigurasi saya saat ini, yang membatasi kinerja I / O sistem saya (di mana bottleneck)?

Konfigurasi saya:

/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

Output dari 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). Jika kolom tidak diindeks, Anda dapat memanfaatkan HOT (lihat git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/… ). (2) Coba dengan synchronous_commit = off, setelah membaca dokumen di postgresql.org/docs/9.2/static/wal-async-commit.html . (3) Seperti apa konfigurasi Anda? Misalnya. hasil dari permintaan ini:SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');
bma

@ bma Izinkan saya menambahkan peringatan tentang synchronous_commit: 'Komit asinkron adalah opsi yang memungkinkan transaksi diselesaikan lebih cepat, dengan biaya transaksi paling baru mungkin hilang jika database macet.'
dezso

@dezso saya seharusnya lebih eksplisit tentang bagian dokumen yang saya maksud. Terimakasih atas klarifikasinya. Alasan saya mengemukakan hal itu adalah karena salah satu server kami di bawah beban tinggi (menggunakan Hibernate) menderita sehingga saya membuat keputusan untuk beralih ke async commit dan 40% dari beban hampir hilang. Tidak direkomendasikan untuk sebagian besar sistem, tetapi dalam kasus tertentu dapat memberi Anda waktu antara peningkatan server dan perubahan aplikasi.
bma

Jawaban:


10

Jika melakukan peningkatan perangkat keras, apakah jumlah disk adalah kunci kinerja?

Ya, sebagai cakram keras - bahkan SAS - memiliki kepala yang membutuhkan waktu untuk bergerak.

Ingin peningkatan HUGH?

Bunuh cakram SAS, buka SATA. Sambungkan SATA SSD - tingkat perusahaan, seperti Samsung 843T.

Hasil? Anda dapat melakukan sekitar 60.000 (yaitu 60 ribu) IOPS per drive.

Inilah sebabnya SSD adalah pembunuh di ruang DB dan jauh lebih murah daripada drive SAS. Disc pemintalan phyiscal tidak bisa mengimbangi kemampuan IOPS dari disk.

Cakram SAS Anda adalah pilihan biasa-biasa saja untuk memulai (terlalu besar untuk mendapatkan banyak IOPS) Untuk basis data penggunaan yang lebih tinggi (lebih banyak cakram yang lebih kecil akan berarti lebih banyak IOPS), tetapi pada akhirnya SSD adalah pengubah permainan di sini.

Mengenai perangkat lunak / kernel. Setiap basis data yang layak akan melakukan banyak IOPS dan menyiram buffer. File log ini harus dituliskan agar kondisi dasar ACID dijamin. Satu-satunya nada kernel yang dapat Anda lakukan akan membatalkan integritas transaksional Anda - sebagian Anda BISA lolos begitu saja. Kontroler Raid dalam mode tulis kembali akan melakukan itu - konfirmasikan bahwa penulisan telah memerah walaupun tidak - tetapi ia dapat melakukannya karena BBU diasumsikan aman pada hari ketika listrik mati. Apa pun yang Anda lakukan lebih tinggi di kernel - lebih baik tahu Anda bisa hidup dengan efek samping negatif.

Pada akhirnya, basis data membutuhkan IOPS, dan Anda mungkin terkejut melihat betapa kecilnya pengaturan Anda dibandingkan dengan yang lain di sini. Saya telah melihat databas dengan 100+ cakram hanya untuk mendapatkan IOPS yang mereka butuhkan. Tapi sungguh, hari ini, Anda membeli SSD dan menggantinya - mereka sangat unggul dalam kemampuan IOPS, tidak masuk akal untuk melawan game ini dengan drive SAS.

Dan ya, nomor IOPS Anda tidak terlihat buruk untuk perangkat kerasnya. Dalam apa yang saya harapkan.


6

Jika Anda mampu membelinya, letakkan pg_xlog pada drive RAID 1 yang terpisah pada pengontrolnya sendiri dengan RAM yang didukung baterai yang dikonfigurasi untuk write-back. Ini benar bahkan jika Anda perlu menggunakan spinning rust untuk pg_xlog sementara yang lainnya menggunakan SSD.

Jika Anda menggunakan SSD, pastikan SSD memiliki kapasitor super atau cara lain untuk mempertahankan semua data cache tentang kegagalan daya.

Secara umum, lebih banyak spindel berarti lebih banyak bandwidth I / O.


Sayangnya saya hanya memiliki empat slot hdd di pengontrol serangan. Mengapa Anda meletakkan pg_xlog pada array yang terpisah, jika semua disk lain milik SSD?
Niels Kristian

2
@NielsKristian Saya pikir saya benar ketika saya mengatakan bahwa dalam kebanyakan sistem log transaksi adalah hal yang paling banyak ditulis pada disk. Juga, penulisan itu pada dasarnya paralel dengan penulisan data. Keduanya tidak dapat dilakukan bersamaan dengan HDD karena kepalanya ada di pg_xlog atau di folder data. (Peringatan penyederhanaan serius!) Memisahkan dua tugas membagi beban IO pada dua disk / array independen.
dezso

2
Selain apa yang dikatakan @dezso, hard drive tidak apa-apa untuk penyimpanan yang didedikasikan untuk WAL karena aksesnya hampir seluruhnya berurutan, jadi cari waktu yang minimal ..
kgrittn

1

Dengan asumsi Anda menjalankan di Linux, pastikan untuk mengatur penjadwal IO disk.

Dari pengalaman masa lalu, beralih ke noop akan memberi Anda kecepatan yang cukup besar (terutama untuk SSD).

Mengubah penjadwal IO dapat dilakukan dengan cepat tanpa downtime.

yaitu. echo noop> / sys / block // queue / scheduler

Lihat: http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/ untuk informasi lebih lanjut.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.