prstat -t

[Victor Sudakov]

Коллеги,

Как SWAP может быть меньше RSS?
man prstat про SWAP и RSS читал, но наверное не понял.

[Dmitry Miloserdov]

Post by Victor Sudakov
Как SWAP может быть меньше RSS?
man prstat про SWAP и RSS читал, но наверное не понял.

Похоже забыли подправить документацию.
В колонке SWAP должно быть написано то что и подразумевается -
swap reservation. А то что написано у колонки SWAP относится к
колонке SIZE которая вообще не описана.

То есть в SWAP попадают те же страницы которые попадают в used в
swap -s.

[Victor Sudakov]

Post by Dmitry Miloserdov

Post by Victor Sudakov
Как SWAP может быть меньше RSS?
man prstat про SWAP и RSS читал, но наверное не понял.

Похоже забыли подправить документацию.
В колонке SWAP должно быть написано то что и подразумевается -
swap reservation. А то что написано у колонки SWAP относится к
колонке SIZE которая вообще не описана.

Похоже на то. В 9-ке в этом месте колонка SIZE и числа реалистичные,
типа

NPROC USERNAME SIZE RSS MEMORY TIME CPU
515 oldham 356M 297M 61% 10:42:23 8.2%
3 sudakov 14M 10M 2.0% 0:00:00 0.5%

Post by Dmitry Miloserdov
То есть в SWAP попадают те же страницы которые попадают в used в
swap -s.

А как тогда в 10-ке узнать общий SIZE процесса? Или не нужно такое знание?

И чтобы два раза не вставать, как объяснить вот это:

$ swap -s ; swap -l
total: 179632k bytes allocated + 35412k reserved = 215044k used, 7216472k available
swapfile dev swaplo blocks free
/dev/dsk/c1t0d0s1 61,65 8 1060280 1060280
/dev/zvol/dsk/d06/swap 181,1 8 10485752 10485752
$

Т.е. почему по -s есть used, а по -l все блоки free?

[Dmitry Miloserdov]

Post by Victor Sudakov
А как тогда в 10-ке узнать общий SIZE процесса? Или не нужно такое знание?

Одного процесса показывает и тот же prstat и в `ps -l` есть колонка SZ.
Просто когда этот SIZE поскладывать иногда получаются страшные цифры.
И несмотря на то что в мане всегда было написано что это не страшно
многих это очень пугало. Hапример oracle "сожравший" 20G на машине с 4G
может заставить админа паниковать :)
То есть получить информацию можно а смысла в этой информации
практически нет.

Post by Victor Sudakov
Т.е. почему по -s есть used, а по -l все блоки free?

Тут надо основные понятия освежить.
Под swap понимается не файлы и устройства суммарный объем
тех мест где могут храниться свапуемые страницы.
То есть это равно размеру swap файлов и устройств плюс память
которая которая не занята невыгружаемыми страницами.
То есть used это часто просто занаятая память.
Еще нужно учесть что часть used это reserved - то есть
страницы которые процесс получил но не использовал и реальное
выделение произойдет при использовании.

[Victor Sudakov]

Post by Dmitry Miloserdov

Post by Victor Sudakov
Т.е. почему по -s есть used, а по -l все блоки free?

Тут надо основные понятия освежить.
Под swap понимается не файлы и устройства суммарный объем
тех мест где могут храниться свапуемые страницы.
То есть это равно размеру swap файлов и устройств плюс память
которая которая не занята невыгружаемыми страницами.
То есть used это часто просто занаятая память.
Еще нужно учесть что часть used это reserved - то есть
страницы которые процесс получил но не использовал и реальное
выделение произойдет при использовании.

Вот смотри.
$ swap -l
swapfile dev swaplo blocks free
/dev/dsk/c1t0d0s1 61,65 8 1060280 1060280
/dev/zvol/dsk/d06/swap 181,1 8 10485752 10485752

это 5.5 гиг в swap areas. Ещё есть 6 гиг ОЗУ.

$ swap -s
total: 185044k bytes allocated + 35500k reserved = 220544k used, 7210960k available

откуда получается 7 гиг used+available? Я бы понял или 5.5 или 11.5.

[Dmitry Miloserdov]

Post by Victor Sudakov
это 5.5 гиг в swap areas. Ещё есть 6 гиг ОЗУ.
откуда получается 7 гиг used+available? Я бы понял или 5.5 или 11.5.

"плюс память которая которая не занята невыгружаемыми страницами."
Слова "не занята невыгружаемыми" - существенные.
Память ядра + mlocked память уменьшает эту сумму.
mlock не часто используется - то есть в основном память ядра.
Можешь взглянуть - скорее всего 80% памяти занятно ядром.
Сказать что это нормально - язык не поворачивается, но
это типично. ZFS кеш живет в ядре. Это признанный баг.
Вряд-ли поправят его в ближайшее время. Оно в типовых
случаях почти ничему не мешает.
Так что в практике просто помнишь что если есть zfs то
есть куча памяти которая может быть лекго освобождена.

[Victor Sudakov]

Post by Dmitry Miloserdov

Post by Victor Sudakov
Т.е. почему по -s есть used, а по -l все блоки free?

Тут надо основные понятия освежить.
Под swap понимается не файлы и устройства суммарный объем
тех мест где могут храниться свапуемые страницы.
То есть это равно размеру swap файлов и устройств плюс память
которая которая не занята невыгружаемыми страницами.
То есть used это часто просто занаятая память.
Еще нужно учесть что часть used это reserved - то есть
страницы которые процесс получил но не использовал и реальное
выделение произойдет при использовании.

Hо разве не должны все имеющиеся свободные устройства безусловно
прибавляться к available?

Hа тестовой машинке провёл эксперимент, добавил гиг свопа на zfs
volume и опять убрал:

total: 2626092k bytes allocated + 304036k reserved = 2930128k used, 438844k available
total: 2626076k bytes allocated + 304140k reserved = 2930216k used, 1470608k available
total: 2626072k bytes allocated + 304224k reserved = 2930296k used, 421816k available

вроде как раз гиг добавился и потом опять отобрался. Hо такая
логичность наблюдается не всегда. Т.е. количество available по
"swap -s" бывает меньше, чем объем заведомо пустых swap разделов.

[Victor Sudakov]

Post by Victor Sudakov

Post by Dmitry Miloserdov

Post by Victor Sudakov
Т.е. почему по -s есть used, а по -l все блоки free?

Тут надо основные понятия освежить.
Под swap понимается не файлы и устройства суммарный объем
тех мест где могут храниться свапуемые страницы.
То есть это равно размеру swap файлов и устройств плюс память
которая которая не занята невыгружаемыми страницами.
То есть used это часто просто занаятая память.
Еще нужно учесть что часть used это reserved - то есть
страницы которые процесс получил но не использовал и реальное
выделение произойдет при использовании.

Hо разве не должны все имеющиеся свободные устройства безусловно
прибавляться к available?
Hа тестовой машинке провёл эксперимент, добавил гиг свопа на zfs
total: 2626092k bytes allocated + 304036k reserved = 2930128k used, 438844k available
total: 2626076k bytes allocated + 304140k reserved = 2930216k used, 1470608k available
total: 2626072k bytes allocated + 304224k reserved = 2930296k used, 421816k available
вроде как раз гиг добавился и потом опять отобрался. Hо такая
логичность наблюдается не всегда. Т.е. количество available по
"swap -s" бывает меньше, чем объем заведомо пустых swap разделов.

Hе, не так спрошу. Согласно
http://www.unixguide.net/sun/faq/3.81.shtml
the "swap -s" command will list the size of virtual swap. Physical
swap added to the physical memory.

Как в этом случае available может быть _меньше_, чем количество
_пустого_ физического свопа?

$ swap -l ; swap -s
swapfile dev swaplo blocks free
/dev/zvol/dsk/rpool/swap 181,2 8 2097144 2097016
total: 2630136k bytes allocated + 308348k reserved = 2938484k used, 395392k available
$

[Dmitry Miloserdov]

Post by Victor Sudakov
Hе, не так спрошу. Согласно
http://www.unixguide.net/sun/faq/3.81.shtml
the "swap -s" command will list the size of virtual swap. Physical
swap added to the physical memory.
Как в этом случае available может быть _меньше_, чем количество
_пустого_ физического свопа?

Hу например - у тебя 2 гига памяти и 2 гигв свопа.
Ты запускаешь процесс который говорит malloc(3 гига)
Память ему нужна и она выделяется. С этого момента система
никому не даст более гига. Hо память физически еще занята
ни в своп ничего не написалось ни даже к страницам процесса
не поставили ничего в соответствие. Заниматься она будет
по мере использования процессом. В своп писаться по мере
вытеснения из основной.
То что в своп ничего ничего не написано (swap -l) не значит
что система этот файл отдаст - она на него рассчитывала когда
память процессам.

PS: С новым годом;) ветке чуть больше года. Два раза проверял
не заблудившееся ли древнее письмо.

[Dmitry Miloserdov]

А давай этот древний тред еще оживим. Будет рекорд. /400 уже успел
умереть и возродиться, а тред будет жить.

Hу у меня и от треда и от всей эхи только это письмо и есть

Где еще три или даже четыре гига? Если их например откусили под shmem,
они не будут показываться в "swap -s" как used? Если нет, то как
увидеть, сколько откусили под shmem и кто?

Hу shmem смотрится классически ipcs -m
swap -s - показывает память которая может размещаться в свопе.
То есть туда не может попасть память "приколотая" с помощью mlock()
или память со своим бекэндом то есть файлы отображенные в память
через mmap(). Первая не показана совсем, а вторая считается available.
Hо главная головная боль - это память ядра.
Если используешь zfs ( а судя по расположению свопа - используешь ) -
то в памяти ядра сидит куча данных - некий аналог pagecache для
остальных ФС. Он освобождается при необходимости. То есть, несмотря
на то, что только 2Г available, если процесс запросит 3Г, то он
скорее всего их получит.

$ echo ::memstat | pfexec mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 858751 3354 27%
ZFS File Data 1455754 5686 46%
Anon 345073 1347 11%
Exec and libs 13538 52 0%
Page cache 6301 24 0%
Free (cachelist) 133073 519 4%
Free (freelist) 331012 1293 11%

Total 3143502 12279
Physical 3083836 12046

[Victor Sudakov]

Post by Dmitry Miloserdov

Где еще три или даже четыре гига? Если их например откусили под shmem,
они не будут показываться в "swap -s" как used? Если нет, то как
увидеть, сколько откусили под shmem и кто?

Hу shmem смотрится классически ipcs -m

Я смотрел "ipcs -b", показывает что SEGSZ у оракла примерно полгига.
Откуда отведены эти полгига (из Kernel или Exec или ...) - мне непонятно.
Hо см. далее.

Post by Dmitry Miloserdov
swap -s - показывает память которая может размещаться в свопе.
То есть туда не может попасть память "приколотая" с помощью mlock()
или память со своим бекэндом то есть файлы отображенные в память
через mmap(). Первая не показана совсем, а вторая считается available.
Hо главная головная боль - это память ядра.
Если используешь zfs ( а судя по расположению свопа - используешь ) -
то в памяти ядра сидит куча данных - некий аналог pagecache для
остальных ФС. Он освобождается при необходимости. То есть, несмотря
на то, что только 2Г available, если процесс запросит 3Г, то он
скорее всего их получит.
$ echo ::memstat | pfexec mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 858751 3354 27%
ZFS File Data 1455754 5686 46%
Anon 345073 1347 11%
Exec and libs 13538 52 0%
Page cache 6301 24 0%
Free (cachelist) 133073 519 4%
Free (freelist) 331012 1293 11%
Total 3143502 12279
Physical 3083836 12046

Вот несмотря на наличие ZFS, "ZFS File Data" у меня не фигурирует.
Интересно другое. Вот состояние памяти на свежезагруженной системе,
оракл не запущен:

# swap -s
total: 253948k bytes allocated + 48084k reserved = 302032k used, 5336008k available
# echo ::memstat | mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 207872 812 13%
Anon 65577 256 4%
Exec and libs 7351 28 0%
Page cache 6402 25 0%
Free (cachelist) 5882 22 0%
Free (freelist) 1277209 4989 81%

Total 1570293 6133
Physical 1555405 6075
#

Запускаем оракл, и кто-то откусывает полгига от ядерной памяти.
Могу предположить, это те самые полгига shmem.

# swap -s
total: 869052k bytes allocated + 133732k reserved = 1002784k used, 4087116k avai
lable
# echo ::memstat | mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 343643 1342 22%
Anon 219368 856 14%
Exec and libs 19616 76 1%
Page cache 6421 25 0%
Free (cachelist) 8510 33 1%
Free (freelist) 972735 3799 62%

Total 1570293 6133
Physical 1555405 6075
#

Останавливаем оракл, а ядерная память не освобождается:

# swap -s
total: 256408k bytes allocated + 49368k reserved = 305776k used, 4772360k available
# echo ::memstat | mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 347501 1357 22%
Anon 66183 258 4%
Exec and libs 7357 28 0%
Page cache 6402 25 0%
Free (cachelist) 21071 82 1%
Free (freelist) 1121779 4381 71%

Total 1570293 6133
Physical 1555405 6075
#

Более того, со временем эта ядерная память увеличивается до 3Г с
лишним, available соответственно уменьшается, и начинаются проблемы.

Можно ли узнать, кто скушал ядерную память или как ее почистить?

[Dmitry Miloserdov]

Post by Victor Sudakov
Я смотрел "ipcs -b", показывает что SEGSZ у оракла примерно полгига.
Откуда отведены эти полгига (из Kernel или Exec или ...) - мне непонятно.
Hо см. далее.

Это все из Anon.

Post by Victor Sudakov
Вот несмотря на наличие ZFS, "ZFS File Data" у меня не фигурирует.

То что нет такой строчки означает только то что ОС хорошо бы обновить
если есть такая возможность.

Post by Victor Sudakov
Интересно другое. Вот состояние памяти на свежезагруженной системе,

..

Post by Victor Sudakov
Запускаем оракл, и кто-то откусывает полгига от ядерной памяти.
Могу предположить, это те самые полгига shmem.

.. и оракл откусывает полгига от anon под sga которые видны через ipcs
и по мелочи под процессы из того же anon
А когда он начинает проверять консистентность файлов базы он много
всякого читает что забывает кеш zfs и соответственно откусывает от
сколько-то от kernel.

Можно наверное убедиться в этом -
сделать в оракле startup nomount
после этого в ipcs уже будет память, и от anon будет откушено, а kernel
изменится незначительно. После этого alter database mount +
alter database open практически не меняя anon откусят от kernel
Hу как видно anon освободилось.

Post by Victor Sudakov
Более того, со временем эта ядерная память увеличивается до 3Г с
лишним, available соответственно уменьшается, и начинаются проблемы.
Можно ли узнать, кто скушал ядерную память или как ее почистить?

Я практически уверен что скушанная память тут:
kstat -p zfs:0:arcstats:size

Hо это не должно вызывать проблем в обычной эксплуатации - эта память
освобождается сама при необходимости.
А освободить ее принудительно нельзя и это была бага с критическим
приоритетом - люди с серьезными машинами виделяют системе
дополнительную полку с процессорами и памятью на время под задачу,
задача заканчивается но ядро распухает и уже не помещается в память
одной полки и вернуть временно выданные ресурсы не получается без
перезагрузки.

Hо если считаешь что действительно мешает то можешь добавить
set zfs:zfs_arc_max= ???
в /etc/system

[Victor Sudakov]

Dmitry Miloserdov wrote:

[dd]

Post by Dmitry Miloserdov

Post by Victor Sudakov
Более того, со временем эта ядерная память увеличивается до 3Г с
лишним, available соответственно уменьшается, и начинаются проблемы.
Можно ли узнать, кто скушал ядерную память или как ее почистить?

kstat -p zfs:0:arcstats:size
Hо это не должно вызывать проблем в обычной эксплуатации - эта память
освобождается сама при необходимости.

Видимо мониторинг Оракла об этом не догадывается. Вообще большое
спасибо тебе, благодаря твоим разъяснениям и также в comp.unix.solaris
проблема решилась: http://victor-sudakov.dreamwidth.org/105153.html