AB
тут посмотреть что-нибудь подозрительное
Size: a a a
2021 February 01
LM
2), 3), 4) команды — пустые таблицы
LM
1)
AB
select * from pg_stat_activity where state~'in transaction' order by query_start desc limit 3;D
поняль, пасиба
Если записям таблицы, к которой применяете FROM, соответствует несколько записей в тех таблицах, которые связываете по LEFT JOIN, то COUNT покажет большее значение, чем без LEFT JOIN.
LM
select * from pg_stat_activity where state~'in transaction' order by query_start desc limit 3;
Не стал отображать ненужные на данный момент поля (dbname, ip, client, etc)
AB
Lina M
Не стал отображать ненужные на данный момент поля (dbname, ip, client, etc)
ну оно вроде не сильно древнее чтобы вал держать
AB
select last_archived_wal,pg_walfile_name(pg_current_wal_insert_lsn()) from pg_stat_archiver; вот тут ещё можно посмотреть на сколько чиселки отличаются архивированного вала и вала который пишетсяLM
select last_archived_wal,pg_walfile_name(pg_current_wal_insert_lsn()) from pg_stat_archiver; вот тут ещё можно посмотреть на сколько чиселки отличаются архивированного вала и вала который пишется
AB
Если они рядом - то похоже я бы проиграл литр пива если бы реально поспорил и место занято чем-то другим. Стоит посмотреть логи на предмет временных файлов.
AB
Lina M
да, всё заархивировано, похоже что место занято не валом
LM
Если они рядом - то похоже я бы проиграл литр пива если бы реально поспорил и место занято чем-то другим. Стоит посмотреть логи на предмет временных файлов.
Чтобы это сделать нужно, скорее всего, иметь прямое подключение к CLI PostgreSQL?
AB
Lina M
Чтобы это сделать нужно, скорее всего, иметь прямое подключение к CLI PostgreSQL?
нет, обычно в облачных базах есть способ посмотреть логи
LM
Потому что всё что доступно из Google Cloud:
AB
У нас вот так это выглядит, я думаю у них тоже есть.
AB
ещё в cli скорее всего есть возможность грепать по логам
LM
Вот буквально 5 минут назад было Emergency error:
"2021-02-01 16:52:17.879 UTC [2570102]: [64-1] db=db_test,user=superadmin PANIC: could not write to log file 0000000100000183000000A7 at offset 9043968, length 614400: Cannot allocate memory"
AB
это ООМ
AB
ООМ следствие того что много серверных бекендов каждый из которых со своим кешом. но что сожрало место?
VY
справедливости ради OOM следует в dmesg.