Re: PANIC: could not flush dirty data: Cannot allocate memory

Поиск
Список
Период
Сортировка
От Christoph Moench-Tegeder
Тема Re: PANIC: could not flush dirty data: Cannot allocate memory
Дата
Msg-id Y3QB0aANtLBAjyVc@elch.exwg.net
обсуждение исходный текст
Ответ на Re: PANIC: could not flush dirty data: Cannot allocate memory  (klaus.mailinglists@pernau.at)
Список pgsql-general
## klaus.mailinglists@pernau.at (klaus.mailinglists@pernau.at):

> AFAIU the problem is not related to the memory settings in 
> postgresql.conf. It is the kernel that
> for whatever reasons report ENOMEM. Correct?

Correct, there's a ENOMEM from the kernel when writing out data.

> Filesystem is ext4. VM technology is mixed: VMware, KVM and XEN PV. 
> Kernel is 5.15.0-52-generic.

I do not suspect the filesystem per se, ext4 is quite common and we
would have heard something about that (but then, someone gotta be
the first reporter?). I would believe that the kernel would raise
a bunch of printks if it hit ENOMEM in the commonly used paths, so
you would see something in dmesg or wherever you collect your kernel
log if it happened where it was expected.
And coming from the other side: does this happen on all the hosts,
or is it limited to one host or one technology? Any uncommon options
on the filesystem or the mount point? Anything which could mess
with your block devices? (I'm expecially thinking "antivirus" because
it's always "0 days since the AV ate a database" and they tend to
raise errors in the weirdest places, which would fit the bill here;
but anythig which is not "commonly in use everywhere" could be a
candidate).

Regards,
Christoph

-- 
Spare Space



В списке pgsql-general по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: PANIC: could not flush dirty data: Cannot allocate memory
Следующее
От: gzh
Дата:
Сообщение: An I/O error occured while sending to the backend