web-dev-qa-db-ja.com

更新（ソフトウェアおよびハードウェア）による大量のI / Oのためにデータベースを最適化する方法

状況常に大幅に更新されているpostgresql 9.2データベースがあります。したがって、システムはI/Oバウンドであり、現在別のアップグレードを検討しています。どこから改善を開始するかを指示するだけです。

過去3か月の状況を次に示します。

enter image description here

ご覧のとおり、更新操作はディスク使用率のほとんどを占めています。以下は、より詳細な3時間のウィンドウで状況がどのように見えるかを示す別の画像です。

enter image description here

ご覧のとおり、ピーク書き込み速度は約20MB/sです。

ソフトウェアサーバーはubuntu 12.04とpostgresql 9.2を実行しています。更新の種類は、通常、IDで識別される個々の行に対して小規模に更新されます。例えば。 UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id。可能な限りインデックスを削除して最適化しました。サーバー構成（Linuxカーネルとpostgres confの両方）もかなり最適化されています。

ハードウェアハードウェアは、32GB ECCラム、4x 600GB 15.000 rpmの専用サーバーですSAS RAID 10アレイのディスク、BBUおよびIntel Xeon E3-1245 Quadcoreプロセッサ。

質問

  • グラフで見られるパフォーマンスは、この口径のシステム（読み取り/書き込み）に対して妥当ですか？
  • したがって、ハードウェアのアップグレードに集中するか、ソフトウェアの詳細を調査する必要がありますか（カーネルの微調整、conf、クエリなど）？
  • ハードウェアのアップグレードを行う場合、ディスクの数はパフォーマンスにとって重要ですか？

- - - - - - - - - - - - - - - - 更新 - - - - - - - - --------------------

これで、データベースサーバーを古い15k SASディスクの代わりに4つのintel 520 SSDでアップグレードしました。同じRAIDコントローラを使用しています。次のピークI/Oパフォーマンスは約6〜10倍向上しました。それは素晴らしいことです。 enter image description here しかし、新しいSSDの回答とI/O機能によると、20〜50倍の改善が期待されていました。だからここに別の質問があります。

新しい質問現在の構成に何かありますか？それは私のシステムのI/Oパフォーマンスを制限しています（ボトルネックはどこですか？）

私の構成：

/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 [email protected]:/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

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
postgresqlperformanceupdatehardware
20
Niels Kristian

ハードウェアのアップグレードを行う場合、ディスクの数はパフォーマンスにとって重要ですか？

はい、ハードディスクとして-SAS-でも、動くのに時間がかかるヘッドがあります。

大きなアップグレードが必要ですか？

SASディスクを殺し、SATAに移動します。SATASSDを接続します-Samsung 843Tのようなエンタープライズレベル。

結果？ドライブあたり約60.000（つまり60 000）IOPSを実行できます。

これが、SSDがDB領域のキラーであり、他のどのドライブよりもはるかに安価である理由ですSASドライブ。Phyiscalスピニングディスクは、ディスクのIOPS機能に対応できません。

あなたのSASディスクは、最初は平凡な選択でした（大きすぎて多くのIOPSを取得するには大きすぎます）。使用頻度の高いデータベースの場合（ディスクが小さいほど、IOPSが多くなることを意味します） SSDはここでのゲームチェンジャーです。

ソフトウェア/カーネルについて。適切なデータベースは、多くのIOPSを実行し、バッファをフラッシュします。基本的なACID状態を保証するには、ログファイルを書き込む必要があります。実行できる唯一のカーネル調整は、トランザクションの整合性を無効にします-部分的にはそれでうまくいくことができます。ライトバックモードのRAIDコントローラはそれを行います-フラッシュされていない場合でも書き込みがフラッシュされていることを確認します-しかし、電源が落ちた日はBBUが安全であると想定されているため、フラッシュを行うことができます。カーネルの上位にあること-否定的な副作用に耐えられることをよく理解してください。

最後に、データベースにはIOPSが必要です。ここで、ご使用の設定が他の設定と比較してどれほど小さいかを見て驚かれるかもしれません。必要なIOPSを取得するためだけに、100枚以上のディスクでデータベースを確認しました。しかし、実際には、今日、SSDを購入し、そのサイズを試してください。IOPS機能が非常に優れているため、このゲームをSASドライブで戦うことは意味がありません。

そして、はい、あなたのIOPSの数値はハードウェアに問題がないように見えます。私が期待する範囲内で。

10
TomTom

余裕がある場合は、pg_xlogを、バッテリーでバックアップされた独自のコントローラーのRAID 1ペアのドライブに配置しますRAMライトバック用に構成されています。これは、スピニングを使用する必要がある場合でも当てはまります。 Rust pg_xlogの場合、他はすべてSSD上にあります。

SSDを使用する場合は、電源障害時にキャッシュされたすべてのデータを保持するスーパーコンデンサーまたはその他の手段がSSDにあることを確認してください。

一般に、スピンドルが多いほど、I/O帯域幅が大きくなります。

6
kgrittn

Linuxで実行している場合は、必ずディスクIOスケジューラーを設定してください。

過去の経験から、noopに切り替えるとかなり高速になります（特にSSDの場合）。

IOスケジューラの変更は、ダウンタイムなしでオンザフライで実行できます。

すなわち。 echo noop>/sys/block // queue/scheduler

詳細については、 http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/ を参照してください。

1
Paul Miles