Як оптимізувати базу даних для великого вводу / виводу з оновлень (програмного та апаратного забезпечення)


20

У мене є база даних postgresql 9.2, яка весь час сильно оновлюється. Отже, система пов'язана з входом / виводом, і я зараз розглядаю можливість зробити ще одне оновлення, мені просто потрібні деякі вказівки щодо того, з чого почати вдосконалюватись.

Ось картина, як виглядала ситуація за останні 3 місяці:

введіть тут опис зображення

Як бачите, оновлюйте операційні рахунки для більшої частини використання диска. Ось ще одна картина того, як виглядає ситуація у більш детальному 3-годинному вікні:

введіть тут опис зображення

Як бачите, пікова швидкість запису становить близько 20 МБ / с

Програмне забезпечення На сервері працює ubuntu 12.04 і postgresql 9.2. Тип оновлень невеликий, оновлюється, як правило, на окремих рядках, визначених ідентифікатором. Напр UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id. Я видалив та оптимізував індекси наскільки я думаю, що це можливо, і конфігурація серверів (як Linux Linux, так і postgres conf) також досить оптимізована.

Обладнання Апаратне забезпечення - це спеціалізований сервер з 32 ГБ оперативної пам’яті ECC, 4x 600 ГБ 15.000 об / хв SAS дисками в масиві RAID 10, керований рейсовим контролером LSI з BBU та процесором Intel Xeon E3-1245 Quadcore.

Запитання

  • Чи доцільна ефективність графіків розумна для системи цього калібру (читання / запис)?
  • Чи слід, отже, зосередитись на здійсненні оновлення обладнання або глибшому дослідженні програмного забезпечення (налаштування ядра, конфс, запити тощо)?
  • Якщо ви робите апаратне оновлення, чи є кількість дисків ключовою для продуктивності?

------------------------------ ОНОВЛЕННЯ ------------------- ----------------

Зараз я оновив мій сервер баз даних чотирма SSD 520 Intel замість старих 15k SAS дисків. Я використовую той же контролер рейду. Все значно покращилося, як видно з наступних пікових показників вводу / виводу покращилися приблизно в 6-10 разів - і це чудово !. введіть тут опис зображення Однак я очікував щось подібне на покращення в 20-50 разів відповідно до відповідей та можливостей вводу / виводу нових SSD. Тож тут іде інше питання.

Нове запитання: Чи є в моїй поточній конфігурації щось, що обмежує продуктивність вводу / виводу моєї системи (де вузьке місце)?

Мої конфігурації:

/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: "Асинхронна фіксація - це варіант, який дозволяє операціям завершуватися швидше, за рахунок того, що можуть бути втрачені останні операції, якщо база даних буде збій."
dezso

@dezso Я мав би бути більш чітким щодо розділу документів, про який я мав на увазі. Дякуємо за роз’яснення. Причиною цього я став той факт, що один з наших серверів під великим навантаженням (використовуючи Hibernate) страждав, тому я прийняв обгрунтоване рішення перейти на фіксацію асинхронізації, і 40% навантаження практично зникло. Не рекомендується для більшості систем, але в деяких випадках це може придбати вам час між оновленнями сервера та зміною додатків.
bma

Відповіді:


10

Якщо ви робите апаратне оновлення, чи є кількість дисків ключовою для продуктивності?

Так, оскільки жорсткий диск - навіть SAS - має голову, яка потребує часу для переміщення.

Хочете оновлення HUGH?

Вбийте диски SAS, перейдіть до SATA. Підключіть SATA SSD - рівень підприємства, як у Samsung 843T.

Результат? Ви можете зробити близько 60 000 (тобто 60 тисяч) IOPS за привід.

З цієї причини SSD є вбивцями в просторі БД і настільки дешевше, ніж будь-який диск SAS. Прядильний диск Phyiscal просто не може йти в ногу з можливостями IOPS дисків.

Ваші диски SAS були посереднім вибором для початку (занадто великий, щоб отримати багато IOPS) Для бази даних з більш високим рівнем використання (більше менших дисків означало б набагато більше IOPS), але в кінці SSD тут змінюється гра.

Щодо програмного забезпечення / ядра. Будь-яка гідна база даних зробить багато IOPS та очистить буфери. Файл журналу повинен бути ПИСАНО, щоб забезпечити основні умови кислотної кислоти. Єдині мелодії ядра, які ви могли б зробити, призведе до того, що ви втратите цілісність транзакцій - частково ви МОЖЕТЕ відмовитися від цього. Контролер Raid в режимі зворотного запису зробить це - підтвердить запис як розмитий, навіть якщо його немає - але він може це зробити, оскільки BBU повинен захищати день, коли живлення вийде з ладу. Все, що ви робите вище в ядрі - краще знайте, що можете жити з негативними побічними ефектами.

Зрештою, базам даних потрібен IOPS, і ви можете здивуватися, побачивши, наскільки крихітна ваша установка порівняна з деякими іншими тут. Я бачив бази даних зі 100+ дисками лише для того, щоб отримати необхідні IOPS. Але насправді сьогодні ви купуєте SSD і переходите за розмірами на них - вони настільки перевершують можливості IOPS, що не має сенсу боротися з цією грою з дисками SAS.

І так, ваші номери IOPS не виглядають погано для обладнання. У межах того, що я б очікував.


6

Якщо ви можете собі це дозволити, поставте pg_xlog на окрему пару приводів RAID 1 на власному контролері з оперативною пам’яттю, що підтримується батареєю, налаштованою для зворотного запису. Це справедливо, навіть якщо вам потрібно використовувати спінінг іржі для pg_xlog, поки все інше знаходиться на SSD.

Якщо ви використовуєте SSD, переконайтеся, що у нього є суперконденсатор або інші засоби для збереження всіх кешованих даних щодо відключення живлення.

Загалом, більше шпинделів означає більшу пропускну здатність вводу / виводу.


На жаль, у мене тільки чотири hdd-слоти в рейдовому контролері. Навіщо ви ставите pg_xlogs на окремий масив, якщо всі інші диски були SSD?
Нільс Крістіан

2
@NielsKristian Я думаю, що я маю рацію, коли кажу, що в більшості систем журнал транзакцій є найбільш сильно написаною справою на диску. Також його запис відбувається в основному паралельно запису даних. Це неможливо зробити одночасно з жорстким диском, оскільки головка знаходиться в pg_xlog або в папках даних. (Серйозне попередження про спрощення!) Розділення двох завдань розділяє навантаження на IO на два незалежні диски / масиви.
dezso

2
На додаток до того, що сказав @dezso, жорсткі диски в порядку для зберігання, призначеного для WAL, оскільки доступ майже повністю послідовний, тому час пошуку мінімальний ..
kgrittn

1

Якщо припустимо, що ви працюєте в Linux, не забудьте встановити диспетчер IO диска.

З досвіду минулого, перехід на noop дасть вам досить значну швидкість (особливо для SSD).

Зміна планувальника вводу-виводу може бути здійснено на ходу без простоїв.

тобто. echo noop> / sys / block // черга / планувальник

Дивіться: http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/ для отримання додаткової інформації.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.