Обсуждение: [pgsql-ru-general] Все запросы модификации БД уходят в статус sleep+waiting, что делать?

с базой что-то случилось, любой CREATE INDEX CONCURENTLY, VACUUM или
даже ANALYZE отображается в pg_top в таком виде

23982 postgres  20    0   28G   17M sleep   0:00  0.00%  0.00% postgres: unera taxi [local] ANALYZE waiting

и висят бесконечно (приписка waiting не убирается).

кильнуть можно, сделать действие нельзя.

что-то я гуглил и не нашел ничего что может мне помочь.

нагрузки на базу большой нет (но сама база большая).

pg_top показывает где-то раз в 2-3 секунды пользовательские запросы, а
все остальное время висит idle. нагрузка на хосте 0.6.

что можно подергать/покопать?
--

. ''`.            Dmitry E. Oboukhov <unera@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30
  `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756

> Блокировки смотрели?

да, чисто и тихо :)


и pg_stop_backup на вс случай проверил

https://wiki.postgresql.org/wiki/Lock_Monitoring - вот по этой статье
все запросы дают пустой список.

просмотрел логи OOM - думал вдруг кого убили ненароком (на хосте
правда 256 памяти), там тоже тишина
--

. ''`.            Dmitry E. Oboukhov <unera@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30
  `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756

> Пальцем в небо, но, возможно, что-то случилось со статистикой.

> Можете воспроизвести на новой таблице и сделать на ней,
> например, pg_stat_reset_single_table_counters(oid)

> К блокировкам - ACCESS EXCLUSIVE нигде нет?

не, проблема исключительно в одной таблице (я думаю с дисковым
хранилищем что-то случилось). блокировок EXCLUSIVE нет.


я так понял проблема начинает проявляться при попытке построить индекс

WHERE
   ...
    bla_json->'bla' IS NOT NULL

после этого и произошло данное: этот CREATE INDEX завис "навсегда",
его сняли часа через 4-5 и потом вошло вот в такое состояние
--

. ''`.            Dmitry E. Oboukhov <unera@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30
  `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756

короче рестартанул вчера БД.

после этого уходить запросы в waiting перестали.

запустил ANALYZE VERBOSE table - прошло

запустил для теста VACUUM ANALYZE VERBOSE table;

дошло до конца: проверило все индексы, обычно такой VACUUM перед
завершением выдает такие строчки (это с другой таблицы):

CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  analyzing "public.drivers"
INFO:  "drivers": scanned 15000 of 113723 pages, containing 17459 live
rows and 56560 dead rows; 15000 rows in sample, 503542 estimated total
rows
VACUUM

про CPU выдало и далее зависло похоже опять навсегда.


что можно посмотреть?
--

. ''`.            Dmitry E. Oboukhov <unera@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30
  `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756

> Проверить железо и перестроить таблицу в новом физически месте. Похоже,
> предположение про неисправность стораджа верно.

имеется реплика теоретически можно попробовать на него переключиться,
но интересно на реплике не будет ли та же проблема.

посмотрел в обновлениях 9.5 (стоял 9.5.4) есть такие вещи в
чейнджлоге:

    9.5.5
    + Fix WAL-logging of truncation of relation free space maps and visibility
      maps (Pavan Deolasee, Heikki Linnakangas)

      It was possible for these files to not be correctly restored during
      crash recovery, or to be written incorrectly on a standby server. Bogus
      entries in a free space map could lead to attempts to access pages that
      have been truncated away from the relation itself, typically producing
      errors like could not read block XXX: read only 0 of 8192 bytes.
      Checksum failures in the visibility map are also possible, if
      checksumming is enabled.
    9.5.6
    + Fix a race condition that could cause indexes built with CREATE INDEX
      CONCURRENTLY to be corrupt (Pavan Deolasee, Tom Lane)

      If CREATE INDEX CONCURRENTLY was used to build an index that depends on
      a column not previously indexed, then rows inserted or updated by
      transactions that ran concurrently with the CREATE INDEX command could
      have received incorrect index entries.  If you suspect this may have
      happened, the most reliable solution is to rebuild affected indexes
      after installing this update.

судя по всему прямо моя проблема. обновил БД будем посмотреть



> 2017-07-13 10:05 GMT+02:00 Dmitry E. Oboukhov <unera@debian.org>:

> короче рестартанул вчера БД.

> после этого уходить запросы в waiting перестали.

> запустил ANALYZE VERBOSE table - прошло

> запустил для теста VACUUM ANALYZE VERBOSE table;

> дошло до конца: проверило все индексы, обычно такой VACUUM перед
> завершением выдает такие строчки (это с другой таблицы):

> CPU 0.00s/0.00u sec elapsed 0.00 sec.
> INFO:  analyzing "public.drivers"
> INFO:  "drivers": scanned 15000 of 113723 pages, containing 17459 live
> rows and 56560 dead rows; 15000 rows in sample, 503542 estimated total
> rows
> VACUUM

> про CPU выдало и далее зависло похоже опять навсегда.

> что можно посмотреть?
> --

> . ''`.            Dmitry E. Oboukhov <unera@debian.org>
> : :’  :
> `. `~’               GPG key: 4096R/08EEA756 2014-08-30
> `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756

> --
> Regards, Andrei Lizenko
--

. ''`.            Dmitry E. Oboukhov <unera@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30
  `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756