поиск процессов, занимающих место в paging space

Главная Форумы Обсуждение материалов портала поиск процессов, занимающих место в paging space

В этой теме 33 ответа, 6 участников, последнее обновление  uxTuaHgp 5 года/лет, 9 мес. назад.

  • Автор
    Сообщения
  • #13392

    andrewk
    Участник

    [article]414[/article]

  • #13403

    uxTuaHgp
    Участник

    Спасибо, полезный скриптик.

  • #13405

    Ivan
    Участник

    -pLANG=C: 0403-010 A specified flag is not valid for this command.
    оставляешь просто путь к оболочке, пишет
    $ ./top_ps_process.sh
    ./top_ps_process.sh[2]: %-16st%-16st%-16st%sn: not found.

    6100-06-03-1048

  • #13409

    Под AIX 5.2 ML3 будет работать?

  • #13412

    andrewk
    Участник

    -pLANG=C: 0403-010 A specified flag is not valid for this command.
    оставляешь просто путь к оболочке, пишет
    $ ./top_ps_process.sh
    ./top_ps_process.sh[2]: %-16st%-16st%-16st%sn: not found.

    6100-06-03-1048

    как всегда – кривое форматирование. я не могу к сожалению изменить движок этого форума (а если мог бы – то не хочу) и поправить ему форматирование при использовании тэга code. Поэтому Вам придется немного применить голову, чтобы отформатировать скрипт правильно. Сорри.

  • #13414

    andrewk
    Участник

    Под AIX 5.2 ML3 будет работать?

    к счастью, AIX 5.2 в зоопарке сейчас нет, поэтому не тестировал. Но Вы всегда можете попробовать – скрипт не форматирует rootvg и не запускает никаких “взрывоопасных” команд 🙂 Все, что он делает – форматирует вывод svmon.

  • #13421

    Дмитрий
    Участник

    Под AIX 5.2 ML3 будет работать?

    В AIX 5.1 работает.
    svmon – он и в 5.1 svmon.

    Только ‘рекбус’ с форматированием решить нужно.

    AIXPortal.RU – лучший Форум, на которм вы не только можете задавать/получать вопросы, но и изучите shell! 😛

  • #13430

    Alex
    Участник

    В AIX 5.1 работает.
    svmon – он и в 5.1 svmon.

    Не совсем верно. svmon-у синтаксис меняли. В 5.3.8TL5, например, нет ключа -O. Соответственно можно прикинуть по времени и для 5.2, 5.1.

  • #13447

    Дмитрий
    Участник

    не возражаю.

    man svmon рассказывает о ключе -g

    Чужой скрипт не надо просто так запускать – надо в нём разобраться! B)

  • #16926

    uxTuaHgp
    Участник

    А можно верить выводу этого скрипта?
    svmon -S -lrj выдает множество PID-ов, видимо для сегментов разделяемой памяти, и в результате выпадают ошибки.

    Потом из ps axv я вижу процессы, которые занимают и по ~500МБ, а svmon больше 256МБ сегменты не показывает.

    Как-то иначе нужно наверное интерпретировать вывод svmon…

    Получается, что очень сложно оценить адекватно с помощью svmon и прочих утилит AIX, сколько для каждого процесса в физ памяти, в свопе, в виртуальной памяти. И вообще кто потребляет память и почему система лезет в своп.
    Инструмент выдает какие-то полуфабрикаты, а не отчеты.

  • #16927

    andrewk
    Участник

    100% верить никому нельзя 🙂 В первую очередь – ps. svmon показывает то, что есть на самом деле. Если программа состоит из десятка сегментов, но в свап попал только один, то только он один и будет показан. Оценить, сколько реально занимает процесс места в памяти, невозможно. Времена, когда процесс был статическим прошли давно и безвозвратно. Каждый процесс использует кроме своей “личной” памяти еще разделяемые между несколькими процессами библиотеки, сегменты Shared Memory, файловый кэш и увеличивает потребление памяти ядром. Как все это учесть? Никак! Поэтому и самый правильный вывод – по сегментам памяти, а потом искать, кому этот сегмент принадлежит. Принадлежит какому-то процессу? Хорошо! Можно процесс рестартовать. Принадлежит Shared Memory? ipcs в руки, кто там зааллоцировал этот сегмент? Кому он вообще нужен? Библиотека? И никем не используется? slibclean! Тут не может быть готового инструмента.

  • #16929

    uxTuaHgp
    Участник

    Шареные сегменты не очень интересны и потом их можно приплюсовать отдельно, благо их можно увидеть.

    Совершенно прикладная задача: система полезла в свап.
    Предполагается, что количество процессов в системе – константа.
    Нужно определить какой из процессов стал жрать с особенным аппетитом.

    Топ сегментов по инюз или вирчуал не очень помогает – они все по 256МБ.
    Сваппед сегменты – это просто сегменты, к которым давно не обращались, а процессы, которые пухнут активно наоборот все в оперативной памяти.
    Может быть я не прав, но ценность такого отчета сомнительна.

    Буду копать svmon со скриптоами пожалуй в сторону группировки сегментов по процессам…
    Или нет смысла и достаточно опереться на
    ps axv
    и
    svmon -P -t 10

    для выявления прожорливых?

  • #16930

    uxTuaHgp
    Участник

    Я вижу, что размер сегмента зависит от объема памяти в системе.
    Однако не срастается:

    допустим у меня меня 250 ГБ памяти,
    размер сегмента 256МБ
    при 2000 процессов будет выделено не менее 2000 сегментов по 256МБ?
    В сумме получается 512ГБ?

    Или несколько процессов могут размещаться в одном сегменте?

  • #16931

    andrewk
    Участник

    система полезла в свап – и пускай там находится, если ей очень хочется. вот если она очень активно делает page in/page out, либо она настолько залезла в свап, что уже свободной памяти не остается, то надо искать.

    вся память в AIX’е поделена на сегменты, поэтому все равно, как ни крути, все равно придется смотреть в их сторону. При просмотре svmon -P показываются только сегменты, принадлежащие процессам, т.о. сегменты, принадлежащие, например, ядру, показаны не будут. Какой вывод будет сделан в результате этого анализа – хз. ps вообще по моему нескромному мнению показывает непонятно что. Т.е. если уж на то пошло, то правильнее смотреть вывод svmon -S, а потом его группировать по процессам. Но при этом надо учитывать, что один сегмент может принадлежать нескольким процессам сразу же. Например, если 10 раз запускается ls, AIX не аллоцирует память под 10 копий команды, а создает только один сегмент, которым пользуются сразу же 10 процессов.

    Размер сегмента не зависит от объема памяти – они все разные. И совсем не обязательно, что под 2000 процессов будет выделено 2000 сегментов по 256МБ. Если мне не изменяет память, то под 2000 процессов легко будет выделено 4000 сегментов (если все процессы “уникальные”)

  • #16932

    andrewk
    Участник

    с тестовой системы:

    # svmon -S | wc -l
    8633
    # ps -efk | wc -l
    93

  • #16935

    andrewk
    Участник

    и сразу же оттуда пример:

    # svmon -S 801b60 -lrj

    Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
    801b60 – clnt /dev/lvbmc:4 s 20185 0 – –
    /bmc/RSCD82-AIX32.sh
    Addr Range: 0..20240
    Unused segment

    Вот лежит файл в памяти, никем не используемый. Когда использовался – система загрузила его в кэш, так до сих пор и лежит.

  • #16936

    andrewk
    Участник

    а вот сегмент какой-то библиотеки, которая не принадлежит никакому процессу:

    # svmon -S 8c8019 -lrj

    Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
    8c8019 90000000 work shared library text m 968 0 0 968
    Addr Range: 0..1098
    Shared library text segment

  • #16937

    andrewk
    Участник

    а эти библиотечные данные принадлежат какому-то процессу:

    # svmon -S 8d001a -lrj

    Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
    8d001a 9001000a work shared library data m 174 0 0 174
    Addr Range: 0..492
    pid(s)=1769618
    # ps -ef | grep 1769618
    root 1769618 1 0 Oct 10 – 0:00 /usr/ccs/bin/shlap64

  • #16938

    andrewk
    Участник
  • #16939

    uxTuaHgp
    Участник

    Ага, спасибо.

    А я вот чего увидел
    Руки бы оборвать тем, кто это русифицировал…
    Делаю вывод, что ps v дает адекватную информацию о памяти, потребляемой процессом.
    А топ сегментов все же странная штука: у меня топ и 5 и 100 и 1000 выдают сегменты с inuse 256МБ.
    И в чем смысл такого топа?
    Детально разбирать ладно еще, но тогда с чего начинать, как нащупывать те самые жирные?

  • #17003

    uxTuaHgp
    Участник

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

  • #17006

    andrewk
    Участник

    Сегмент может иметь страницы, как в физической памяти, так и (одновременно) в пейджинге:

    Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
    8000 – work page table area s 2583 43 2540 2583

    данный сегмент имеет 2540 страниц в пейджинге, а 43 страницы запинены в физической памяти. Сорри, лучшего примера сейчас нет.

    Т.е., если я правильно понимаю, такие страницы просто два раза отображаются – один раз в пейджинге, один раз вне его (Inuse – Pgsp), но продолжают находиться все в том же сегменте.

  • #17010

    uxTuaHgp
    Участник

    Не не не.
    Я вот о чем: если часть сегмента 256МБ, допустим, 64МБ были выгружена на диск, а потом по требованию были загружены обратно в память, то эти 64МБ будут находиться и в памяти и на диске до тех пор, пока эти страницы в памяти не будут изменены или до тех по пока не возникнет дефицит Paging space.
    То что запинено – это совсем отдельная тема, оно просто никогда не попадет на диск.

    Еще непонятный для меня пока момент:
    У меня не сходятся цифры из svmon -G
    и
    сумма сегментов из svmon -S
    Например:

    [code]
    # svmon -G -O unit=GB
    Unit: GB
    ————————————————————————————–
    size inuse free pin virtual available mmode
    memory 345.00 339.75 5.25 54.0 326.96 10.7 Ded
    pg space 108.00 65.4

    work pers clnt other
    pin 43.9 0 0.01 10.1
    in use 323.48 0 16.3

    # svmon -S -O unit=GB |awk
    ‘BEGIN {CSZ=0; WSZ=0; KSZ=0}
    /clnt/ {S=NF-3; CSZ+=$S}
    > ‘BEGIN {CSZ=0; WSZ=0; KSZ=0}
    /clnt/ {S=NF-3; CSZ+=$S}
    /kernel heap/ {S=NF-3; KSZ+=$S}
    /work/ {S=NF-3; WSZ+=$S}
    END { print “File cache size: “CSZ;
    print “Kernel Heap size: “KSZ;
    print “Total Heap size: “WSZ;
    print “Total Memory Usage: “WSZ+CSZ}’
    > /clnt/ {S=NF-3; CSZ+=$S}
    > /kernel heap/ {S=NF-3; KSZ+=$S}
    > /work/ {S=NF-3; WSZ+=$S}
    > END { print “File cache size: “CSZ;
    > print “Kernel Heap size: “KSZ;
    > print “Total Heap size: “WSZ;
    > print “Total Memory Usage: “WSZ+CSZ}’
    File cache size: 15.77
    Kernel Heap size: 39.7
    Total Heap size: 304.88
    Total Memory Usage: 320.65

    [/code]

    Где-то потерялось ~20ГБ.
    Что я делаю не так?

  • #17011

    Alex
    Участник

    Первое, что приходит на ум: unit=GB наверняка округляет до нуля всё, что меньше 256Мб (не могу представить себе 0.012345 в выводе svmon .-) ). Если уж не хочется считать в страницах, – по меньшей мере надо делать unit=KB. Не гарантирую, что сойдётся, но разница между -G и -O точно уменьшится.

  • #17012

    uxTuaHgp
    Участник

    Хорошо, Unit=KB
    [code]
    # svmon -G -O unit=KB
    Unit: KB
    ————————————————————————————–
    size inuse free pin virtual available mmode
    memory 361758720 358489996 3268724 56668360 344799796 9279784 Ded
    pg space 113246208 68606364

    work pers clnt other
    pin 46038532 0 11204 10618624
    in use 341159260 76 17330660

    # svmon -S -O unit=KB |awk
    ‘BEGIN {CSZ=0; WSZ=0; KSZ=0}
    /clnt/ {S=NF-3; CSZ+=$S}
    > ‘BEGIN {CSZ=0; WSZ=0; KSZ=0}
    /clnt/ {S=NF-3; CSZ+=$S}
    /kernel heap/ {S=NF-3; KSZ+=$S}
    /work/ {S=NF-3; WSZ+=$S}
    END { print “File cache size: “CSZ;
    print “Kernel Heap size: “KSZ;
    > /clnt/ {S=NF-3; CSZ+=$S}
    > /kernel heap/ {S=NF-3; KSZ+=$S}
    > /work/ {S=NF-3; WSZ+=$S}
    > END { print “File cache size: “CSZ;
    > print “Kernel Heap size: “KSZ;
    > print “Total Heap size: “WSZ;
    > print “Total Memory Usage: “WSZ+CSZ}’
    File cache size: 17332920
    Kernel Heap size: 41725400
    Total Heap size: 330731248
    Total Memory Usage: 348064168
    [/code]
    Согласен, погрешность меньше, но все равно ~10ГБ куда-то улетели.
    Что-то я не учел или у svmon дебет с кредитом не сводится?
    Кстати, минимальный квант – страница 4КБ, правильно?

  • #17013

    andrewk
    Участник

    # svmon -S -O unit=KB | awk ‘{print $3}’ | sort -u

    Type
    clnt
    mmap
    rmap
    work

  • #17015

    uxTuaHgp
    Участник

    pers – жалкие крохи

    mmap и rmap – вообще нули

  • #17016

    Alex
    Участник

    Поизучал сейчас вывод svmon – это его баг.

    Раскадровка:

    svmon -S считает размер правильно, если в выделенном сегменте присутствуют страницы только одного типа. На более-менее нагруженных же системах обязательно будут смешанные сегменты типа sm. Те, кто писал svmon изначально, этого явно не ожидали, даже по параметрам видно. Можно фильтровать, например, по типу сегмента, но только по какому-то одному (s/m/L/S), смешанный тип (sm) не предусмотрен.

    В случае sm сегментов svmon для вычисления размера просто берёт число выделенных страниц и умножает на 4K. Пример:

    [code]bash-3.2# svmon -S 182cf00

    Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
    182cf00 – work sm 2220 0 0 2220

    bash-3.2# svmon -S 182cf00 -O unit=KB
    Unit: KB

    Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
    182cf00 – work sm 8880 0 0 8880
    [/code]
    2220 страниц _разного_ размера при указании unit-а превращаются в 8880Кб (2220*4). Смотрим реальный размер.

    [code]bash-3.2# svmon -D 182cf00 -O filterpgsz=s | grep ” s ” | wc -l
    988
    bash-3.2# svmon -D 182cf00 -O filterpgsz=m | grep ” m ” | wc -l
    1232
    [/code]
    Что в сумме даёт нам 988*4+1232*64=80Мб. Против 8.7Мб, выдаваемых svmon с ключом -S.

    У меня нет семёрки – возможно, там уже поправили?

    Никто не хочет открыть PMR для шестёрки, попрактиковать терпение и выдержку в беседах с очередным Кумаром? 😉

  • #17021

    uxTuaHgp
    Участник

    Мой случай не подходит под такое описание.
    У меня только 4К страницы vmm_mpsize_support=0, так что никакого sm.

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

    PMR по перфомансу открыт, в рамках которого я озадачиваю поддержку и вопросом об svmon

  • #17022

    Alex
    Участник

    Гм, действительно, наворотили там.

    Сравнил сейчас значения – такое чувство, что не показывается какая-то часть запиненой памяти (какие-то очень системные вещи?). Потому что по PgSp, например, вывод -S у меня совпадает с global report. А общее количество памяти, считаемое через суммирование всех сегментов отличается от global report на величину недостающей pin memory.

  • #17025

    uxTuaHgp
    Участник

    Поддержка ответила по поводу разницы в отчетах:

    mem_wo_vmm_segids_hex=`echo “dd wlm_hw_pages 1” | kdb | grep wlm_hw_pages+ | awk ‘{print $2}’`
    mem_wo_vmm_segids_dec=`echo “ibase=16;$mem_wo_vmm_segids_hex” | bc`
    echo “Total kernel mem w/ no segment id (wlm_hw_pages)” $mem_wo_vmm_segids_dec
    above commands will give the page count in 4k size.
    So we are getting the value from kernel using kernel debugger command that is kdb.

    В общем svmon -S дает расклад по именованным сегментам, но в системе есть сегменты без идентификаторов, которые можно увидеть только с помощью дебагера.

  • #17040

    andrewk
    Участник

    адресовал вопрос напрямую в Austin. На следующей неделе, надеюсь, пришлют какой-нибудь ответ…

  • #17044

    Alex
    Участник

    но в системе есть сегменты без идентификаторов, которые можно увидеть только с помощью дебагера.

    Занятно.
    Но моего бага с sm это не снимает! .-)

  • #17049

    uxTuaHgp
    Участник

    какое забавное развитие темы 🙂

Для ответа в этой теме необходимо авторизоваться.