LINUX.ORG.RU
ФорумAdmin

Как узнать размер доступной памяти ?

 


0

1

Есть ли какая-либо тулза, параметр в proc или еще чего, которое показывает значение доступной памяти на текущий момент времени.

Именно доступной, а не свободной, с учетом настроек всяческих оверкоммитов и прочее прочее.

Предложением самому писать скрипт с подсчетом VIRT/RES и прочей арифметикой просьба не беспокоить. Нет так нет.

★★

Ответ на: комментарий от hope13

не угадал.

Именно доступной, а не свободной, с учетом настроек всяческих оверкоммитов и прочее прочее.

TEX ★★ ()

Есть ли какая-либо тулза, параметр в proc или еще чего, которое показывает значение доступной памяти на текущий момент времени.

NoWay

Нет так нет.

всегда рад помочь.

emulek ()
аree -m
total used free shared buffers cached
Mem: 3272 3220 51 0 84 1412
-/+ buffers/cache: 1723 1548
Swap: 0 0 0

1723

darkenshvein ★★★★★ ()
Ответ на: комментарий от darkenshvein

Неверно. При станадрном vm.overcommit_memory=[0 или 1] для 64битной системы доступно примерно грубо 2^64-VIRT-1

TEX ★★ ()
Ответ на: комментарий от TEX

А зря... alloc же как то её вычисляет

ты хотел сказать malloc(3)? Увы, оно тебе и Over9000 мегабайт выделит, когда у тебя всего 256.

emulek ()
Ответ на: комментарий от TEX

для 64битной системы доступно примерно грубо 2^64-VIRT-1

а... Тебе это число зачем-то надо? Ну считай. Функции нет, потому что оно кроме тебя, никому не нужно.

emulek ()
Ответ на: комментарий от emulek

а... Тебе это число зачем-то надо?

А ты подумай насколько это прекрасный параметр для мониторинга и аудита.

Вот сейчас кривущий fop на Java выносит мне мозг своим

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 303376 bytes for Chunk::new
в произвольные моменты на относительно ровном месте. И хотя причина в целом понятна, отмониторить ситуацию и окружение когда вот вот скорее всего начнется, я не представляю как

Ну считай.

Было бы куда проще если разрабы ядра, что поддерживают alloc, сами это считали. А считать самому ... можно но малореально, на одном подсчете памяти потоков и shared памяти энтузиазм уже как то пропадает

TEX ★★ ()
Ответ на: комментарий от emulek

Увы, оно тебе и Over9000 мегабайт выделит, когда у тебя всего 256.

Мне это и нужно. Вот только он не всегда выделяет Over9000. Самому отслеживать все условия нереально

TEX ★★ ()
Ответ на: комментарий от TEX

в произвольные моменты на относительно ровном месте. И хотя причина в целом понятна, отмониторить ситуацию и окружение когда вот вот скорее всего начнется, я не представляю как

страдай. Сочувствую.

Было бы куда проще если разрабы ядра, что поддерживают alloc, сами это считали. А считать самому ... можно но малореально, на одном подсчете памяти потоков и shared памяти энтузиазм уже как то пропадает

подсчёт слишком дорогой. Потому не нужный. Увы. Я тут неоднократно спорил, меня назвали идиотом, а жабу — няшкой. Спорить дальше мне не интересно. Делай, потом расскажешь о результатах.

emulek ()
Ответ на: комментарий от TEX

Вот только он не всегда выделяет Over9000.

ну потому что сам подход дефективный. Не нужно выделять Over9000 если у тебя Over9000 процессов. В таком случае этот ваш жабоGC не эффективен, а ручками вам лениво. Вот и страдайте.

emulek ()
Ответ на: комментарий от emulek

подсчёт слишком дорогой.

Какой нафиг дорогой ? malloc её в том или ином виде и так считает.

TEX ★★ ()
Ответ на: комментарий от TEX

malloc её в том или ином виде и так считает.

нуяхз. Как так у жабы получается НЕ выделить 300К — мне непонятно. У меня такого не бывает.

emulek ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.