Возможно в микрофон я не смог донести ситуацию целиком, постараюсь текстом:
Команда COPY насколько мне известно и судя по документации работает только для таблицы, т.е. чтобы её использовать нужно знать имя таблиц Таблиц - тысячи в одной базе, баз 50 + Т.е. Итого 500+ тысяч таблиц Казалось бы - ну напишем скрипт, но...
Главная проблема в том, что получить имена таблиц невозможно Из-за повреждения системных индексов любой запрос уходил в бесконечное выполнение. При отключении в конфиге использования системных индексов, запрос на получение списка таблиц в одной из десятков баз выполнился только за 2,5 дня! Такого количества времени не было,счёт шёл на часы...
К сожалению по той же причине (повреждение системных индексов) не работали опции --schema-only и --data-only у pg_dump. Была надежда что --data-only нас спасёт, так как индексов в разы больше чем таблиц, и соответственно рассчитывали на то, что при этой опции не будет запроса на получение списка и состава индексов и запрос отработает сильно быстрее, но оказалось что pg_dump всё равно запрашивает список и состав индексов даже при указании --data-only.
Поэтому пришлось патчить pg_dump заставив его не запрашивать информацию об индексах. Затем обрабатывали уже ошибки pg_dump. когда он находил сбойный чанк, пропускали таблицу со сбойным чанком через --exclude-table и её уже спасали через COPY + dblink + offset В итоге мы получили данные через -data-only + всё что можно было спасти через "copy + dblink + offset", затем процедурой выгрузки/загрузки dt восстановить индексы
Сжимается всё, и индексы в том числе Повышенный расход памяти не зафиксирован По поводу cpu в статье отразил, что на уровне погрешности измерений 1,5% рост нагрузки Замеры делались на системе с 500+ одновременно работающих пользователей
Для SATA дисков вынести всё таки в оперативку каталога статистики я бы рекомендовал.
Ну или как вариант, сделайте 2 теста, без выноса в оперативку и с выносом, заодно будет видно влияние этого действа на вашей инфраструктуре.
max_files_per_process = 10000 вместо max_files_per_process = 1000
synchronous_commit = off вместо #synchronous_commit = on
commit_delay = 1000 вместо #commit_delay = 1000
seq_page_cost = 1.0 вместо seq_page_cost = 0.1
from_collapse_limit = 8 вместо from_collapse_limit = 20
join_collapse_limit = 8 вместо join_collapse_limit = 20
max_parallel_workers_per_gather = 0 вместо max_parallel_workers_per_gather = 4
log_autovacuum_min_duration = 1000 вместо log_autovacuum_min_duration = 0
autovacuum_vacuum_scale_factor = 0.02 вместо #autovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_scale_factor = 0.01 вместо #autovacuum_analyze_scale_factor = 0.1
вынести каталог pg_stat_tmp в RAM
В файл etc/fstab добавляем tmpfs <путь к pg_stat_tmp> tmpfs noatime,nodiratime,defaults,size=256M
Перезагружаем сервер полностью
ОЧЕНЬ ВАЖНЫЙ момент — после загрузки базы в Postgres, не важно через dump или dt, обязательно проведите analyze на всей базе, так как дамп PG не содержит статистику, а при загрузке из dt атовакуум не успеет проанализировать всё. Если для повторного теста базу вгружать не планируете, то проведите на ней перед тестирование vacuum full.
Попробуйте с этими изменениями провести тесты (кроме теста Гилёва, так как по моему мнению этот тест для клиент-серверной 1С не показателен )
P.S. Насколько я понял дисковый массив 1, если нет, то WAL на отдельный дисковый массив (по аналогии выноса temdb у MS SQL). По возможности поменяйте версию платформы, 8.3.13.1513 одна из самых неудачных версий.
P.P.S. при проведении тестов для статьи на которую Вы ссылаетесь индексирование дисков было отключено)
Тогда покажите Postgresql.conf и точные параметры железа для сервера СУБД:
Количество ядер
Тип HDD их количество и как разбиты на логические диски
Количество оперативной памяти
Подскажите, какой смысл указывать from_colapse_limit=20, если параметр geqo_threshold по умолчанию рааен 12 и судя по статье его не меняли?
Правильно понимаю что при таком сочетании настроек оптимизатора, по факту лимит перебора для планировщика 11, а не 20?
copy(selectrelnamespace, relnamefrompg_classwhererelkind='r')to'/tmp/pg_class.txt'- хорошая мысль.В тот момент такая идея в голову не пришла.
Добрый день!
Возможно в микрофон я не смог донести ситуацию целиком, постараюсь текстом:
Команда COPY насколько мне известно и судя по документации работает только для таблицы, т.е. чтобы её использовать нужно знать имя таблиц
Таблиц - тысячи в одной базе, баз 50 +
Т.е. Итого 500+ тысяч таблиц
Казалось бы - ну напишем скрипт, но...
Главная проблема в том, что получить имена таблиц невозможно
Из-за повреждения системных индексов любой запрос уходил в бесконечное выполнение.
При отключении в конфиге использования системных индексов, запрос на получение списка таблиц в одной из десятков баз выполнился только за 2,5 дня!
Такого количества времени не было,счёт шёл на часы...
К сожалению по той же причине (повреждение системных индексов) не работали опции --schema-only и --data-only у pg_dump.
Была надежда что --data-only нас спасёт, так как индексов в разы больше чем таблиц, и соответственно рассчитывали на то, что при этой опции не будет запроса на получение списка и состава индексов и запрос отработает сильно быстрее, но оказалось что pg_dump всё равно запрашивает список и состав индексов даже при указании --data-only.
Поэтому пришлось патчить pg_dump заставив его не запрашивать информацию об индексах.
Затем обрабатывали уже ошибки pg_dump. когда он находил сбойный чанк, пропускали таблицу со сбойным чанком через --exclude-table и её уже спасали через COPY + dblink + offset
В итоге мы получили данные через -data-only + всё что можно было спасти через "copy + dblink + offset", затем процедурой выгрузки/загрузки dt восстановить индексы
Сжимается всё, и индексы в том числе
Повышенный расход памяти не зафиксирован
По поводу cpu в статье отразил, что на уровне погрешности измерений 1,5% рост нагрузки
Замеры делались на системе с 500+ одновременно работающих пользователей
Ну или как вариант, сделайте 2 теста, без выноса в оперативку и с выносом, заодно будет видно влияние этого действа на вашей инфраструктуре.
И не забудьте про аналайз перед тестом)
synchronous_commit = off вместо #synchronous_commit = on
commit_delay = 1000 вместо #commit_delay = 1000
seq_page_cost = 1.0 вместо seq_page_cost = 0.1
from_collapse_limit = 8 вместо from_collapse_limit = 20
join_collapse_limit = 8 вместо join_collapse_limit = 20
max_parallel_workers_per_gather = 0 вместо max_parallel_workers_per_gather = 4
log_autovacuum_min_duration = 1000 вместо log_autovacuum_min_duration = 0
autovacuum_vacuum_scale_factor = 0.02 вместо #autovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_scale_factor = 0.01 вместо #autovacuum_analyze_scale_factor = 0.1
вынести каталог pg_stat_tmp в RAM
В файл etc/fstab добавляем tmpfs <путь к pg_stat_tmp> tmpfs noatime,nodiratime,defaults,size=256M
Перезагружаем сервер полностью
ОЧЕНЬ ВАЖНЫЙ момент — после загрузки базы в Postgres, не важно через dump или dt, обязательно проведите analyze на всей базе, так как дамп PG не содержит статистику, а при загрузке из dt атовакуум не успеет проанализировать всё. Если для повторного теста базу вгружать не планируете, то проведите на ней перед тестирование vacuum full.
Попробуйте с этими изменениями провести тесты (кроме теста Гилёва, так как по моему мнению этот тест для клиент-серверной 1С не показателен )
P.S. Насколько я понял дисковый массив 1, если нет, то WAL на отдельный дисковый массив (по аналогии выноса temdb у MS SQL). По возможности поменяйте версию платформы, 8.3.13.1513 одна из самых неудачных версий.
P.P.S. при проведении тестов для статьи на которую Вы ссылаетесь индексирование дисков было отключено)
Посмотрю конфиг, если будет что поправить, напишу
Количество ядер
Тип HDD их количество и как разбиты на логические диски
Количество оперативной памяти
если можно.