am
Не?
Size: a a a
2021 January 13
W
Индексы и все остальное сервисное делается во время vacuum
ST
Ребят, а как сделать дамп бд на сервер, когда бд в докер-контейнере?
Чтобы файл дампа сохранить на сервере, не внутри контейнера
P.s. ступил, не загуглив сначала
Решение: https://stackoverflow.com/a/29913462/9545396
Чтобы файл дампа сохранить на сервере, не внутри контейнера
P.s. ступил, не загуглив сначала
Решение: https://stackoverflow.com/a/29913462/9545396
MZ
Да перестаньте. Я вопрос задал с надеждой, что это что-то очень обыденное и всем известное.
ну вариантов то может быть много. и прошёл update массовые, и планы изменились из-за входных параметров, и случайно таблицы увеличились больше 256мб, а у вас там indexonlyscan масштабные, или аудит подъехал, или ядро начало стояно мувать процессы ибо прерывания начали штормить...
лучше разок хоть как-то глянуть на треки, там сразу будет ответ. телепаты в отпуске увы...
лучше разок хоть как-то глянуть на треки, там сразу будет ответ. телепаты в отпуске увы...
VY
Вопрос по pg internals!
Есть база на выделенном сервере, где нагрузки всегда под горлышко (так задумано).
Где-то раз в 2 недели бекенды на несколько часов начинают жрать CPU как не в себя, рисуя на графиках красивый логарифм. При этом по IO не меняется вообще ничего. Вместе с CPU растет только buffer hit (все индексы полностью в RAM). «Тяжелых» запросов к базе нет, все быстрые и по индексам, но их много.
Что оно там делает? Индексы мнет? Как это называется?
Есть база на выделенном сервере, где нагрузки всегда под горлышко (так задумано).
Где-то раз в 2 недели бекенды на несколько часов начинают жрать CPU как не в себя, рисуя на графиках красивый логарифм. При этом по IO не меняется вообще ничего. Вместе с CPU растет только buffer hit (все индексы полностью в RAM). «Тяжелых» запросов к базе нет, все быстрые и по индексам, но их много.
Что оно там делает? Индексы мнет? Как это называется?
нету каких-то чисток данных в таблицах? где-нить в “начале” таблицы (физическом)?
VY
также интересно глянуть на топ работающих запросов в базе в такие моменты
AL
Вопрос по pg internals!
Есть база на выделенном сервере, где нагрузки всегда под горлышко (так задумано).
Где-то раз в 2 недели бекенды на несколько часов начинают жрать CPU как не в себя, рисуя на графиках красивый логарифм. При этом по IO не меняется вообще ничего. Вместе с CPU растет только buffer hit (все индексы полностью в RAM). «Тяжелых» запросов к базе нет, все быстрые и по индексам, но их много.
Что оно там делает? Индексы мнет? Как это называется?
Есть база на выделенном сервере, где нагрузки всегда под горлышко (так задумано).
Где-то раз в 2 недели бекенды на несколько часов начинают жрать CPU как не в себя, рисуя на графиках красивый логарифм. При этом по IO не меняется вообще ничего. Вместе с CPU растет только buffer hit (все индексы полностью в RAM). «Тяжелых» запросов к базе нет, все быстрые и по индексам, но их много.
Что оно там делает? Индексы мнет? Как это называется?
любопытно взглянуть на картину меняется ли количественно и качественно трафик запросов в моменты когда длится жор cpu.
AL
условный topN график самых прожорливых query по total_time/calls/rows
AL
условно говоря может там чтото из серии гдето между приложением и БД ломается кэш, и все приложения массово начинают спрашивать всё в БД, растет количество запросов и растет количество CPU usage, но учитывая что все в памяти, то IO как такового нет.
МШ
Вопрос по pg internals!
Есть база на выделенном сервере, где нагрузки всегда под горлышко (так задумано).
Где-то раз в 2 недели бекенды на несколько часов начинают жрать CPU как не в себя, рисуя на графиках красивый логарифм. При этом по IO не меняется вообще ничего. Вместе с CPU растет только buffer hit (все индексы полностью в RAM). «Тяжелых» запросов к базе нет, все быстрые и по индексам, но их много.
Что оно там делает? Индексы мнет? Как это называется?
Есть база на выделенном сервере, где нагрузки всегда под горлышко (так задумано).
Где-то раз в 2 недели бекенды на несколько часов начинают жрать CPU как не в себя, рисуя на графиках красивый логарифм. При этом по IO не меняется вообще ничего. Вместе с CPU растет только buffer hit (все индексы полностью в RAM). «Тяжелых» запросов к базе нет, все быстрые и по индексам, но их много.
Что оно там делает? Индексы мнет? Как это называется?
Первое, что сразу лезет в голову: количество выполняющихся запросов (которые не в
Второе - группировка запросов по типам. А потом уже всё остальное.
idle, а в любом другом состоянии) в момент жора, и в момент, когда более-менее нормальное состояние.Второе - группировка запросов по типам. А потом уже всё остальное.
D
Вообще реально похоже на очистку кеша
МШ
условно говоря может там чтото из серии гдето между приложением и БД ломается кэш, и все приложения массово начинают спрашивать всё в БД, растет количество запросов и растет количество CPU usage, но учитывая что все в памяти, то IO как такового нет.
Ну так количество активных запросов в условно-нормальном состоянии и в момент жора ЦПУ и покажет, куда лезть надо дальше: в пг, или таки в бек и прочие кеши.
YS
Да перестаньте. Я вопрос задал с надеждой, что это что-то очень обыденное и всем известное.
Hope is not a strategy. ;)
Т.е. более подробный мониторинг должен быть.
Вот напишут Вам сейчас кучу типичных причин — а как Вы выясните, какая из них вызывает эту проблему?
Т.е. более подробный мониторинг должен быть.
Вот напишут Вам сейчас кучу типичных причин — а как Вы выясните, какая из них вызывает эту проблему?
am
условный topN график самых прожорливых query по total_time/calls/rows
А как такое делают? Руками на стороне приложения?
am
также интересно глянуть на топ работающих запросов в базе в такие моменты
Как такую статистику собирают? Постгрес можно как-то попросить считать секунды по разным prepared statements?
am
ну вариантов то может быть много. и прошёл update массовые, и планы изменились из-за входных параметров, и случайно таблицы увеличились больше 256мб, а у вас там indexonlyscan масштабные, или аудит подъехал, или ядро начало стояно мувать процессы ибо прерывания начали штормить...
лучше разок хоть как-то глянуть на треки, там сразу будет ответ. телепаты в отпуске увы...
лучше разок хоть как-то глянуть на треки, там сразу будет ответ. телепаты в отпуске увы...
> и случайно таблицы увеличились больше 256мб, а у вас там indexonlyscan масштабные
Во-о-от. Какие слова загуглить, чтобы понять нумерологический смысл 256 мегабайт?
Во-о-от. Какие слова загуглить, чтобы понять нумерологический смысл 256 мегабайт?
am
условно говоря может там чтото из серии гдето между приложением и БД ломается кэш, и все приложения массово начинают спрашивать всё в БД, растет количество запросов и растет количество CPU usage, но учитывая что все в памяти, то IO как такового нет.
Нет, я исключил все внешние факторы. Иначе я дурак и нечего было спрашивать.
MZ
> и случайно таблицы увеличились больше 256мб, а у вас там indexonlyscan масштабные
Во-о-от. Какие слова загуглить, чтобы понять нумерологический смысл 256 мегабайт?
Во-о-от. Какие слова загуглить, чтобы понять нумерологический смысл 256 мегабайт?
1 страница visibility map. Но это не важно. Кстати, а что за железо? Сколько процессоров? Какие? Сколько ram? Может у вас page faultинг взлетает?
MZ
Хотя конечно это не на часы...
VY
Как такую статистику собирают? Постгрес можно как-то попросить считать секунды по разным prepared statements?
лучше всего https://okmeter.io/