วิธีเพิ่มประสิทธิภาพฐานข้อมูลสำหรับ I / O หนักจากการอัปเดต (ซอฟต์แวร์และฮาร์ดแวร์)


20

สถานการณ์ ฉันมีฐานข้อมูล postgresql 9.2 ซึ่งค่อนข้างมีการปรับปรุงอย่างมากตลอดเวลา ระบบจึงถูก จำกัด ด้วย I / O และตอนนี้ฉันกำลังพิจารณาที่จะอัพเกรดอีกครั้งฉันแค่ต้องการทิศทางที่จะเริ่มปรับปรุง

นี่คือภาพว่าสถานการณ์ดู 3 เดือนที่ผ่านมาได้อย่างไร:

ป้อนคำอธิบายรูปภาพที่นี่

อย่างที่คุณเห็นอัปเดตบัญชีการปฏิบัติงานสำหรับการใช้งานดิสก์ส่วนใหญ่ นี่เป็นอีกภาพของการมองสถานการณ์ในหน้าต่าง 3 ชั่วโมงที่มีรายละเอียดมากขึ้น:

ป้อนคำอธิบายรูปภาพที่นี่

อย่างที่คุณเห็นอัตราการเขียนสูงสุดคือประมาณ 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 ram, 4x 600GB 15.000 รอบต่อนาทีดิสก์ SAS ในอาร์เรย์ RAID 10 ควบคุมโดย LSI RAID คอนโทรลเลอร์ที่มี BBU และโปรเซสเซอร์ Intel Xeon E3-1245 Quadcore

คำถาม

  • ประสิทธิภาพการทำงานของกราฟนั้นสมเหตุสมผลสำหรับระบบที่มีความสามารถนี้ (อ่าน / เขียน) หรือไม่?
  • ดังนั้นฉันจึงควรมุ่งเน้นไปที่การอัพเกรดฮาร์ดแวร์หรือตรวจสอบลึกเข้าไปในซอฟต์แวร์ (เคอร์เนล tweaking, confs, แบบสอบถาม ฯลฯ )?
  • หากทำการอัปเกรดฮาร์ดแวร์หมายเลขดิสก์จะมีผลต่อประสิทธิภาพหรือไม่

------------------------------ UPDATE ------------------- ----------------

ตอนนี้ฉันได้อัพเกรดเซิร์ฟเวอร์ฐานข้อมูลของฉันด้วย Intel 520 SSD สี่ตัวแทนที่จะเป็นดิสก์ SAS ขนาด 15k ตัวเก่า ฉันกำลังใช้ตัวควบคุมการโจมตีตัวเดียวกัน สิ่งต่าง ๆ ได้รับการปรับปรุงให้ดีขึ้นมากอย่างที่คุณเห็นจากประสิทธิภาพการทำงานของ I / O ที่ดีขึ้นดังต่อไปนี้ดีขึ้นประมาณ 6-10 ครั้ง - และนั่นยอดเยี่ยมมาก! ป้อนคำอธิบายรูปภาพที่นี่ อย่างไรก็ตามฉันคาดหวังว่าจะมีการปรับปรุงให้ดีขึ้นกว่า 20-50 เท่าตามคำตอบและความสามารถของ I / O ของ SSD ใหม่ ดังนั้นที่นี่คำถามอื่นไป

คำถามใหม่ มีบางสิ่งในการกำหนดค่าปัจจุบันของฉันซึ่ง จำกัด ประสิทธิภาพของ 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 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

ผลผลิตของ 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) หากคอลัมน์ไม่ได้ถูกจัดทำดัชนีคุณสามารถใช้ประโยชน์จาก HOT (ดูgit.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/ … ) (2) ลองด้วยsynchronous_commit = offหลังจากที่ได้อ่านเอกสารที่postgresql.org/docs/9.2/static/wal-async-commit.html (3) การกำหนดค่าของคุณมีลักษณะอย่างไร เช่น. ผลการค้นหานี้:SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');
bma

@bma ให้ฉันเพิ่มคำเตือนเกี่ยวกับsynchronous_commit: 'Asynchronous กระทำเป็นตัวเลือกที่ช่วยให้การทำธุรกรรมเสร็จเร็วขึ้นในราคาที่การทำธุรกรรมล่าสุดอาจหายไปหากฐานข้อมูลควรผิดพลาด'
dezso

@dezso ฉันควรจะชัดเจนมากขึ้นเกี่ยวกับส่วนของเอกสารที่ฉันอ้างถึง ขอขอบคุณสำหรับการชี้แจง. เหตุผลที่ฉันพูดถึงเรื่องนี้ก็เพราะเซิร์ฟเวอร์ของเราที่มีภาระสูง (ใช้ไฮเบอร์เนต) กำลังทนทุกข์ดังนั้นฉันจึงตัดสินใจอย่างชาญฉลาดเพื่อเปลี่ยนมาใช้ async commit และ 40% ของภาระงานหายไปจริง ไม่แนะนำสำหรับระบบส่วนใหญ่ แต่ในบางกรณีอาจซื้อเวลาให้คุณได้ระหว่างการอัปเกรดเซิร์ฟเวอร์และการเปลี่ยนแปลงแอปพลิเคชัน
bma

คำตอบ:


10

หากทำการอัปเกรดฮาร์ดแวร์หมายเลขดิสก์จะมีผลต่อประสิทธิภาพหรือไม่

ใช่ในฐานะฮาร์ดดิสก์ - แม้แต่ SAS - มีหัวที่ต้องใช้เวลาในการเคลื่อนย้าย

ต้องการอัปเกรด HUGH หรือไม่

ทำลายดิสก์ SAS ไปที่ SATA เสียบ SATA SSD - ระดับองค์กรเช่น Samsung 843T

ผล? คุณสามารถทำประมาณ 60.000 (นั่นคือ 60,000) IOPS ต่อไดรฟ์

นี่คือเหตุผลที่ SSD เป็นนักฆ่าในพื้นที่ DB และราคาถูกกว่าไดรฟ์ SAS มาก ดิสก์การหมุนแบบ Phyiscal ไม่สามารถติดตามความสามารถของดิสก์ IOPS ได้

ดิสก์ SAS ของคุณเป็นแบบปานกลางเลือกที่จะเริ่มต้นด้วย (มีขนาดใหญ่เกินกว่าที่จะได้รับ IOPS มาก) สำหรับฐานข้อมูลการใช้งานที่สูงขึ้น (ดิสก์ที่เล็กกว่าจะหมายถึง IOPS มากขึ้น) แต่สุดท้าย SSD เป็นตัวเปลี่ยนเกมที่นี่

เกี่ยวกับซอฟต์แวร์ / เคอร์เนล ฐานข้อมูลที่เหมาะสมใด ๆ ที่จะทำมากของ IOPS และล้างบัฟเฟอร์ ไฟล์บันทึกเหล่านั้นจะต้องมี WRITTEN เพื่อให้แน่ใจว่าสามารถรับประกันเงื่อนไขกรดพื้นฐาน เคอร์เนลเพลงเดียวที่คุณสามารถทำได้จะทำให้ความสมบูรณ์ของธุรกรรมของคุณเป็นโมฆะ - บางส่วนที่คุณสามารถหลีกเลี่ยงได้ ตัวควบคุม Raid ในโหมดเขียนกลับจะทำเช่นนั้น - ยืนยันการเขียนเป็นฟลัชแม้ว่าจะไม่ได้ - แต่ก็สามารถทำได้เพราะ BBU จะถือว่าปลอดภัยในวันที่ไฟฟ้าดับ ทุกสิ่งที่คุณทำสูงขึ้นในเคอร์เนล - ดีกว่ารู้ว่าคุณสามารถอยู่กับผลข้างเคียงเชิงลบ

ในตอนท้ายฐานข้อมูลต้องการ IOPS และคุณอาจประหลาดใจที่เห็นว่าการตั้งค่าของคุณมีขนาดเล็กเมื่อเทียบกับที่อื่น ๆ ที่นี่ ฉันได้เห็นดาต้าบาส์ที่มีแผ่นดิสก์มากกว่า 100 แผ่นเพื่อรับ IOPS ที่ต้องการ แต่จริงๆแล้ววันนี้คุณซื้อ SSD แล้วเพิ่มขนาดให้กับมัน - มันยอดเยี่ยมมากในความสามารถของ IOPS มันไม่สมเหตุสมผลเลยที่จะต่อสู้กับเกมนี้ด้วยไดรฟ์ SAS

และใช่เลข IOPS ของคุณดูไม่ดีสำหรับฮาร์ดแวร์ ภายในสิ่งที่ฉันคาดหวัง


6

หากคุณสามารถซื้อได้ให้วาง pg_xlog ในไดรฟ์ RAID 1 คู่แยกต่างหากบนคอนโทรลเลอร์ของตัวเองพร้อม RAM ที่สำรองแบตเตอรี่ซึ่งกำหนดค่าไว้สำหรับการเขียนกลับ สิ่งนี้เป็นจริงแม้ว่าคุณจะต้องใช้การเกิดสนิมหมุนสำหรับ pg_xlog ในขณะที่ทุกอย่างอยู่ใน SSD

หากคุณใช้ SSD ตรวจสอบให้แน่ใจว่ามีตัวเก็บประจุพิเศษหรือวิธีการอื่นเพื่อคงข้อมูลที่แคชไว้ทั้งหมดเมื่อไฟฟ้าขัดข้อง

โดยทั่วไปแกนหมุนที่มากขึ้นหมายถึงแบนด์วิดธ์ของ I / O ที่มากขึ้น


น่าเสียดายที่ฉันมีช่อง hdd เพียงสี่ช่องในตัวควบคุมการโจมตี ทำไมคุณต้องวาง pg_xlogs ในอาร์เรย์ที่แยกต่างหากถ้าดิสก์อื่นทั้งหมดเป็น SSD
Niels Kristian

2
@NielsKristian ฉันคิดว่าฉันพูดถูกในระบบส่วนใหญ่บันทึกธุรกรรมเป็นสิ่งที่เขียนอย่างหนักที่สุดบนแผ่นดิสก์ นอกจากนี้การเขียนมันเกิดขึ้นโดยทั่วไปขนานกับการเขียนข้อมูล ทั้งสองไม่สามารถทำได้พร้อมกันกับ HDD เนื่องจากส่วนหัวอยู่ใน pg_xlog หรือในโฟลเดอร์ข้อมูล (การแจ้งเตือนการทำให้เข้าใจง่ายอย่างจริงจัง!) การแยกงานสองอย่างนี้แยกภาระ IO ในสองดิสก์ / อาร์เรย์อิสระ
dezso

2
นอกจากสิ่งที่ @dezso กล่าวแล้วฮาร์ดไดรฟ์ก็โอเคสำหรับการจัดเก็บข้อมูลที่ทุ่มเทให้กับ WAL เพราะการเข้าถึงนั้นเกือบจะเป็นลำดับทั้งหมดดังนั้นเวลาในการค้นหาจึงน้อยมาก ..
kgrittn

1

สมมติว่าคุณกำลังใช้งานบน Linux โปรดตั้งค่าตัวกำหนดตารางเวลา IO ของดิสก์

จากประสบการณ์ที่ผ่านมาการเปลี่ยนมาใช้ noop จะทำให้คุณมีความเร็วมากพอสมควร (โดยเฉพาะสำหรับ SSD)

การเปลี่ยนกำหนดการของ IO สามารถทำได้ทันทีโดยไม่ต้องหยุดทำงาน

กล่าวคือ echo noop> / sys / block // queue / scheduler

ดู: http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/สำหรับข้อมูลเพิ่มเติม

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.