Solaris: почему prstat показывает десятки гигабайт

Если shared memory отображена только как часть процесса, выделившего ее, то сумма всей используемой памяти будет более точной. В нашем случае они все используют один и тот же сегмент размером 100 MB, но когда рассматриваются по отдельности, то каждый из них имеет в наличии 100 MB. Если сегмент shared memory отображен как часть каждого процесса, 100 MB-вый разделенный сегмент будет подсчитан дважды, поскольку он хоть в действительности и один, но присоединен ко множеству процессов. Таким путем Solaris предпочитает отображать использование памяти.
Взглянем на более практический пример, ниже у нас две очень простые программы: одна для создания сегмента shared memory (shm_creator), и вторая для присоединения к этому сегменту и отображения его в своем адресном пространстве:

Для того, чтобы отличать наши тестовые процессы от остальной статистики Solaris, мы создадим нового пользователя и project для распределения этих процессов. Кто не знаком с project, читайте документацию.

# groupadd -g 2222 test
# projadd -U test -p 2222 testproj
# projmod -c 'Test Project for SHM' testproj

Для запуска программ мы будем использовать команду newtask, которая позволит нам выполнять процессы в указанном проекте. Сначала запустим процесс сервера (shm_creator), который распределит сегмент shared memory.

# newtask -p testproj ./shm_creator

Если мы посмотрим на память, распределенную проектом с помощью prstat, мы увидим, что используется около 100 MB:

# prstat -J

Теперь мы запускаем процесс, который присоединяется к этому сегменту памяти: помните, что процесс не распределяет еще дополнительно 100 MB памяти, он только присоединяется к тому же самому сегменту shared memory, созданному первым процессом:

# newtask -p testproj ./shm_attach
String from SHM : Hello From Server ....

Из статистики prstat теперь видно, что проект в общей сложности распределил 200 MB, но помните, что реальная распределенная память - 100 MB.

# prstat -J

Другие инструментальные средства, которые могут использоваться для изучения shared memory, включают утилиты ipcs и pmap. Команда ipcs используется, чтобы отобразить сегменты shared memory, очереди сообщений и семафоры в Solaris. В наших целях мы будем использовать ее, чтобы взглянуть на сегмент shared memory, который мы создали:

# ipcs -m -J -t -p -o

IPC status from  as of Tue Mar 20 00:53:02 GMT+4 2007

T         ID      KEY        MODE        OWNER    GROUP NATTCH  CPID  LPID   ATIME    DTIME    CTIME          PROJECT

Shared Memory:

m         26   0x1e1b9    --rw-rw-rw-     root     root      2  3063  3065  0:25:23 no-entry  0:16:18        testproj 

Из вывода видно, что существуют два процесса, которые присоединены к этому сегменту (NATTCH) и что создатель сегмента принадлежит проекту testproj. Второй инструмент, который мы будем использовать - pmap, эта утилита показывает информацию об адресном пространстве для указанного процесса. В нашем случае мы будем использовать ее для наблюдения за процессом, который создал сегмент shared memory и процессом, который присоединился к нему. Сначала посмотрим на процесс, который создал shared memory-сегмент:

# pmap -x -a `pgrep shm_creator`

3063:   ./shm_creator

 Address  Kbytes     RSS    Anon  Locked Mode   Mapped File

08046000       8       8       8       - rwx--    [ stack ]

08050000       4       4       -       - r-x--  shm_creator

08060000       4       4       4       - rwx--  shm_creator

F8A00000  102400       4       4       - rwxs-    [ shmid=0x1a ]

FEED0000       4       4       4       - rwx--    [ anon ]

FEEE0000     736     724       -       - r-x--  libc.so.1

FEFA8000      24      24      24       - rw---  libc.so.1

FEFAE000       8       8       8       - rw---  libc.so.1

FEFC0000      24      12      12       - rwx--    [ anon ]

FEFC9000     132     132       -       - r-x--  ld.so.1

FEFFA000       4       4       4       - rwx--  ld.so.1

FEFFB000       8       8       8       - rwx--  ld.so.1

-------- ------- ------- ------- -------

total Kb  103356     936      76       -

В выводе можно видеть сегмент 100 MB, идентифицированный пометкой shmid=0x1a.
Если мы посмотрим на процесс, который присоединился к этому сегменту, то мы увидим тот же самый прикрепленный сегмент:

# pmap -x -a `pgrep shm_attach`

3065:   ./shm_attach

 Address  Kbytes     RSS    Anon  Locked Mode   Mapped File

08046000       8       8       8       - rwx--    [ stack ]

08050000       4       4       -       - r-x--  shm_attach

08060000       4       4       4       - rwx--  shm_attach

F8A00000  102400       4       4       - rwxs-    [ shmid=0x1a ]

FEED0000       4       4       4       - rwx--    [ anon ]

FEEE0000     736     724       -       - r-x--  libc.so.1

FEFA8000      24      24      24       - rw---  libc.so.1

FEFAE000       8       8       8       - rw---  libc.so.1

FEFC0000      24      12      12       - rwx--    [ anon ]

FEFC9000     132     132       -       - r-x--  ld.so.1

FEFFA000       4       4       4       - rwx--  ld.so.1

FEFFB000       8       8       8       - rwx--  ld.so.1

-------- ------- ------- ------- -------

total Kb  103356     936      76       -

Это только два процесса, совместно использующие 100 МБ: если посмотреть на базу Oracle, картина покажется более искаженной, если не знать, как интерпретировать статистику.
Каждый процесс сервера Oracle разделяет сегменты памяти для базы данных. Так как эти общие сегменты памяти в Oracle нередко достигают нескольких гигабайт, становится понятно, почему prstat может показывать большой объем используемой памяти.
Как последнее примечание, подобный случай существует и для shared-библиотек, поскольку они обычно загружаются в системе только раз и отображаются ко всем процессам, которые используют ту же самую shared-библиотеку. Поскольку они обычно намного меньше чем гигабайтовые сегменты распределенной памяти баз данных, то обычно остаются незамеченными.