Скорость восстановления данных со временем заметно замедляется / PostgreSQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Скорость восстановления данных со временем заметно замедляется

25 сообщений из 80, страница 3 из 4

все

Скорость восстановления данных со временем заметно замедляется

#39192188

Sheriffua

Участник

Откуда: г. Киев

Сообщения: 1 223

Рейтинг: 0 / 0

Leonid KudryavtsevSheriffuavyegorov,

Результат запароса здесь:

Могу ошибаться:

checkpoint_sync_time | 1018687
checkpoint_write_time | 46277179

По доке, в ms. Т.е. checkpoint_write_time = 46 277 179 ms = 46 277 sec = 771 min = > 12 hour
checkpoint_sync_time = 1 018 687 = 1 018 sec = 16 min

Мне одному кажется, что это ДОФИГА. Смотрим, сколько всего информации пытался записать PostgreSQL

buffers_checkpoint = 11 757 214 * 8 Kb = 94 057 712 Kb = 94 Gb

Т.е. скорость диска, если верить PostgreSQL = 94 057 712 / 46 277 179 = 2 Mb / sec

Где Вы такой SSD купили и/или кого к настройке дискового хранилища подпускали ?

Вы хотите сказать, что первые 20 Гб восстановились за 1 час для одной таблицы (общий размер восстановления составил 75 Гб, т.к. запускалось восстаноление в 4 потока), после этого скорость падает одного потока в разы, и в этом виноват SSD?

...

Рейтинг:

0 / 0

15.03.2016, 12:50

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192191

grufos

Участник

Откуда: Москва

Сообщения: 94

Рейтинг: 0 / 0

Leonid KudryavtsevКак-то мне кажется, что нагрузка на диск 9 Mb/s - это как то ни о чем.
Да, верно.
не могу сказать за linux, но на windows есть проблема с нагрузкой на диск.
Сам работаю в windows и я смог получить примерно 4-5 Mb/s .... это максимум!!!
Смог решить проблему скорости чтения данных только лишь поместив все данные в кэш (pg_prewarm)
А так, да... пока кэш не разогрет, то простейшие запросы
select * from firms where leader_fio ~ 'сидоров' limit 10 offset 20;
работали крайне медленно. Замечу сразу, что такой запрос делал именно с цель посмотреть нагрузку по чтению на диск. Сама табличка большая 3 Гб и её надо просмотреть почти всю.
Увы, как на велосипеде едем :)

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

QUERY PLAN
Limit  (cost=14686.39..22029.59 rows=10 width=444) (actual time=4179.054..5364.288 rows=10 loops=1)
  Output: id, short_name, norm_name, fns_number, reg_number, state_reg_number, id_region, id_okved, leader_fio, country_code, fts_name, fts_leader_fio, create_date, modify_date
  Buffers: shared read=90239
  I/O Timings: read=3581.307
  ->  Seq Scan on public.firms  (cost=0.00..466292.95 rows=635 width=444) (actual time=286.454..5364.267 rows=30 loops=1)
        Output: id, short_name, norm_name, fns_number, reg_number, state_reg_number, id_region, id_okved, leader_fio, country_code, fts_name, fts_leader_fio, create_date, modify_date
        Filter: ((firms.leader_fio)::text ~ 'сидоров'::text)
        Rows Removed by Filter: 1547738
        Buffers: shared read=90239
        I/O Timings: read=3581.307
Planning time: 38.715 ms
Execution time: 5364.570 ms

а вот после разогрева

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

QUERY PLAN
Limit  (cost=14686.39..22029.59 rows=10 width=444) (actual time=1788.878..2676.313 rows=10 loops=1)
  Output: id, short_name, norm_name, fns_number, reg_number, state_reg_number, id_region, id_okved, leader_fio, country_code, fts_name, fts_leader_fio, create_date, modify_date
  Buffers: shared hit=128247
  ->  Seq Scan on public.firms  (cost=0.00..466292.95 rows=635 width=444) (actual time=0.379..2676.294 rows=30 loops=1)
        Output: id, short_name, norm_name, fns_number, reg_number, state_reg_number, id_region, id_okved, leader_fio, country_code, fts_name, fts_leader_fio, create_date, modify_date
        Filter: ((firms.leader_fio)::text ~ 'сидоров'::text)
        Rows Removed by Filter: 2386078
        Buffers: shared hit=128247
Planning time: 2.017 ms
Execution time: 2676.370 ms

...

Рейтинг:

0 / 0

15.03.2016, 12:52

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192192

vyegorov

Участник

Откуда: Баньоло-ин-Пьяно

Сообщения: 1 237

Рейтинг: 0 / 0

Leonid KudryavtsevSheriffuavyegorov,

Результат запароса здесь:

Могу ошибаться:

checkpoint_sync_time | 1018687
checkpoint_write_time | 46277179

По доке, в ms. Т.е. checkpoint_write_time = 46 277 179 ms = 46 277 sec = 771 min = > 12 hour
checkpoint_sync_time = 1 018 687 = 1 018 sec = 16 min

Мне одному кажется, что это ДОФИГА. Смотрим, сколько всего информации пытался записать PostgreSQL

buffers_checkpoint = 11 757 214 * 8 Kb = 94 057 712 Kb = 94 Gb

Т.е. скорость диска, если верить PostgreSQL = 94 057 712 / 46 277 179 = 2 Mb / sec

Где Вы такой SSD купили и/или кого к настройке дискового хранилища подпускали ?

Это кумулятивные данные, смотрите также на `stats_reset`.

...

Рейтинг:

0 / 0

15.03.2016, 12:52

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192199

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Sheriffua...Вы хотите сказать, что первые 20 Гб восстановились за 1 час для одной таблицы (общий размер восстановления составил 75 Гб, т.к. запускалось восстаноление в 4 потока), после этого скорость падает одного потока в разы, и в этом виноват SSD?
Не знаю.

Я хочу сказать, что по статистике которую отслеживает PostgreSQL (если я правильно прочитал доку и правильно поделил), 12 часов ушло на работу с диском. Почему такое не очень нормальное поведение - сказать сложно.

1) Я бы вынес файлы БД на обычный жесткий диск. Теоретически, при нормально открученных параметрах памяти и загрузки в один поток, COPY должна давать более-менее ПОСЛЕДОВАТЕЛЬНЫЙ доступ к диску. Т.ч. пусть не 80 Mb/s, но честные 40 Mb/s на любом бытовом жестком диске Вы иметь должны. Сейчас наблюдается 2 Mb/s под РЕАЛЬНОЙ нагрузкой.

2) Настройка параметров checkpoint'ов, что бы их было как можно меньше.

У меня сейчас на компе аналогичное поведение SSD, правда цена у него совсем другая (6 тыс. руб) и объемы у меня другие (пара гигов).

IMHO & AFAIK. Могу ошибаться. Не админ.

...

Рейтинг:

0 / 0

15.03.2016, 12:59

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192206

Sheriffua

Участник

Откуда: г. Киев

Сообщения: 1 223

Рейтинг: 0 / 0

Leonid KudryavtsevSheriffua...Вы хотите сказать, что первые 20 Гб восстановились за 1 час для одной таблицы (общий размер восстановления составил 75 Гб, т.к. запускалось восстаноление в 4 потока), после этого скорость падает одного потока в разы, и в этом виноват SSD?
Не знаю.

Я хочу сказать, что по статистике которую отслеживает PostgreSQL (если я правильно прочитал доку и правильно поделил), 12 часов ушло на работу с диском. Почему такое не очень нормальное поведение - сказать сложно.

1) Я бы вынес файлы БД на обычный жесткий диск. Теоретически, при нормально открученных параметрах памяти и загрузки в один поток, COPY должна давать более-менее ПОСЛЕДОВАТЕЛЬНЫЙ доступ к диску. Т.ч. пусть не 80 Mb/s, но честные 40 Mb/s на любом бытовом жестком диске Вы иметь должны. Сейчас наблюдается 2 Mb/s под РЕАЛЬНОЙ нагрузкой.

2) Настройка параметров checkpoint'ов, что бы их было как можно меньше.

У меня сейчас на компе аналогичное поведение SSD, правда цена у него совсем другая (6 тыс. руб) и объемы у меня другие (пара гигов).

IMHO & AFAIK. Могу ошибаться. Не админ.

К сожалению нет места, чтобы вынести файлы БД на другой диск

...

Рейтинг:

0 / 0

15.03.2016, 13:02

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192218

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

grufosДа, верно.
не могу сказать за linux, но на windows есть проблема с нагрузкой на диск.
Сам работаю в windows и я смог получить примерно 4-5 Mb/s .... это максимум!!!
...
PostgreSQL, Windows 7 max, AMD FX 4.7 Gh, SSD Kingston SUV300S37A 240G

Запустил select sum( length( текстовое_поле ) ) from большая_таблица

В мониторе ресурсов вижу от 40 Mb/s до 50 Mb/s чтение.

...

Рейтинг:

0 / 0

15.03.2016, 13:21

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192229

Sheriffua

Участник

Откуда: г. Киев

Сообщения: 1 223

Рейтинг: 0 / 0

Попробую еще восстановление запустить на диск Е, там 10й рейд скази винтов

...

Рейтинг:

0 / 0

15.03.2016, 13:31

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192251

grufos

Участник

Откуда: Москва

Сообщения: 94

Рейтинг: 0 / 0

Leonid Kudryavtsev,

Приведите пожалуйста план запроса для 1-го вызова при отсутствии таблицы в кеше и после помещения таблицы в кеш.
Хотелось бы взглянуть... и еще если можно скрин монитора ресурсов...
на моей системе такой же запрос:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

QUERY PLAN
Aggregate  (cost=482634.74..482634.75 rows=1 width=50) (actual time=14922.737..14922.737 rows=1 loops=1)
  Output: sum(length((leader_fio)::text))
  Buffers: shared read=384584
  I/O Timings: read=12432.931
  ->  Seq Scan on public.firms  (cost=0.00..449951.16 rows=6536716 width=50) (actual time=10.900..13778.633 rows=6425658 loops=1)
        Output: leader_fio
        Buffers: shared read=384584
        I/O Timings: read=12432.931
Planning time: 24.556 ms
Execution time: 14922.977 ms

и после разогрева

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.

QUERY PLAN
Aggregate  (cost=482634.74..482634.75 rows=1 width=50) (actual time=2280.303..2280.303 rows=1 loops=1)
  Output: sum(length((leader_fio)::text))
  Buffers: shared hit=384584
  ->  Seq Scan on public.firms  (cost=0.00..449951.16 rows=6536716 width=50) (actual time=0.010..1237.375 rows=6425658 loops=1)
        Output: leader_fio
        Buffers: shared hit=384584
Planning time: 0.145 ms
Execution time: 2280.352 ms

...

Рейтинг:

0 / 0

15.03.2016, 13:45

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192261

Sheriffua

Участник

Откуда: г. Киев

Сообщения: 1 223

Рейтинг: 0 / 0

Запустил рестор, сейчас такая нагрузка:

...

Рейтинг:

0 / 0

15.03.2016, 13:50

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192315

vyegorov

Участник

Откуда: Баньоло-ин-Пьяно

Сообщения: 1 237

Рейтинг: 0 / 0

Sheriffua,

Я бы делал так:
- включил бы мониторинг (так, чтобы снимки снимались часто и была бы история) на диски, CPU, память, файл подкачки
- сделал бы новый кластер
- настроил бы PG, уделив внимание:
* WAL и контрольных точек
* bgwriter
* памяти: много maintenance, мало шаренных буферов
* логгированию всего чего только можно: connect/disconnect, checkpoints, temp, locks
* выключил бы всё, что может тормознуть (fsync, synchronous_commit)
- поднял бы экземпляр и дал ему спокойно ничего делать минут 10-15, чтобы мониторинг зафикисировал базу
- запустил бы восстановление
- по прошествии минут 30 _после_ замедления, начал бы курить графики мониторинга и логи базы.

Урывками — "вот на этом графике у меня затык!" — не увидеть, сравнить не с чем.

...

Рейтинг:

0 / 0

15.03.2016, 14:19

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192412

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

grufosLeonid Kudryavtsev,

Приведите пожалуйста план запроса для 1-го вызова при отсутствии таблицы в кеше и после помещения таблицы в кеш.
Хотелось бы взглянуть... и еще если можно скрин монитора ресурсов...

Не очень понимаю насчет "таблицы в кеше и после помещения таблицы в кеш."

План (до и после запроса 3 строчки):

"Limit (cost=355933.64..355933.65 rows=1 width=2)"
" -> Aggregate (cost=355933.64..355933.65 rows=1 width=2)"
" -> Seq Scan on <cencored> (cost=0.00..328573.09 rows=5472109 width=2)"

Скриншоты в след. письме.

...

Рейтинг:

0 / 0

15.03.2016, 15:25

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192417

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

OFFTOPIC, по просьбе посетителей. Не очень понимаю ценность, но может действительно кому-то нужно.

Выполнение запроса. Чтение с диска.

...

Рейтинг:

0 / 0

15.03.2016, 15:28

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192469

grufos

Участник

Откуда: Москва

Сообщения: 94

Рейтинг: 0 / 0

Leonid KudryavtsevНе очень понимаю насчет "таблицы в кеше и после помещения таблицы в кеш."

Это я опечатался :)
предолагалось ДО помещения таблицы в кеш. (например сразу после рестарта службы)
и после помещения в кеш - select pg_prewarm('table name');

А в плане... жалко, что нет actual строчек...
ожидал план полученный командой:
explain (COSTS, BUFFERS, TIMING, ANALYZE, VERBOSE) SELECT ....

за скриншоты спасибо. Вижу, что postgres читает со скоростью ~28 Mb/sec
а какая версия самого PostgreSQL ?

...

Рейтинг:

0 / 0

15.03.2016, 16:02

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192511

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

grufosза скриншоты спасибо
Не за что.

IMHO & AFAIK особой разницы в скорости дисковой подсистемы Windows / Linux ждать не стоит. Даже наоборот. Обычно под Windows оборудование более массовое/отлажено. Т.ч. пиковые скорости скорее следует на Windows ожидать.

SELECT ... - выполнялся 118 987 ms.
explain ...

"Limit (cost=355933.64..355933.65 rows=1 width=2) (actual time=90426.858..90426.858 rows=1 loops=1)"
" Output: (sum(length(day1)))"
" Buffers: shared hit=421 read=273431"
" -> Aggregate (cost=355933.64..355933.65 rows=1 width=2) (actual time=90426.856..90426.857 rows=1 loops=1)"
" Output: sum(length(day1))"
" Buffers: shared hit=421 read=273431"
" -> Seq Scan on public.innovata (cost=0.00..328573.09 rows=5472109 width=2) (actual time=0.011..89772.976 rows=3952248 loops=1)"
" Output: carrier, flightnumber, servicetype, effectivedate, discontinueddate, day1, day2, day3, day4, day5, day6, day7, departureairport, departurecity, departuretimepub, departuretimeactual, departureutcvariance, departureterminal, arrivalair (...)"
" Buffers: shared hit=421 read=273431"
"Planning time: 0.084 ms"
"Execution time: 90426.899 ms"

выполнялся 90 sec.
Explain после перезапуска службы:

"Limit (cost=355933.64..355933.65 rows=1 width=2) (actual time=2782.678..2782.679 rows=1 loops=1)"
" Output: (sum(length(day1)))"
" Buffers: shared read=273852"
" -> Aggregate (cost=355933.64..355933.65 rows=1 width=2) (actual time=2782.667..2782.668 rows=1 loops=1)"
" Output: sum(length(day1))"
" Buffers: shared read=273852"
" -> Seq Scan on public.innovata (cost=0.00..328573.09 rows=5472109 width=2) (actual time=0.649..2180.144 rows=3952248 loops=1)"
" Output: carrier, flightnumber, servicetype, effectivedate, discontinueddate, day1, day2, day3, day4, day5, day6, day7, departureairport, departurecity, departuretimepub, departuretimeactual, departureutcvariance, departureterminal, arrivalair (...)"
" Buffers: shared read=273852"
"Planning time: 0.761 ms"
"Execution time: 2782.719 ms"

Почему-то стало быстрее (на пару порядков)

Еще одно выполнение explain plan

"Limit (cost=355933.64..355933.65 rows=1 width=2) (actual time=2515.380..2515.381 rows=1 loops=1)"
" Output: (sum(length(day1)))"
" Buffers: shared hit=196 read=273656"
" -> Aggregate (cost=355933.64..355933.65 rows=1 width=2) (actual time=2515.378..2515.378 rows=1 loops=1)"
" Output: sum(length(day1))"
" Buffers: shared hit=196 read=273656"
" -> Seq Scan on public.innovata (cost=0.00..328573.09 rows=5472109 width=2) (actual time=0.006..1900.970 rows=3952248 loops=1)"
" Output: carrier, flightnumber, servicetype, effectivedate, discontinueddate, day1, day2, day3, day4, day5, day6, day7, departureairport, departurecity, departuretimepub, departuretimeactual, departureutcvariance, departureterminal, arrivalair (...)"
" Buffers: shared hit=196 read=273656"
"Planning time: 0.058 ms"
"Execution time: 2515.412 ms"

С PostgreSQL explain не дружу. Т.ч. никак трактовать результаты не буду. Вообще, что-то странное. Понятно, что тесты не чистые

...

Рейтинг:

0 / 0

15.03.2016, 16:28

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192512

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

grufosа какая версия самого PostgreSQL ?
Version string PostgreSQL 9.4.5, compiled by Visual C++ build 1800, 64-bit

...

Рейтинг:

0 / 0

15.03.2016, 16:29

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192553

grufos

Участник

Откуда: Москва

Сообщения: 94

Рейтинг: 0 / 0

Leonid KudryavtsevIMHO & AFAIK особой разницы в скорости дисковой подсистемы Windows / Linux ждать не стоит.

вот тут как раз и есть сомнения....
"старшие товарищи" в лице Ильи Космоденьянского

- настоятельно не рекомендовали под Windows увеличивать размер буферного кеша больше 8 Гб при любом большом размере ОЗУ.

- также должен отметить, что только под Linux сейчас поддерживается работа с большим объёмом ОЗУ - так называемые huge_pages

- на конференциях мне говорили, что под Windows не эффективно реализован код работающий с буферным кэшом. К сожалению у меня недостаточно знаний, чтобы это подтвердить/опровергнуть.

Именно поэтому хотелось получить отзыв о работе под Windows/Linux

Что касается представленных планов, то они очень интересные...

1-й "Execution time: 90426.899 ms"
" Buffers: shared hit=421 read=273431" говорит о том, что в буферном кеше уже нашлось 421 страница и прочитано 273431 страниц итого = 273852

2-й "Execution time: 2782.719 ms"
" Buffers: shared read=273852" О как! мы всё прочитали с диска, но при этом работали 40 раз быстрее!

3-й "Execution time: 2515.412 ms"
" Buffers: shared hit=196 read=273656" часть уже в буферном кеше - 196 страниц. Время работы уменьшилось. Ожидаемо если сравнивать со 2-м запросом, но не с 1-м.

здесь действительно неясно почему 1-й запрос работал так долго. Возможно, что вклинились некие процессы которые просто сильно затормозили его работу...

...

Рейтинг:

0 / 0

15.03.2016, 17:04

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192559

vyegorov

Участник

Откуда: Баньоло-ин-Пьяно

Сообщения: 1 237

Рейтинг: 0 / 0

grufos,

Есть ещё кэш операционки, все 3 плана читают тот же файл.

...

Рейтинг:

0 / 0

15.03.2016, 17:08

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192572

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Тест понятно не корректный и комп в фоне молотил долгий расчет (к БД не обращался). Т.к. мне не очень понятно, что именно и для чего нужно grufos, то и смысла нет напрягаться измерить сферического коня. IMHO

Если даже взять 90 sec это чтение с диска (что похоже на правду), то 273 431 * 8Kb / 90 sec = 24.3 Mb/s эффективных данных.

С загрузкой 40-50 Mb/s в диспетчере задач согласуется достаточно хорошо. Всяко НЕ "примерно 4-5 Mb/s .... это максимум". Цифры IMHO вполне адекватные для рабочего компа с бытовым SSD диском.

...

Рейтинг:

0 / 0

15.03.2016, 17:20

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192584

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

grufosвот тут как раз и есть сомнения....
IMHO & AFAIK

Для Oracle, Oracle Co. указывал цифры в 10% - 20% изменения производительности в зависимости от конфигурирования ввода-вывода (файловая система, RAW-девайсы и т.д.).

IMHO Где-то такой разброс между различными версиями операционных систем, адекватными конфигурациями и стоит ожидать. Максимум. Если разница зашкаливает в РАЗЫ, то явно: глюк, бага, кривое оборудование, кривые руки.

Я верю в профессионализм своих коллег! Поэтому когда вместо ожидаемых десятков/сотен Mb/s получаю "примерно 4-5 Mb/s" - я точно знаю в чем дело. В компании не только я работаю. Не смог таких результатов добиться самостоятельно - коллеги тебе помогли )))

...

Рейтинг:

0 / 0

15.03.2016, 17:28

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192606

grufos

Участник

Откуда: Москва

Сообщения: 94

Рейтинг: 0 / 0

Leonid Kudryavtsev,
vyegorov,

Спасибо за ответы и подсказки.
Конечно я ещё буду исследовать этот вопрос с контролём счетчиков, чтобы убрать вот это "примерно 4-5 Mb/s"

...

Рейтинг:

0 / 0

15.03.2016, 17:57

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192689

Sheriffua

Участник

Откуда: г. Киев

Сообщения: 1 223

Рейтинг: 0 / 0

Leonid KudryavtsevIMHO & AFAIK

Для Oracle, Oracle Co. указывал цифры в 10% - 20% изменения производительности в зависимости от конфигурирования ввода-вывода (файловая система, RAW-девайсы и т.д.).

IMHO Где-то такой разброс между различными версиями операционных систем, адекватными конфигурациями и стоит ожидать. Максимум. Если разница зашкаливает в РАЗЫ, то явно: глюк, бага, кривое оборудование, кривые руки.

Я верю в профессионализм своих коллег! Поэтому когда вместо ожидаемых десятков/сотен Mb/s получаю "примерно 4-5 Mb/s" - я точно знаю в чем дело. В компании не только я работаю. Не смог таких результатов добиться самостоятельно - коллеги тебе помогли )))

Главное чтобы коллеги владели кухней.
Пока смотрю на рестор и ответа не нахожу с чем связана данная трабла, с виндой, железом, утечкой памяти... Не понимаю (( Куда пропадает скорость восстановления данных и что на нее влияет??!

...

Рейтинг:

0 / 0

15.03.2016, 19:50

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192852

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

SheriffuaLeonid KudryavtsevIMHO & AFAIK

Для Oracle, Oracle Co. указывал цифры в 10% - 20% изменения производительности в зависимости от конфигурирования ввода-вывода (файловая система, RAW-девайсы и т.д.).

IMHO Где-то такой разброс между различными версиями операционных систем, адекватными конфигурациями и стоит ожидать. Максимум. Если разница зашкаливает в РАЗЫ, то явно: глюк, бага, кривое оборудование, кривые руки.

Я верю в профессионализм своих коллег! Поэтому когда вместо ожидаемых десятков/сотен Mb/s получаю "примерно 4-5 Mb/s" - я точно знаю в чем дело. В компании не только я работаю. Не смог таких результатов добиться самостоятельно - коллеги тебе помогли )))

Главное чтобы коллеги владели кухней.
Пока смотрю на рестор и ответа не нахожу с чем связана данная трабла, с виндой, железом, утечкой памяти... Не понимаю (( Куда пропадает скорость восстановления данных и что на нее влияет??!

1)Включите полный лог запросов к базе во время рестора и посмотрите что там происходит тогда когда все уже медленно идет.
или
2)попробуйте сделать --jobs=4 (или 8) для pg_restore.
или
3)возьмите и попробуйте на другом сервере для теста.
или
4)ВРЕМЕННО для теста на базе сделайте fsync=off и попробуйте загрузить

--
Maxim Boguk
www.postgresql-consulting.ru

...

Рейтинг:

0 / 0

16.03.2016, 03:41

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192885

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

Maxim Boguk,

4 уже -- см выше
3 -- ему не дают, [ибо it-нег]
2 -- у него одна табличка остаёцца для копей. т.е. остальные потоки в пролёте
1 -- см 2.

...

Рейтинг:

0 / 0

16.03.2016, 08:29

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39192931

Sheriffua

Участник

Откуда: г. Киев

Сообщения: 1 223

Рейтинг: 0 / 0

qwwqMaxim Boguk,

4 уже -- см выше
3 -- ему не дают, [ибо it-нег]
2 -- у него одна табличка остаёцца для копей. т.е. остальные потоки в пролёте
1 -- см 2.

Всё верно.

...

Рейтинг:

0 / 0

16.03.2016, 09:33

| Ответить | Цитировать | Написать

Скорость восстановления данных со временем заметно замедляется

#39193544

Sheriffua

Участник

Откуда: г. Киев

Сообщения: 1 223

Рейтинг: 0 / 0

vyegorovSheriffua,

Я бы делал так:
- включил бы мониторинг (так, чтобы снимки снимались часто и была бы история) на диски, CPU, память, файл подкачки
- сделал бы новый кластер
- настроил бы PG, уделив внимание:
* WAL и контрольных точек
* bgwriter
* памяти: много maintenance, мало шаренных буферов
* логгированию всего чего только можно: connect/disconnect, checkpoints, temp, locks
* выключил бы всё, что может тормознуть (fsync, synchronous_commit)
- поднял бы экземпляр и дал ему спокойно ничего делать минут 10-15, чтобы мониторинг зафикисировал базу
- запустил бы восстановление
- по прошествии минут 30 _после_ замедления, начал бы курить графики мониторинга и логи базы.

Урывками — "вот на этом графике у меня затык!" — не увидеть, сравнить не с чем.

Вы говорили про этот мониторинг?

...

Рейтинг:

0 / 0

16.03.2016, 17:00

| Ответить | Цитировать | Написать

25 сообщений из 80, страница 3 из 4

все

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=53&msg=39192559&tid=1997294]:	0ms
get settings:	8ms
get forum list:	14ms
check forum access:	3ms
check topic access:	3ms
track hit:	311ms
get topic data:	7ms
get forum data:	2ms
get page messages:	39ms
get tp. blocked users:	2ms
others:	240ms

total:	629ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы