Очень долгий update на 30М записей / PostgreSQL

ReSQL.ru

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

Гость

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

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

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

Цитировать

Написать

Автор*:

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

Тема*:

Сообщение

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

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

Автор:

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

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

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

Вложение:

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

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

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

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

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

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий update на 30М записей

25 сообщений из 29, страница 1 из 2

все

Очень долгий update на 30М записей

#39178123

nateless

Гость

Все пытаюсь бороться с Postgresql, теперь встал вопрос оптимизации update на таблице с постоянным инсертом, после завершения будет около 150М кластеров. Сейчас медленно движемся в районе 35М. Возникают спайки такого плана:

SQL (53712.7ms) UPDATE "cluster_addresses" SET "cluster_id" = 13801883 WHERE "cluster_addresses"."cluster_id" = $1 [["cluster_id", 14099291]]

Код: plsql

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

postgresql=> \d+ cluster_addresses;
                                               Table "public.cluster_addresses"
   Column   |  Type   |                           Modifiers                            | Storage | Stats target | Description
------------+---------+----------------------------------------------------------------+---------+--------------+-------------
 id         | integer | not null default nextval('cluster_addresses_id_seq'::regclass) | plain   |              |
 cluster_id | integer |                                                                | plain   |              |
 address_id | integer |                                                                | plain   |              |
Indexes:
    "cluster_addresses_pkey" PRIMARY KEY, btree (id)
    "index_cluster_addresses_on_address_id" UNIQUE, btree (address_id)
    "index_cluster_addresses_on_cluster_id" btree (cluster_id)

Код: plsql

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

prometheus=> explain analyze UPDATE "cluster_addresses" SET "cluster_id" = 13801883 WHERE "cluster_addresses"."cluster_id" = 14099291;
                                                                                QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Update on cluster_addresses  (cost=0.56..369.87 rows=290 width=14) (actual time=5243.940..5243.940 rows=0 loops=1)
   ->  Index Scan using index_cluster_addresses_on_cluster_id on cluster_addresses  (cost=0.56..369.87 rows=290 width=14) (actual time=5243.939..5243.939 rows=0 loops=1)
         Index Cond: (cluster_id = 14099291)
 Planning time: 3.574 ms
 Execution time: 5243.963 ms
(5 rows)

Повторно ( видимо после попадания в кеш ) запрос выполняется моментально.

Какие есть варианты оптимизации? Можно ли как-то прогрузить всю таблицу cluster_addresses в память? После 5 дней работы Postgresql жрет около 22GB RAM из 64. Вся база сейчас на отдельном SSD диске.

Postgresql 9.5, конфиг:

max_connections = 50
shared_buffers = 16GB
effective_cache_size = 48GB
work_mem = 335544kB
maintenance_work_mem = 2GB
max_wal_size = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100

...

Рейтинг:

0 / 0

24.02.2016, 19:32

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

Очень долгий update на 30М записей

#39178133

nateless

Гость

Забыл еще про пару настроек:

shared_buffers = 16GB
temp_buffers = 16MB
wal_level = minimal
fsync = off
synchronous_commit = off
checkpoint_completion_target = 0.9

...

Рейтинг:

0 / 0

24.02.2016, 19:49

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

Очень долгий update на 30М записей

#39178168

vyegorov

Участник

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

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

Рейтинг: 0 / 0

nateless,

http://www.postgresql.org/docs/current/interactive/pgprewarm.html

http://raghavt.blogspot.com/2014/06/utilising-caching-contribs-pgprewarm.html

...

Рейтинг:

0 / 0

24.02.2016, 21:21

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

Очень долгий update на 30М записей

#39178238

nateless

Гость

vyegorov, не особо помогает:

D, [2016-02-24T22:11:02.947670 #17639] DEBUG -- : SQL (5919.7ms) UPDATE "cluster_addresses" SET "cluster_id" = 12480109 WHERE "cluster_addresses"."cluster_id" = $1 [["cluster_id", 14255749]]

Это после pg_prewarm

...

Рейтинг:

0 / 0

25.02.2016, 00:12

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

Очень долгий update на 30М записей

#39178258

qwwq

Участник

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

Рейтинг: 0 / 0

nateless,

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

вот скоко оно страничек за 6 сек поднимает --- вывести буферсы не пробовали в експлейне ?

...

Рейтинг:

0 / 0

25.02.2016, 02:07

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

Очень долгий update на 30М записей

#39178814

nateless

Гость

qwwq,

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Update on public.cluster_addresses (cost=0.56..749.71 rows=653 width=14) (actual time=611.142..611.142 rows=0 loops=1)
Buffers: shared hit=28384 dirtied=8567
-> Index Scan using index_cluster_addresses_on_cluster_id on public.cluster_addresses (cost=0.56..749.71 rows=653 width=14) (actual time=611.140..611.140 rows=0 loops=1)
Output: id, 8508905, address_id, ctid
Index Cond: (cluster_addresses.cluster_id = 5495566)
Buffers: shared hit=28384 dirtied=8567
Planning time: 0.035 ms
Execution time: 611.157 ms

Если честно то я еще не очень понимаю вывод про буфферы и что это значит :)

...

Рейтинг:

0 / 0

25.02.2016, 14:21

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

Очень долгий update на 30М записей

#39178838

qwwq

Участник

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

Рейтинг: 0 / 0

natelessqwwq,

Код: sql

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

 Update on public.cluster_addresses  (cost=0.56..749.71 rows=653 width=14) (actual time=611.142..611.142 rows=0 loops=1)
   Buffers: shared hit=28384 dirtied=8567
   ->  Index Scan using index_cluster_addresses_on_cluster_id on public.cluster_addresses  (cost=0.56..749.71 rows=653 width=14) (actual time=611.140..611.140 rows=0 loops=1)
         Output: id, 8508905, address_id, ctid
         Index Cond: (cluster_addresses.cluster_id = 5495566)
         Buffers: shared hit=28384 dirtied=8567
 Planning time: 0.035 ms
 Execution time: 611.157 ms

Если честно то я еще не очень понимаю вывод про буфферы и что это значит :)
переадресуем этот вопрос админам -- тут вегоров нам наверняка объяснит, как буферсы мапятся на страницы. и что означает тот факт, что для добычи 0 записей шириной 14 нам потребовалось поднять аж 28кило буферсов. в данном случае -- из кеша (hit)

...

Рейтинг:

0 / 0

25.02.2016, 14:41

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

Очень долгий update на 30М записей

#39178881

vyegorov

Участник

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

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

Рейтинг: 0 / 0

qwwq,

В Postgres'е IndexScan означает, что доступ идёт не только к индексу, но и к таблице тоже. Всегда.

Индекс хранит все вхождения `cluster_id = 5495566` в таблице, включая те, которые уже были удалены — видимость записей храниться в таблице. База получает все указатели от индекса, лезет в таблицу, чтобы увидеть — а эту запись другая сессия уже удалила, её показывать не надо. Причём под "удалить" попадает и UPDATE, т.к. физически в Postgres'е UPDATE = DELETE + INSERT.

При таком некислом кол-ве буферов, я думаю что:
- у вас много "удалённых" записей, которые есть в индексе, но уже были изменены другими сессиями
- пока бежит запрос, он меняет битики записям (dirtied=8567), т.е. запрос нашёл ещё 8К буферов, на которых данные были изменены недавно и ваш запрос первый это увидел
- активность сильная, autovacuum не успевает. пухнут и индексы, и таблицы.

autovacuum вообще включен? что говорит:

Код: sql

SELECT name, setting, unit FROM pg_settings WHERE name ~ 'autov|vacuum';

Думаю, что нужно настроить autovacuum очень агрессивно, пройтись VACUUM-ом по всем таблицам и перестроить индексы.

...

Рейтинг:

0 / 0

25.02.2016, 15:01

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

Очень долгий update на 30М записей

#39178887

nateless

Гость

vyegorov,

Да, изменения частые. Настройки автовакума не менял вообще:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.

                name                 |  setting  | unit
-------------------------------------+-----------+------
 autovacuum                          | on        |
 autovacuum_analyze_scale_factor     | 0.1       |
 autovacuum_analyze_threshold        | 50        |
 autovacuum_freeze_max_age           | 200000000 |
 autovacuum_max_workers              | 3         |
 autovacuum_multixact_freeze_max_age | 400000000 |
 autovacuum_naptime                  | 60        | s
 autovacuum_vacuum_cost_delay        | 20        | ms
 autovacuum_vacuum_cost_limit        | -1        |
 autovacuum_vacuum_scale_factor      | 0.2       |
 autovacuum_vacuum_threshold         | 50        |
 autovacuum_work_mem                 | -1        | kB
 log_autovacuum_min_duration         | -1        | ms
 vacuum_cost_delay                   | 0         | ms
 vacuum_cost_limit                   | 200       |
 vacuum_cost_page_dirty              | 20        |
 vacuum_cost_page_hit                | 1         |
 vacuum_cost_page_miss               | 10        |
 vacuum_defer_cleanup_age            | 0         |
 vacuum_freeze_min_age               | 50000000  |
 vacuum_freeze_table_age             | 150000000 |
 vacuum_multixact_freeze_min_age     | 5000000   |
 vacuum_multixact_freeze_table_age   | 150000000 |
(23 rows)

...

Рейтинг:

0 / 0

25.02.2016, 15:04

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

Очень долгий update на 30М записей

#39178891

qwwq

Участник

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

Рейтинг: 0 / 0

vyegorov,

вот да
то, что оно для 0 записей 5 секунд шликает ssd -- наводит на именно такую мысль.

Табла гигантская, не партицированная. наверняка вакуумится сутками. Могли и отключить, по недомыслию. При этом апдейтят, как не на пж. ПЖ он слабоват в коленках на такое. (ну вот есть за ним такая слабина)

Для реидекса без останова -- максимову приблуду, наверное, надо поюзать. нет ?

...

Рейтинг:

0 / 0

25.02.2016, 15:08

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

Очень долгий update на 30М записей

#39178922

Alexius

Участник

Сообщения: 749

Рейтинг: 0 / 0

nateless,

длинные транзакции есть?

...

Рейтинг:

0 / 0

25.02.2016, 15:27

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

Очень долгий update на 30М записей

#39178927

nateless

Гость

Alexius,

Не много 90% выглядят примерно так

Код: plsql

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

BEGIN
SELECT "inputs".* FROM "inputs" WHERE "inputs"."trx_id" = $1
SELECT "outputs".* FROM "outputs" WHERE "outputs"."id" IN ($1)
SELECT COUNT(*) FROM "cluster_addresses" WHERE "cluster_addresses"."address_id" IN ($1)
SELECT "cluster_addresses".* FROM "cluster_addresses" WHERE "cluster_addresses"."address_id" IN ($1)
INSERT INTO "cluster_addresses" ("cluster_id", "address_id") VALUES ($1, $2) RETURNING "id"
COMMIT

В случае если кластеры уже есть то идет запись к ним и обьединение через UPDATE которые подвисают.

...

Рейтинг:

0 / 0

25.02.2016, 15:30

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

Очень долгий update на 30М записей

#39178930

nateless

Гость

Сделал VACUUM FULL ANALYZE cluster_addresses;

Все равно виснет:

Код: plsql

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

 Update on cluster_addresses  (cost=0.44..332.20 rows=276 width=14) (actual time=3036.410..3036.410 rows=0 loops=1)
   Buffers: shared hit=2075 dirtied=1
   ->  Index Scan using index_cluster_addresses_on_cluster_id on cluster_addresses  (cost=0.44..332.20 rows=276 width=14) (actual time=3036.408..3036.408 rows=0 loops=1)
         Index Cond: (cluster_id = 11759389)
         Buffers: shared hit=2075 dirtied=1
 Planning time: 0.281 ms
 Execution time: 3036.436 ms
(7 rows)

...

Рейтинг:

0 / 0

25.02.2016, 15:32

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

Очень долгий update на 30М записей

#39178948

nateless

Гость

nateless,

При этом это повторные запросы, тоесть я веду лог запросов от Rails, вижу что он занят 3с, в другом окне через пару секнуд делают его же аналайз и он все равно выполняется 3 секунды. Если сразу повторить его в той же сесси то уже моментально за ~ .5ms

...

Рейтинг:

0 / 0

25.02.2016, 15:37

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

Очень долгий update на 30М записей

#39178987

Alexius

Участник

Сообщения: 749

Рейтинг: 0 / 0

nateless,

насколько длинные? смотреть можно так например:

Код: sql

select max(age(now(), query_start)) from pg_stat_activity where state <> 'idle' and query not like '%autovacuum%';

покажите вывод

Код: sql

1.
2.
3.

\dt+ cluster_addresses
\di+ index_cluster_addresses_on_cluster_id
explain select count(*) from cluster_addresses;

...

Рейтинг:

0 / 0

25.02.2016, 15:52

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

Очень долгий update на 30М записей

#39179013

vyegorov

Участник

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

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

Рейтинг: 0 / 0

nateless,

А что выдаст такой запрос?Желательно запустить в `psql` с ключём `\x` (для построчного вывода):

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.

WITH bgstats AS (
  SELECT checkpoints_timed,
         checkpoints_req,
         checkpoints_timed + checkpoints_req checkpoints,
         checkpoint_sync_time,
         checkpoint_write_time,
         buffers_checkpoint,
         buffers_clean,
         maxwritten_clean,
         buffers_backend,
         buffers_backend_fsync,
         buffers_alloc,
         buffers_checkpoint + buffers_clean + buffers_backend total_buffers,
         pg_postmaster_start_time() startup,
         stats_reset,
         round(extract('epoch' from now() - stats_reset)/60)::numeric min_since_reset,
         --round(extract('epoch' from age(now(), current_date))/60)::numeric min_since_reset,
         delay.setting::numeric bgwriter_delay,
         lru.setting::numeric bgwriter_lru_maxpages,
         ratio.setting::numeric bgwriter_lru_multiplier
    FROM pg_stat_bgwriter
    JOIN pg_settings lru   ON lru.name = 'bgwriter_lru_maxpages'
    JOIN pg_settings delay ON delay.name = 'bgwriter_delay'
    JOIN pg_settings ratio ON ratio.name = 'bgwriter_lru_multiplier'
)
SELECT round(100.0*checkpoints_req/checkpoints,1)                 forced_ratio,
       round(min_since_reset/checkpoints,2)                       min_between,
       round(checkpoint_write_time::numeric/(checkpoints*1000),2) write_time_avg,
       round(checkpoint_sync_time::numeric/(checkpoints*1000),2)  sync_time_avg,
       round(total_buffers/128.0,1)                               mb_total,
       round(buffers_checkpoint/(128.0*checkpoints),2)            mb_per_ckpt,
       round(buffers_checkpoint/(128.0*min_since_reset*60),2)     mbps_ckpt,
       round(buffers_clean/(128.0*min_since_reset*60),2)          mbps_bgw,
       round(buffers_backend/(128.0*min_since_reset*60),2)        mbps_sess,
       round(total_buffers/(128.0*min_since_reset*60),2)          mbps_total,
       round(100.0*buffers_checkpoint/total_buffers,1)            pct_ckpt,
       round(100.0*buffers_clean/total_buffers,1)                 pct_bgw,
       round(100.0*buffers_backend/total_buffers,1)               pct_sess,
       round(100.0*maxwritten_clean/(min_since_reset*60000/bgwriter_delay),2) bgw_halt_only_len,
       round(100.0*maxwritten_clean/(nullif(buffers_clean,0)/bgwriter_lru_maxpages),2)  bgw_halt_ratio,
       round(1.0*buffers_alloc/total_buffers,3)                   new_ratio,
       now()-pg_postmaster_start_time()                           uptime,
       *
  FROM bgstats;

Я бы сделал так:
1. изменил настройки:namesettingautovacuum_max_workers20autovacuum_vacuum_cost_delay-1autovacuum_analyze_scale_factor0.05autovacuum_vacuum_scale_factor0.02log_autovacuum_min_duration1000vacuum_cost_delay5bgwriter_delay100bgwriter_lru_maxpages1000bgwriter_lru_multiplier5commit_delay5000commit_siblings3
2. перезапустил Postgres (перечитать конфиг не поможет)

3. сделал бы `VACUUM ANALYZE cluster_addresses`

4. Перестроил бы индекс:

Код: sql

1.
2.
3.

CREATE INDEX CONCURRENTLY i_ca_cluster ON cluster_addresses (cluster_id);
DROP INDEX index_cluster_addresses_on_cluster_id;
ALTER INDEX i_ca_cluster RENAME TO index_cluster_addresses_on_cluster_id;

5. Ещё раз `VACUUM ANALYZE cluster_addresses`

И киньте `EXPLAIN (analyze, buffers)` после этого.

...

Рейтинг:

0 / 0

25.02.2016, 16:03

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

Очень долгий update на 30М записей

#39179233

nateless

Гость

vyegorov,

Спасибо попробую, как только разберемся что с диском, не смогли выключить postgresql, полезли в логи там нашли кучу

Feb 25 13:54:54 Ubuntu-1510-wily-64-minimal kernel: [1259419.134935] sd 3:0:0:0: [sdc] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
Feb 25 13:54:54 Ubuntu-1510-wily-64-minimal kernel: [1259419.134936] sd 3:0:0:0: [sdc] tag#7 CDB: Write(10) 2a 00 1a 16 29 90 00 05 40 00
Feb 25 13:54:54 Ubuntu-1510-wily-64-minimal kernel: [1259419.134937] blk_update_request: I/O error, dev sdc, sector 437660048
Feb 25 13:54:54 Ubuntu-1510-wily-64-minimal kernel: [1259419.134963] EXT4-fs warning (device sdc1): ext4_end_bio:332: I/O error -5 writing to inode 787752 (offset 0 size 0 starting block 547
07674)

Видимо были проблемы с диском, hdparam не запустить виснет, сейчас общаемся с поддержкой на тему замены диска, не знаю на сколько повреждены данные, как восстановим будем дальше оптимизироваться.

...

Рейтинг:

0 / 0

25.02.2016, 18:15

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

Очень долгий update на 30М записей

#39179237

ScareCrow

Участник

Откуда: Белый город

Сообщения: 16 205

Рейтинг: 0 / 0

авторМожно ли как-то прогрузить всю таблицу cluster_addresses в память
select count(*) from table_name

...

Рейтинг:

0 / 0

25.02.2016, 18:19

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

Очень долгий update на 30М записей

#39179247

vyegorov

Участник

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

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

Рейтинг: 0 / 0

ScareCrowselect count(*) from table_name
Чтобы избежать вымывания буферного кэша выделяется ограниченное кол-во буфферов, которые циклично используются для сканирования (SeqScan, Vacuum, etc.).

Можно проверить, запустив `EXPLAIN (analyze, buffers) SELECT * FROM big_table` и наблюдая как меняются blocks hit / blocks read.

...

Рейтинг:

0 / 0

25.02.2016, 18:43

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

Очень долгий update на 30М записей

#39181710

nateless

Гость

vyegorov,

Заного проиндексировали все, заняло 3 дня, дошли до того-же уровня, спайки пока такие же примерно

Диск загружен на 50% примерно:

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdc 0.00 113.20 3.20 2135.80 220.80 192240.00 179.95 43.58 21.03 57.00 20.98 0.27 57.68

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdc 0.20 48.20 3.60 2089.40 184.00 137387.20 131.46 53.59 25.53 13.33 25.55 0.20 41.52

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdc 0.00 46.00 5.60 2038.60 78.40 141438.40 138.46 52.25 25.63 0.43 25.70 0.21 42.64

Запрос выдал следующее:

Код: plsql

1.
2.
3.
4.

 forced_ratio | min_between | write_time_avg | sync_time_avg | mb_total | mb_per_ckpt | mbps_ckpt | mbps_bgw | mbps_sess | mbps_total | pct_ckpt | pct_bgw | pct_sess | bgw_halt_only_len | bgw_halt_ratio | new_ratio |     uptime     | checkpoints_timed | checkpoints_req | checkpoints | checkpoint_sync_time | checkpoint_write_time | buffers_checkpoint | buffers_clean | maxwritten_clean | buffers_backend | buffers_backend_fsync | buffers_alloc | total_buffers |           startup            |          stats_reset          | min_since_reset | bgwriter_delay | bgwriter_lru_maxpages | bgwriter_lru_multiplier
--------------+-------------+----------------+---------------+----------+-------------+-----------+----------+-----------+------------+----------+---------+----------+-------------------+----------------+-----------+----------------+-------------------+-----------------+-------------+----------------------+-----------------------+--------------------+---------------+------------------+-----------------+-----------------------+---------------+---------------+------------------------------+-------------------------------+-----------------+----------------+-----------------------+-------------------------
         33.9 |        4.30 |         169.11 |          0.00 |  73429.8 |     1272.69 |      4.93 |     0.00 |      0.15 |       5.08 |     97.1 |     0.0 |      2.9 |              0.00 |                |     0.110 | 04:01:09.60985 |                37 |              19 |          56 |                    0 |               9470428 |            9122615 |             0 |                0 |          276398 |                     0 |       1031120 |       9399013 | 2016-02-29 11:09:44.88081+01 | 2016-02-29 11:10:18.411516+01 |             241 |            200 |                   100 |                       2
(1 row)

Сейчас обновлю конфиги по вакууму и посмотрю как дальше пойдет.

...

Рейтинг:

0 / 0

29.02.2016, 17:14

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

Очень долгий update на 30М записей

#39181730

qwwq

Участник

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

Рейтинг: 0 / 0

natelessvyegorov,

Заного проиндексировали все, заняло 3 дня, дошли до того-же уровня, спайки пока такие же примерно
вот ничего не понятно. вы что--то о своём, о девичьем.

что такое "уровень" ? какой он "такой же" ?
а тем паче "спайки" -- может быть ещё и "рубцы" ?
и что вы проиндексировали "за ногу"

пишите битым словом:
1. "вставили столько того--то",
2."наапдейтили с тех пор, как отреидексили -- ещё 100500 раз"

если 2--е -- перейдите на другую субд. или найдите чела, который нарисует вам архитектуру, в которой 100500 раз в большой табличке не апдейтятся.
ибо это -- не для пж. (сходите на "Сравнение СУБД", там вам Йо расскажет, какой плохой пж, и хароши ара,)

если не 2--е . -- я бы поискал долгие локи. и очереди на разделяемый ресурс. Но это -- именно если вы не делаете "2".

Если делаете -- то кто же вам виноват? Пишите конкурентный (ручной) реиндекс в вечном цикле (с конкурентным же дропом предыдущих версий). Не взлетит, так поплавает.

...

Рейтинг:

0 / 0

29.02.2016, 17:34

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

Очень долгий update на 30М записей

#39181735

nateless

Гость

qwwq,

Извиняюсь за ошибки. Я к тому что после замены жесткого диска мы начали процесс с нуля. После наполнения базы и начала нашего кластерного анализа, дошли до того же уровня кластеров как на момент предыдущих сообщений. После замены диска видим примерно такие же делеи при выполнении запросов. Что подтекстом говорит что прошлая проблема была не связана с багнутым жестким диском.

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

...

Рейтинг:

0 / 0

29.02.2016, 17:41

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

Очень долгий update на 30М записей

#39181743

qwwq

Участник

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

Рейтинг: 0 / 0

nateless,

а прикинуть на пальцах, сколько версий одной и той же записи вы наапдейчиваете [или наделет--наинсёрчиваете] в сутки -- вы можете ? как долго версия у вас живёт ? она, запись эта, принципиально все время переписывается ?

или это просто так заливка организована, не подумав ? кончится -- и перестанете теребонькать ?

...

Рейтинг:

0 / 0

29.02.2016, 17:53

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

Очень долгий update на 30М записей

#39181754

nateless

Гость

qwwq,

Так сложно сказать, всего есть 140М транзакций, в которых около 400М outputs которые мы кластеризуем. Сейчас при создании такой БД это разовая работа, дальше мы будем индексировать около 200.000 транзакций в сутки ( что дает около 600к новых outputs в сутки ).

В дальнейшем БД используется как аналитика, выборка кластеров и прочее. Иногда планируется прогонять заного создание кластеров, а так же рекластеризацию определенных записей согласно новым паттернам.

Сейчас идет огромное колличество создания и изменения кластеров, так как они образовываются учитывая наши паттерны, но учитывая обьемы данных при таких задержка в 3 секунды на апдейт кластера это займет слишком большее колличество времени.

...

Рейтинг:

0 / 0

29.02.2016, 18:01

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

Очень долгий update на 30М записей

#39181759

nateless

Гость

nateless,

Через буквально пару минут после адпейта конфига, замены индекса и vacuum:

D, [2016-02-29T16:01:55.368858 #5592] DEBUG -- : SQL (1853.1ms) UPDATE "cluster_addresses" SET "cluster_id" = 2632320 WHERE "cluster_addresses"."cluster_id" = $1 [["cluster_id", 5073322]]

Тот же запрос в psql меньше чем через минуту:

Код: plsql

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

explain (analyze, buffers) UPDATE "cluster_addresses" SET "cluster_id" = 2632320 WHERE "cluster_addresses"."cluster_id" =5073322;
                                                                                  QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Update on cluster_addresses  (cost=0.43..160809.60 rows=192469 width=14) (actual time=227.168..227.168 rows=0 loops=1)
   Buffers: shared hit=14445 dirtied=8829
   ->  Index Scan using index_cluster_addresses_on_cluster_id on cluster_addresses  (cost=0.43..160809.60 rows=192469 width=14) (actual time=227.167..227.167 rows=0 loops=1)
         Index Cond: (cluster_id = 5073322)
         Buffers: shared hit=14445 dirtied=8829
 Planning time: 0.084 ms
 Execution time: 227.181 ms
(7 rows)

...

Рейтинг:

0 / 0

29.02.2016, 18:04

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

25 сообщений из 29, страница 1 из 2

все

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий update на 30М записей

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

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

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

start [/forum/topic.php?fid=53&msg=39178133&tid=1997396]:	0ms
get settings:	5ms
get forum list:	15ms
check forum access:	3ms
check topic access:	3ms
track hit:	42ms
get topic data:	9ms
get forum data:	2ms
get page messages:	66ms
get tp. blocked users:	1ms
others:	218ms

total:	364ms

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