Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий update на 30М записей / 25 сообщений из 29, страница 1 из 2
  1  все
24.02.2016, 19:32
    #39178123
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
Все пытаюсь бороться с 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:49
    #39178133
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
Забыл еще про пару настроек:

shared_buffers = 16GB
temp_buffers = 16MB
wal_level = minimal
fsync = off
synchronous_commit = off
checkpoint_completion_target = 0.9
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
24.02.2016, 21:21
    #39178168
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
nateless,

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

http://raghavt.blogspot.com/2014/06/utilising-caching-contribs-pgprewarm.html
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.02.2016, 00:12
    #39178238
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
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, 02:07
    #39178258
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
nateless,

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

вот скоко оно страничек за 6 сек поднимает --- вывести буферсы не пробовали в експлейне ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.02.2016, 14:21
    #39178814
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
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:41
    #39178838
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
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, 15:01
    #39178881
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
qwwq,

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

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

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

autovacuum вообще включен? что говорит:
Код: sql
1.
SELECT name, setting, unit FROM pg_settings WHERE name ~ 'autov|vacuum';


Думаю, что нужно настроить autovacuum очень агрессивно, пройтись VACUUM-ом по всем таблицам и перестроить индексы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.02.2016, 15:04
    #39178887
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
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:08
    #39178891
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
vyegorov,

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

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

Для реидекса без останова -- максимову приблуду, наверное, надо поюзать. нет ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.02.2016, 15:27
    #39178922
Alexius
Alexius
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
nateless,

длинные транзакции есть?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.02.2016, 15:30
    #39178927
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
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:32
    #39178930
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
Сделал 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:37
    #39178948
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
nateless,

При этом это повторные запросы, тоесть я веду лог запросов от Rails, вижу что он занят 3с, в другом окне через пару секнуд делают его же аналайз и он все равно выполняется 3 секунды. Если сразу повторить его в той же сесси то уже моментально за ~ .5ms
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.02.2016, 15:52
    #39178987
Alexius
Alexius
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
nateless,

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

Код: sql
1.
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, 16:03
    #39179013
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
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, 18:15
    #39179233
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
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:19
    #39179237
ScareCrow
ScareCrow
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
авторМожно ли как-то прогрузить всю таблицу cluster_addresses в память
select count(*) from table_name
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.02.2016, 18:43
    #39179247
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
ScareCrowselect count(*) from table_name
Чтобы избежать вымывания буферного кэша выделяется ограниченное кол-во буфферов, которые циклично используются для сканирования (SeqScan, Vacuum, etc.).

Можно проверить, запустив `EXPLAIN (analyze, buffers) SELECT * FROM big_table` и наблюдая как меняются blocks hit / blocks read.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.02.2016, 17:14
    #39181710
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
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:34
    #39181730
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
natelessvyegorov,

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

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

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

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

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

Если делаете -- то кто же вам виноват? Пишите конкурентный (ручной) реиндекс в вечном цикле (с конкурентным же дропом предыдущих версий). Не взлетит, так поплавает.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.02.2016, 17:41
    #39181735
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
qwwq,

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

Отписал я по инфе с запросом, сейчас после апдейта конфигов по вакуму пришлю новые данные, там уже будем думать. Стоит ли оставаться на PG или искать другие решения.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.02.2016, 17:53
    #39181743
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
nateless,

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

или это просто так заливка организована, не подумав ? кончится -- и перестанете теребонькать ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.02.2016, 18:01
    #39181754
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
qwwq,

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

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

Сейчас идет огромное колличество создания и изменения кластеров, так как они образовываются учитывая наши паттерны, но учитывая обьемы данных при таких задержка в 3 секунды на апдейт кластера это займет слишком большее колличество времени.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.02.2016, 18:04
    #39181759
nateless
nateless
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Очень долгий update на 30М записей
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
| Ответить | Цитировать | Написать  
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Очень долгий update на 30М записей / 25 сообщений из 29, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 469ms
Закрыть
start [/forum/topic.php?fid=53&tablet=1&tid=1997396]:
 0ms
get settings:
 8ms
get forum list:
 14ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 148ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 228ms
total:  469ms
x
x
Закрыть


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