|
dd vs WAL performance
|
|||
---|---|---|---|
#18+
Добрый день. Новичёк в postgres, прошу сильно не пинать. Но есть богатый опыт с Oracle и знакомство с DB2 & SQLServer. Есть относительно неплохое железо: 16G RAM +i7+ 1 ssd +2 магнитных HDD Есть OS Astra Linux Смоленск 1.3 в которую входит докрученный на мандатный доступ РусБиТех'ом Postgersql 9.3... Журналы Postgres положил на ssd, остальной кластер на один магнитный HDD. Пытаюсь оценить производительность... 1. dd if=/dev/zero of=.... блоком по 8К получаю примерно 410 MByte/sec - считаю нормально, напоминает характеристики ssd от производителя. 2. Выполняю тест самописной прогой, которая вставляет 6 int полей в одну таблицу в одну сессию, и после каждой вставки делает autocommit. Пытаюсь вставить 100 тыс. записей. Прога писана мной на С. Наблюдаю за системой средствами iostat и вижу ну совершенно низкую скорость write на ssd ~ 8.5 MByte/sec при этом device busy (или как он там правильно...) около 90%. На магнитном HDD нагрузки практически нет. Пробовал подкручивать WAL параметрами, но не получил видимого прироста. Прога запускается локально, т.е. на сервере где стоит postgres. Если выполнить эту же работу (100 тыс. insert) в одной транзакции процедурой на pgplsql, то это занимает примерно 2-3 секунды, тогда как в тесте примерно 140 секунд . Я понимаю, что autocommit после каждой вставки это не правильно, но это тест такой. commit должен быть после каждой вставки. Вот не пробовал просто commit, без auto-. Подскажите плс., что бы можно было настроить ещё. Очень буду признателен. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2017, 22:40 |
|
dd vs WAL performance
|
|||
---|---|---|---|
#18+
mike_pg_123, Наоборот сделайте — WAL и ОС на железки, т.к. ОС практически ничего не должна делать (в сравнении с базой), а WAL суть последовательная запись. А саму базу на SSD. Вот только 9.3 довольно старая версия, сейчас бы уже 9.6 надо пользовать. При фиксировании транзакций (и умолчательных настройках) база будет писать в журнал (последовательно) и сохранять изменения в кэш. По мере заполнения кэша/потребности в кэше другими запросами/таймауту база будет сохранять страницы из кэша на диск, произвольной записью (с 9.6 страницы упорядочиваются так, чтобы по максимуму последовательно писать). Т.е. если вы не меняете страниц больше, чем есть в кэше — база все манипуляции только в памяти сделает. И большой записи вы не увидите. Посмотрите в сторону `pgbench` для тестов. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2017, 00:11 |
|
dd vs WAL performance
|
|||
---|---|---|---|
#18+
mike_pg_123Добрый день. Новичёк в postgres, прошу сильно не пинать. Но есть богатый опыт с Oracle и знакомство с DB2 & SQLServer. Есть относительно неплохое железо: 16G RAM +i7+ 1 ssd +2 магнитных HDD Есть OS Astra Linux Смоленск 1.3 в которую входит докрученный на мандатный доступ РусБиТех'ом Postgersql 9.3... Журналы Postgres положил на ssd, остальной кластер на один магнитный HDD. Пытаюсь оценить производительность... 1. dd if=/dev/zero of=.... блоком по 8К получаю примерно 410 MByte/sec - считаю нормально, напоминает характеристики ssd от производителя. 2. Выполняю тест самописной прогой, которая вставляет 6 int полей в одну таблицу в одну сессию, и после каждой вставки делает autocommit. Пытаюсь вставить 100 тыс. записей. Прога писана мной на С. Наблюдаю за системой средствами iostat и вижу ну совершенно низкую скорость write на ssd ~ 8.5 MByte/sec при этом device busy (или как он там правильно...) около 90%. На магнитном HDD нагрузки практически нет. Пробовал подкручивать WAL параметрами, но не получил видимого прироста. Прога запускается локально, т.е. на сервере где стоит postgres. Если выполнить эту же работу (100 тыс. insert) в одной транзакции процедурой на pgplsql, то это занимает примерно 2-3 секунды, тогда как в тесте примерно 140 секунд . Я понимаю, что autocommit после каждой вставки это не правильно, но это тест такой. commit должен быть после каждой вставки. Вот не пробовал просто commit, без auto-. Подскажите плс., что бы можно было настроить ещё. Очень буду признателен. Скорее всего у вас дешевый не серверный ssd, и он fsync медленно отрабатывает. Попробуйте syncronous_commit=off сделать в базе и еще раз потестировать. Если станет сильно быстрее - выкиньте ваш SSD и возьмите нормальный Intel s3710 или решите что для вашего приложения не критична потея последних 200ms транзакций если сервер выключат вдруг. PS: обычно рекомендуется наоборот - wal на механику а данные на ssd (потому что wal пишется линейно с чем и механика неплохо справляется. PPS: большие обьемы данных лучше через copy заливать. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2017, 05:26 |
|
|
start [/forum/topic.php?fid=53&fpage=78&tid=1996684]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 138ms |
0 / 0 |