P
вполне может быть параллельное выполнение
А, точно, так и есть. В таком случае доп. странность в том, что я ожидал выполнение 48 воркерами и EXPLAIN то показывал...
Size: a a a
2020 December 23
P
а сколько памяти в системе?
474GB, сейчас этот процесс откушал порядка 50GB и рост продолжается
AL
полагаю что делается дамп памяти (do_coredump) и сейчас в файловую систему делается дамп всей памяти
AL
косвенно можно посмотреть по утилизации диска (iostat -x -m 1) и по изменения свободного места на фс (df -h)
P
Алексей, может тогда проконсультируете и по следующему моменту:
У меня после выполнения долгих сугубо технических запросов на dev машине остается занято порядка 80GB из 474GB (бывает и больше, +/-), для того чтобы от этого избавиться я обычно просто перезагружаю постгрес.
Собственно после этого всегда и возникает вышеописанная проблема. Это, я так понимаю, подтверждает вашу гипотезу?
У меня после выполнения долгих сугубо технических запросов на dev машине остается занято порядка 80GB из 474GB (бывает и больше, +/-), для того чтобы от этого избавиться я обычно просто перезагружаю постгрес.
Собственно после этого всегда и возникает вышеописанная проблема. Это, я так понимаю, подтверждает вашу гипотезу?
AL
вобщем я предлагаю вам ждать... в какой-то момент система либо завершит то что она делает, либо придет OOM Killer и завершит принудительно
P
косвенно можно посмотреть по утилизации диска (iostat -x -m 1) и по изменения свободного места на фс (df -h)
пользуюсь iotop, он серьезной нагрузки на диск не показывает
upd.: чистоты эксперимента ради проверил и в iostat, — тоже самое
upd.: чистоты эксперимента ради проверил и в iostat, — тоже самое
MZ
Он в пайп пишет. Смотрите настройки дампа аля coredump_pattern
MZ
Может он по сети все передает
MZ
Или вообще сжимает
P
Может он по сети все передает
По сети ему, по идее, передавать некуда
AL
Алексей, может тогда проконсультируете и по следующему моменту:
У меня после выполнения долгих сугубо технических запросов на dev машине остается занято порядка 80GB из 474GB (бывает и больше, +/-), для того чтобы от этого избавиться я обычно просто перезагружаю постгрес.
Собственно после этого всегда и возникает вышеописанная проблема. Это, я так понимаю, подтверждает вашу гипотезу?
У меня после выполнения долгих сугубо технических запросов на dev машине остается занято порядка 80GB из 474GB (бывает и больше, +/-), для того чтобы от этого избавиться я обычно просто перезагружаю постгрес.
Собственно после этого всегда и возникает вышеописанная проблема. Это, я так понимаю, подтверждает вашу гипотезу?
ядро Linux устроено таким образом что всегда пытается закэшировать все что можно и такая ситуация когда "выедается" вся память это нормально (поисследуйте /proc/meminfo). Если вам крaй нужно чтоб была свободная память, попроубйте сбрасывать кэши (echo 3 > /proc/sys/vm/drop_caches) - но не злоупотребляйте этим на проде. Page cache он все-таки для ускорения, чтоб не читать все время с диска.
MZ
По сети ему, по идее, передавать некуда
Какое значение coredump_pattern?
AL
пользуюсь iotop, он серьезной нагрузки на диск не показывает
upd.: чистоты эксперимента ради проверил и в iostat, — тоже самое
upd.: чистоты эксперимента ради проверил и в iostat, — тоже самое
смотрите iostat он "ближе" к железу
P
ядро Linux устроено таким образом что всегда пытается закэшировать все что можно и такая ситуация когда "выедается" вся память это нормально (поисследуйте /proc/meminfo). Если вам крaй нужно чтоб была свободная память, попроубйте сбрасывать кэши (echo 3 > /proc/sys/vm/drop_caches) - но не злоупотребляйте этим на проде. Page cache он все-таки для ускорения, чтоб не читать все время с диска.
Благо, речь идёт о некоторых работах сугубо на dev серверах. В целом понял, спасибо
p
ядро Linux устроено таким образом что всегда пытается закэшировать все что можно и такая ситуация когда "выедается" вся память это нормально (поисследуйте /proc/meminfo). Если вам крaй нужно чтоб была свободная память, попроубйте сбрасывать кэши (echo 3 > /proc/sys/vm/drop_caches) - но не злоупотребляйте этим на проде. Page cache он все-таки для ускорения, чтоб не читать все время с диска.
ну 3 - в drop_caches слишком злобно. Достаточно 1
p
пользуюсь iotop, он серьезной нагрузки на диск не показывает
upd.: чистоты эксперимента ради проверил и в iostat, — тоже самое
upd.: чистоты эксперимента ради проверил и в iostat, — тоже самое
а iotop не покажет ничего для memory mapped i/o, которым пользуется pg
AL
ну 3 - в drop_caches слишком злобно. Достаточно 1
да норм..., от 2/3 мир не обрушится
MZ
По сети ему, по идее, передавать некуда
/proc/sys/kernel/core_pattern
P
/proc/sys/kernel/core_pattern
у меня ubuntu, там:
|/usr/share/apport/apport %p %s %c %d %P %E