ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий update на 30М записей
4 сообщений из 29, страница 2 из 2
  2  все
Очень долгий update на 30М записей
    #39181761
nateless
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nateless
Гость
nateless,

логи postgres`a

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
2016-02-29 15:48:35 CET [5515-2] LOG:  automatic analyze of table "prometheus.public.clusters" system usage: CPU 0.09s/0.37u sec elapsed 7.08 sec
2016-02-29 16:03:14 CET [5616-1] LOG:  automatic vacuum of table "prometheus.public.cluster_addresses": index scans: 1
	pages: 0 removed, 195683 remain, 0 skipped due to pins
	tuples: 479505 removed, 17286038 remain, 327108 are dead but not yet removable
	buffer usage: 421097 hits, 21553 misses, 22276 dirtied
	avg read rate: 5.274 MB/s, avg write rate: 5.451 MB/s
	system usage: CPU 0.16s/5.04u sec elapsed 31.92 sec
2016-02-29 16:04:09 CET [5623-1] LOG:  automatic vacuum of table "prometheus.public.cluster_addresses": index scans: 1
	pages: 0 removed, 195683 remain, 1 skipped due to pins
	tuples: 1272248 removed, 20323272 remain, 27 are dead but not yet removable
	buffer usage: 468380 hits, 21393 misses, 6014 dirtied
	avg read rate: 6.417 MB/s, avg write rate: 1.804 MB/s
	system usage: CPU 0.18s/5.82u sec elapsed 26.04 sec
2016-02-29 16:06:16 CET [5640-1] LOG:  automatic vacuum of table "prometheus.public.cluster_addresses": index scans: 1
	pages: 0 removed, 195683 remain, 2 skipped due to pins
	tuples: 1167628 removed, 21838575 remain, 183 are dead but not yet removable
	buffer usage: 486084 hits, 21016 misses, 21523 dirtied
	avg read rate: 4.851 MB/s, avg write rate: 4.968 MB/s
	system usage: CPU 0.17s/6.09u sec elapsed 33.84 sec
...
Рейтинг: 0 / 0
29.02.2016, 18:07
| Ответить | Цитировать | Написать  
Очень долгий update на 30М записей
    #39181772
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
nateless,

у вас гигантский поток апдейтов в большой таблице. не взлетит. т.е. не на ПЖ.

или надо исхитрятся -- писать события в одну табличку, без апдейтов. "очередь событий". а агрегировать результаты большими пачками и апдейтить -- чтобы снизить поток апдейтов хотя бы на порядок -- другой.

чем так мучиться -- поищите более другую СУБД. у ПЖ есть ахиллесова пята. пятища. печаль.

или ещё кто--то м.б. что то подскажет.
м.б. кто--то таблички такого профиля нагрузки как--то раскидывал. (поток сменных партиций, с дропом очищенных старых, что--то в этом роде. много хенджоба на ровном месте).
...
Рейтинг: 0 / 0
29.02.2016, 18:21
| Ответить | Цитировать | Написать  
Очень долгий update на 30М записей
    #39181774
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
nateless,

У вас:
задержка [тут можно было бы остановиться :) ] на запись ~22мс и 2000 wIOPS — слабо для SSD, латенсия большая.

шаренные буфера 16Гб (начальный пост), при этом почти всю "грязь" из шареных буферов выносят чекпойнты (pct_ckpt=97.1),
новые блоки почти не выделяются т.к. места и так навалом (new_ratio=0.110), бэкграунд врайтер ничего не делает (pct_bgw=0.0).
Из всех контрольных точек треть вынужденная (forced_ratio=33.9), точки происходят часто (min_between=4.30).

По картинке — вы дофига пишите в базу (не новость).
Для преимущественно пишущих нагрузок нужно ограничивать базу в размере кэша, чтоб к работе с диском подключались все и раньше.


Я бы сделал так:
- вынес бы `pg_xlog` на отдельный диск, при таких показателях может помочь.
- понизил бы шаренные буфера до 2Гб (надо подбирать, конечно)
- выкрутил бы bgwriter (вроде уже упоминал)
- посмотрел бы на тему понизить fillfactor, только он учитывается при INSERT-ах, соответственно то что есть — не поменяетя.

Помониторить после этого.

P.S. При выводе iostat-данных вы интервал не убирайте...
...
Рейтинг: 0 / 0
29.02.2016, 18:23
| Ответить | Цитировать | Написать  
Очень долгий update на 30М записей
    #39181814
Author the new one
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Author the new one
Участник
nateless,

А результат select * from pg_stats where schemaname='public' and tablename='clusters' не покажете?
...
Рейтинг: 0 / 0
29.02.2016, 18:47
| Ответить | Цитировать | Написать  
4 сообщений из 29, страница 2 из 2
  2  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий update на 30М записей
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=39181814&tid=1997396]:
 0ms
get settings:
 7ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 61ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 39ms
get tp. blocked users:
 1ms
others: 240ms
total:  372ms
созд. / загр.: 372ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]