|
Как сделать аналог оракловому STORAGE(INITIAL xxx NEXT yyy) ?
|
|||
---|---|---|---|
#18+
Добрый день! Столкнулся со следующей проблемой: Имею несколько сотен таблиц, которые постоянно и более менее равномерно накапливают данные. Записи инсертятся каждую минуту во все таблицы малыми количестваим (по 10-500 строк в минуту). табличкам выделяется новое место на диске, но прирост идет минимальными объемами. Таким образом фрагментация файлов получается жуткая, что крайне негативно влияет потом на скорость чтения. Дефрагментация диска помогает, но потом приходится заново дефрагменитровать. Из штатных средств нашел только VACUUM FULL, но это долго, т.к. по сути создает таблицу заново, при этом лочит намертво исходник. А помогает опять же временно, пока не накопится новый фрагментированный кусок. В ORACLE можно указать сколько выделить таблице/индексу/пространству сразу, и сколько следующими кусками STORAGE(INITIAL xxx NEXT yyy) Нет ли в PG каких либо аналогичных параметров? И кто как справляется с подобными проблемами в PG? для инфо: PG 11.1 windows server 2016 текщий занятый объем (только данные без индексов) 600GB. Диск обычный серверный SATA без рейда. Заранее спасибо за ваши ответы. Как запасное решение держу в голове следующий сценарий: 1. отключить на таблицах автовакуум 2. сделать ежедневный JOB, который будет: 2.1. добавлять среднесуточное кол-во записей с отрицательными ID (insert from generate_series...) 2.2. удалять добавленные записи 2.3. делать на таблицу vacuum freeze (без лока и пересоздания) Рассчитываю, что таблицы таким образом будут прирастать большими кусками, что не будет снижать скорость чтения. Но что-то мне подсказывает, что должно быть более красивое и системное решение. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2019, 12:58 |
|
Как сделать аналог оракловому STORAGE(INITIAL xxx NEXT yyy) ?
|
|||
---|---|---|---|
#18+
Такого функционала нет. В постресе в принципе все вопросы касательно дискового IO и его оптимизации возложены на уровень ОС и ФС, в то время как в оракле изначально используется как раз противоположный подход. Собственно, это слабейшее и наиболее зависимое от выбора ОС место постгреса, следом за ним, пожалуй, идёт работа с разделяемой памятью - всё по тем же причинам. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2019, 10:51 |
|
Как сделать аналог оракловому STORAGE(INITIAL xxx NEXT yyy) ?
|
|||
---|---|---|---|
#18+
pg_delphiДиск обычный серверный SATA без рейда. У вас проблема с процитированным. Не делаю базы на SATA (и SAS) уже лет 5-10 как. Ставьте SSD внятный и проблемы с фрагментацией не будет. А те костыли что вы пытаетесь придумать - до добра вас не доведут. Тем более на 600GB таблице. PS: или разбирайтесь как в NTFS настроить чтобы оно сразу большими кусками выделяло место при расширении файла. Это задача файловой системы не допускать сильной фрагментации append файла а не базы. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2019, 13:43 |
|
Как сделать аналог оракловому STORAGE(INITIAL xxx NEXT yyy) ?
|
|||
---|---|---|---|
#18+
Спасибо за обратную связь! Особенно приятно видеть Scott_Tiger - старого доброго завсегдатая скуля. И как всегда кратко, по делу, без понтов и тролинга. Привет и удачи тебе, уважаемый! Да, костылики кривенькие получаются. 1. В моем случае VACUUM всегда возвращает занятое пространство Оси. 2. При левых инсертах и делитах накладывается необходимость ждать CHECKPOINT. Мне SDD не потянуть сейчас, т.к. объем солидный и перезапись частая. А проект не промышленный, а так, домашний стартапчик на PowerPC вместо сервера. И так пришлось потратиться на 3 серверных винта: 1 под WAL, 1 под данные, 1 под индексы. Так что пока остаюсь на дефрагментации. Для начала переформатировал диски до 64к кластер. Плюс попробую поиграться с segment_size и block_size с целью снижения RELSEG_SIZE. Да, файлов будет больше, но за счет уменьшения их объема дефраг должен быть полегче. Дальше, возможно, буду смотреть в сторону SAS рейд контролера. Надо будет покурить FAQи по фрагментации в рейдах. А по настройкам NTFS в части приращения файлов что-то не смог ничего нагуглить. Если не лень кому-то будет – ткните носом, буду крайне признателен. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2019, 11:14 |
|
Как сделать аналог оракловому STORAGE(INITIAL xxx NEXT yyy) ?
|
|||
---|---|---|---|
#18+
pg_delphi, RAID в этом случае вряд ли сильно поможет, а с хорошим большим кэшем и батарейкой будет стоить совсем небюджетно. Если на пару терабайт (оценка с потолка) SSD в зеркале денег или желания инвестировать их в железо нет, смотрите на эффективно кэширующие ФС (ОС рекомендую сменить в любом случае) и гибридные дисковые пулы. Я по ряду причин практикую ZFS на Solaris и подобных. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2019, 10:03 |
|
|
start [/forum/topic.php?fid=53&tid=1995342]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
45ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 152ms |
0 / 0 |