Управление процессами

Замечание об управлении ресурсами

В этой лекции рассматриваются базовые сведения, связанные с управлением процессами. Многое из содержания этой лекции применимо и к другим системам UNIX, отличным от Solaris. Более глубокие знания об управлении ресурсами именно в Solaris, в частности, об управлении проектами, пулами ресурсов, зонами и контейнерами, можно получить из лекции 6 курса "Системное администрирование ОС Solaris 10". Если вы применяете Solaris на сервере, где много свободных ресурсов, или на обычной рабочей станции, где лишь набираете тексты и строите графики, то применять знания, полученные из настоящей лекции, вы будете, может быть, время от времени, а вот материал из лекции 6 курса "Системное администрирование ОС Solaris 10" скорее пригодится вашим коллегам, имеющим дело с ресурсоемкими задачами большего масштаба.

Замечание о совместимости утилит

Несмотря на то, что Solaris удовлетворяет многочисленным стандартам, некоторые программы в системе (точнее, их возможности и ключи) расходятся со стандартом XPG4. Этот стандарт (The X/Open Portability Guide, Issue 4 – XPG4) представляет собой спецификацию, описывающую программы, заголовки и интерфейсы. В частности, описывается ожидаемое поведения ряда программ UNIX и их ключи.

Что находится в каталоге /usr/bin/xpg4

В тех случаях, когда поведение и ключи программ Solaris расходились со спецификацией XPG4, изначальная версия программы под Solaris не изменялась, вместо этого программа, совместимая с XPG4, с примерно такими же функциональными особенностями и совершенно таким же именем, помещалась в каталог /usr/bin/xpg4. Таким образом, для того, чтобы выбрать, какие программы – оригинальные или XPG4-совместимые вы предпочитаете использовать в своей системе, – достаточно указать первым в переменной среды окружения PATH тот каталог, в котором лежат нужные вам "по умолчанию" программы. Если первым указан каталог /usr/bin, то при вызове команды по ее короткому имени (например, grep ), а не по полному имени файла (например, /usr/bin/xpg4/grep ), будет вызываться /usr/bin/grep – оригинальная программа. Если указать в PATH первым /usr/bin/xpg4, то будет запускаться XPG4-совместимая версия. Помните, что оригинальные программы могут располагаться также в /bin, /usr/ucb and /usr/ccs/bin.

Спецификация XPG4 включает в себя спецификации программ из IEEE Std 1003.2-1992 и IEEE Std 1003.2a-1992 (которые вместе носят название POSIX 2).

Общие сведения о многопоточности

Единицей исполнения в любой операционной системе является процесс. Процесс – это совокупность исполняемого кода, данных, связанных с этим кодом, и информации, необходимой для исполнения этого кода операционной системой. Существуют операционные системы, в которых после запуска одного процесса другой не может быть запущен до тех пор, пока не завершится первый. Такие ОС называются однозадачными и встречаются в современном мире редко. Большинство ОС – многозадачные, т.е. способны обеспечить одновременное исполнение нескольких процессов (как правило, нескольких десятков тысяч).

В многозадачной системе всегда есть планировщик задач – часть ядра ОС, которая передает управление от одного процесса другому в соответствии с алгоритмом переключения. Для определения процесса, которому надо передать управление, используется формула, куда входит приоритет процесса – параметр, который придается любому процессу в системе.

Каждый процесс в большинстве ОС (в частности, Solaris, Linux, других системах UNIX и в современных версиях ОС Windows) исполняется в своем собственном адресном пространстве. Процесс не может обратиться к адресному пространству другого процесса, за исключением специального случая использования разделяемой памяти – механизма межпроцессного взаимодействия, который обеспечивается в некоторых ОС. Это сделано для того, чтобы сбои в работе одного процесса не могли повлиять на остальные процессы в системе. Процессы в многозадачной многопользовательской системе могут принадлежать разным пользователям и выполняются независимо друг от друга.

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

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

Современные средства разработки предоставляют несколько механизмов синхронизации, например, исключения (mutex), блокировки, семафоры. В Solaris для многопоточного программирования можно использовать библиотеку POSIX threads (libpthreads) или разработанную ранее компанией Sun библиотеку libthreads (она сохраняется в Solaris для совместимости с предыдущими версиями).

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

В компьютерах с несколькими процессорами (а также с многоядерными процессорами, некоторые из которых обрабатывают несколько потоков команд одновременно, например, UltraSPARC T2 от Sun – 64 потока) многопоточность позволяет исполнять разные потоки на разных процессорах, что во многих случаях дает значительный прирост производительности.

Реализация многопоточности в Solaris

Задача обеспечения многопоточности сводится к созданию оптимального алгоритма управления потоками. С точки зрения ядра Solaris, поток – это единица диспетчеризации, т.е. именно потоки конкурируют между собой за доступ к ресурсам (прежде всего, к процессору).

Диспетчер (также его иногда называют планировщиком) – это часть ядра, ответственная за переключение между потоками, которое выполняется в соответствии с приоритетами потоков. В Solaris наряду с процессом и потоком вводятся понятия потока пользователя (user thread), потока ядра (kernel thread) и легковесного процесса (LWP, lightweight process). Поток ядра в Solaris – это как раз и есть единица диспетчеризации. Поток ядра описывается в ядре небольшой по размеру структурой ("структурой" в понимании языка С, т.е. набором переменных). Поток ядра может быть связан с легковесным процессом, который, в свою очередь, всегда связан с одним потоком пользователя. Кроме этого, поток ядра может быть инициирован самим ядром, и тогда с ним не связан никакой легковесный процесс. Рисунок 9.1 показывает соотношение потока пользователя, потока ядра и легковесного процесса. На рисунке также указано, как называются структуры, описывающие процесс, поток пользователя, легковесный процесс и поток ядра соответственно.

Такая организация многопоточности введена в Solaris начиная с версии Solaris 10, потому что на современном оборудовании она более выигрышна, чем использованная в предыдущих версиях Solaris. Ранее к одному легковесному процессу могло привязываться несколько потоков пользователя (рис 9.2), что усложняло управление процессами на уровне библиотеки потоков libthreads и требовало отдельного планировщика потоков пользователя на уровне процесса. Эта схема была эффективной в течение многих лет, так как затраты процессорного времени на создание нового потока ядра были достаточно высоки. С ростом мощности процессоров, появлением многоядерных процессоров, удешевлением компонент в целом оптимизация управления потоками стала более важной, чем экономия на создании новых потоков ядра.

Иерархия процессов в Solaris

Процессы делятся на ядро и все остальные процессы. Последние называются пользовательскими процессами. Пользовательский процесс не обязательно запущен неким пользователем, то, что он – "пользовательский", означает исключительно то, что он не является ядром.

Само ядро Solaris представляет собой множество потоков (threads), которые выполняются параллельно. Действительно, у ядра много разных дел, было бы странно, если бы ядро пыталось все делать последовательно, а не параллельно. Термин threads часто переводят как "нить", но мы будем говорить в контексте управления процессами именно о "потоках", понимая под этим "потоки команд", в отличие от "потоков данных", которые будем обсуждать ниже.

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

Solaris реализует многоуровневую поточную модель. Ее назначение – разделить управление потоками пользовательского уровня и работу ядра. Потоки пользовательского уровня имеют свою схему приоритетов. Их планирование проводится с помощью потока-планировщика. Такой поток создается библиотекой потоков, когда многопоточное приложение компилируется и выполняется. Внутри одного пользовательского процесса могут работать свои потоки, передача управления между которыми осуществляется внутренним планировщиком этого процесса. Благодаря этому многопоточные приложения могут порождать тысячи потоков без существенной загрузки ядра. Оно будет видеть это приложение как один процесс. По сути, ядро не видит пользовательские потоки, пока они не присоединяются к легковесному процессу (lightweight process, LWP), имеющему определенное положение в операционной системе. Поток-планировщик отвечает за отображение пользовательских потоков в легковесный процесс (LWP), который связан с потоком ядра для выполнения процессором. Каждый LWP имеет поток ядра, но необязательно каждый поток ядра имеет LWP. Часть потоков ядра задействованы исключительно операционной системой, поэтому LWP здесь не требуется.

Свойства процесса

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

Идентификаторы процесса

Процесс всегда имеет свой уникальный номер – PID (process ID). PID – это целое число в диапазоне допустимых целых чисел (для 32-х-разрядных систем – от 0 до 65535). Процесс номер 0 – это, обычно, процесс свопинга, фактически являющийся частью кода ядра. Процесс с номером 1 – это всегда init, процесс, который порождает все остальные процессы в системе при ее старте. У всех процессов, кроме init, есть родительский процесс, и каждому процессу, кроме его собственного идентификатора PID, соответствует идентификатор родительского процесса (PPID – parent process ID).

В таблице процессов, кроме идентификаторов PID и PPID, хранятся eUID (effective UID – эффективный идентификатор пользователя) владельца процесса и eGID (effective GID – эффективный идентификатор группы) группы процесса. Фактические (реальные) владелец и группа процесса – это пользователь и группа, которые запустили процесс, а эффективные владелец и группа процесса – это те, от имени которых запущен процесс. Для определения прав доступа используются эффективные идентификаторы, а для задач управления процессом (например, посылки сигнала процессам, которые запустил определенный пользователь, см. описание команды pkill ниже) – реальные. Эти идентификаторы передаются по наследству от родительского процесса к дочернему.

Передача этих идентификаторов для пользовательских процессов организована следующим образом. При входе пользователя в систему для него запускается командный процессор, этот запуск программа login обеспечивает от имени входящего пользователя. Группой процесса этого командного процессора назначается главная группа пользователя, вошедшего в систему.

Любой процесс относится к какой-либо терминальной группе, т.е. группе процессов, запущеных с одного терминала. Терминал определяется параметром TTYID.

Процесс имеет базовый и динамический приоритеты, в зависимости от приоритета запросы процесса к системе выполняются медленнее или быстрее.

Посмотреть полный список процессов в системе с выводом их идентификаторов и ряда других параметров можно командой ps –ef.

Приоритеты процесса

Во многих системах UNIX процесс имеет базовый приоритет (NICE) и динамический приоритет (PRI). Базовый приоритет может принимать значение от -20 до +20. Чем меньше числовое значение базового приоритета NICE, тем выше приоритет. Процесс с отрицательным приоритетом -20 – самый высокоприоритетный. Динамический приоритет вычисляется планировщиком задач на основе базового приоритета по формуле, в которую входит общее потребленное процессом процессорное время. Чтобы дать возможность выполняться новым и более коротким процессам, динамический приоритет снижается с увеличением потребленного процессом времени процессора.

В Solaris существует более сложная схема планирования приоритетов процессов, которая приведена ниже. Для процессов одного из классов планирования (с разделением времени) справедлива вышеописанная простая схема из базового и динамического приоритетов.

Каждый процесс может быть представлен одним или несколькими потоками ядра. С точки зрения ядра, объектом назначения того или иного приоритета является поток ядра. Если процесс сопоставлен только одному потоку ядра, то приоритет процесса и приоритет этого потока ядра – это одно и то же.

Приоритет базируется на классе планирования (scheduling class), Существует всего четыре таких класса: с разделением времени (timesharing), системный (system), реального времени (real-time) и планирования на основе справедливого раздела (fair class scheduling – FSS). У процессов разных классов планирования свои уровни приоритета и свои очереди на выполнение. Стало быть, в системе мы имеем четыре очереди к процессору. Внутри каждого класса процессы, стоящие в очереди, имеют свои уровни приоритета. Эти уровни отображаются в глобальные приоритеты планирования (global scheduling priorities). Первым процессор займет процесс, который имеет наивысший глобальный приоритет. По умолчанию процесс из класса планирования с разделением времени имеет более низкий глобальный приоритет, чем процесс из системного класса, а тот, в свою очередь, более низкий, чем процесс реального времени.

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

Получить информацию о текущих классах планирования процессов можно с помощью команды dispadmin.

Среда окружения

Каждый процесс имеет свою среду окружения – специальную область, в которой хранятся имена переменных и их значения. Среда окружения используется для модификации поведения процесса; так, в зависимости от значения переменной TERM текстовый редактор будет выдавать разные коды управления экраном, поскольку переменная TERM применяется для задания типа терминала. Переменные среды окружения могут быть помечены как экспортируемые: это означает, что такую переменную дочерний процесс унаследует от процесса-родителя. Такие переменные, как TERM, PATH, USER, обычно являются экспортируемыми. Из командной строки пометить переменную как экспортируемую можно с помощью команды export:

export TERM PATH

К переменным среды окружения легко обратиться из прикладной программы – для этого предусмутрен специальный массив строк

char *env[]

Аргументы

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

char *argv[]

Число аргументов обязательно передается в каждый процесс в переменной

int argc

Классы планирования

В Solaris есть шесть классов планирования: с разделением времени (timesharing, TS), интерактивный (interactive, IA), системный (system, SYS), реального времени (real-time, RT), с фиксированным приоритетом (fixed priority, FX) и планирования на основе долевого распределения (fair share scheduling, FSS).

По умолчанию процессы попадают в класс с разделением времени.

С помощью команды

ps –cl

можно узнать глобальные приоритеты запущенных в данный момент процессов, а "внутренние" приоритеты процессов в разных классах планирования – с помощью команды dispadmin.

Планирование процессов реального времени

Планирование в реальном времени относится к средствам, с помощью которых процессу по мере необходимости обеспечивается квант процессора. Такая схема характерна для некоторых типов приложений, например, в робототехнике или управлении полетом.

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

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

В нестрогой среде реального времени период реакции должен иметь гарантированную конечную продолжительность (например, верхний предел времени, за которое приложение должно освободить процессор; в Solaris такой период составляет 5 миллисекунд).

В большинстве систем UNIX поддержки реального времени нет. Это связано с тем, что:

Решение первой из этих проблем в Solaris состоит в том, что все страницы процесса реального времени в памяти блокируются и их выгрузка на диск запрещается. Решение второй проблемы таково: ядро Solaris многопотоковое, обработчики прерываний реализованы как отдельные потоки, что делает возможным установить для них отдельный приоритет; более того, в Solaris есть priority lending – "одалживание приоритета": когда более приоритетный процесс нуждается в результатах работы менее приоритетного процесса, он может "одолжить" последнему на время свой высокий приоритет для выполнения требуемой задачи.

Диспетчер

Когда поток готов к выполнению, он помещается в очередь отправки на выполнение. Каждый процессор (в многопроцессорной системе) имеет отдельный набор очередей отправки. Состояние ожидания в очереди отправки называется состоянием выполнения (RUN). Когда процессор освобождается, диспетчер берет поток с наивысшим приоритетом из очереди отправки этого процессора и помещает его в процессор. Теперь поток в состоянии "внутри процессора" (ONPROC) и может выполнять вычисления.

Поток может лишиться процессорного времени в данный момент и покинуть процессор по нескольким причинам:

Проверка приоритета процесса

Выяснить, с каким легковесным процессом ассоциирован конкретный процесс, и какой класс планирования ему назначен, можно с помощью команды ps и ключей –L и –с:

/usr/bin/ps –efcL

UID   PID  PPID LWP NLWP CLS  PRI  STIME     TTY   LTIME   CMD
root  0    0    1   1    SYS  96   00:23:03  ?     0:03    sched
root  1    0    1   1    TS   59   00:23:03  ?     0:00    /etc/init -
root  2    0    1   1    SYS  98   00:23:03  ?     0:00    pageout
root  3    0    1   1    SYS  60   00:23:03  ?     0:00    fsflush
root  314  1    1   1    TS   59   00:23:35  ?     0:00    /usr/lib/saf/sac -t 300
root  289  1    1   1    TS   59   00:23:32  ?     0:00    /usr/lib/snmp/snmpdx -y -c
                                                           /etc/snmp/conf
root  182  1    1   3    TS   59   00:23:22  ?     0:00    /usr/lib/autofs/automountd
root  182  1    2   3    TS   59   00:23:23  ?     0:00    /usr/lib/autofs/automountd
root  182  1    3   3    TS   59   00:25:23  ?     0:00    /usr/lib/autofs/automountd
root  207  1    3   18   TS   59   00:23:25  ?     0:00    /usr/sbin/nscd
root  207  1    4   18   TS   59   00:23:25  ?     0:00    /usr/sbin/nscd
root  207  1    5   18   TS   59   00:23:25  ?     0:00    /usr/sbin/nscd
root  207  1    6   18   TS   59   00:23:25  ?     0:00    /usr/sbin/nscd
root  207  1    7   18   TS   59   00:23:25  ?     0:00    /usr/sbin/nscd
root  207  1    8   18   TS   59   00:23:25  ?     0:00    /usr/sbin/nscd
root  207  1    9   18   TS   59   00:23:25  ?     0:00    /usr/sbin/nscd
root  193  1    11  13   TS   59   00:23:24  ?     0:00    /usr/sbin/syslogd
root  193  1    12  13   TS   59   00:23:24  ?     0:00    /usr/sbin/syslogd
root  193  1    13  13   TS   59   00:23:26  ?     0:00    /usr/sbin/syslogd
root  439  419  1   1    IA   39   00:24:42  pts/4 0:00    bash

Вывод этой команды сильно сокращен: процессов в системе на самом деле всегда значительно больше. Сейчас нам интересны прежде всего колонки LWP, CLS и PRI, в которых показаны номер легковесного процесса, класс планирования и глобальный приоритет соответственно.

Чем больше числовое значение глобального приоритета (значение PRI), тем выше глобальный приоритет процесса.

Мы видим, что многопоточные процессы (например, демон автомонтирования /usr/lib/autofs/automountd и демон протоколирования /usr/sbin/syslogd) могут одновременно иметь несколько LWP (в колонке NLWP указано количество LWP, с которыми ассоциирован процесс).

Настройка таблиц диспетчера

Таблицы диспетчера настраиваются с помощью команды dispadmin. Настройка выполняется следующим образом: вначале таблица диспетчера конкретного класса выводится в файл, затем файл редактируется в текстовом редакторе и загружается обратно в таблицу диспетчера. Вывод и загрузка таблицы осуществляется с помощью программы dispadmin.

Чтобы узнать, какие классы доступны для редактирования, следует запустить dispadmin с ключом –l и определить активные классы планирования:

dispadmin -l
CONFIGURED CLASSES ==================
SYS (System Class)
TS  (Time Sharing)
FX  (Fixed Priority)
IA  (Interactive)
RT  (Real Time)

Далее выводим таблицу диспетчера для выбранного класса (попробуем это на классе планирования с разделением времени – TS ):

dispadmin -c TS -g

# Time Sharing Dispatcher Configuration
RES=1000

ts_quantum  ts_tqexp  ts_slpret  ts_maxwait  ts_lwait      PRIORITY LEVEL
200         0         50         0           50        #   0
200         0         50         0           50        #   1
200         0         50         0           50        #   2
200         0         50         0           50        #   3
200         0         50         0           50        #   4
200         0         50         0           50        #   5
200         0         50         0           50        #   6
200         0         50         0           50        #   7
200         0         50         0           50        #   8
200         0         50         0           50        #   9
160         0         51         0           51        #   10
160         1         51         0           51        #   11
160         2         51         0           51        #   12
160         3         51         0           51        #   13
160         4         51         0           51        #   14
160         5         51         0           51        #   15
160         6         51         0           51        #   16
160         7         51         0           51        #   17
160         8         51         0           51        #   18
160         9         51         0           51        #   19
120         10        52         0           52        #   20
120         11        52         0           52        #   21
120         12        52         0           52        #   22
120         13        52         0           52        #   23
120         14        52         0           52        #   24
120         15        52         0           52        #   25
120         16        52         0           52        #   26
120         17        52         0           52        #   27
120         18        52         0           52        #   28
120         19        52         0           52        #   29
80          20        53         0           53        #   30
80          21        53         0           53        #   31
80          22        53         0           53        #   32
80          23        53         0           53        #   33
80          24        53         0           53        #   34
80          25        54         0           54        #   35
80          26        54         0           54        #   36
80          27        54         0           54        #   37
80          28        54         0           54        #   38
80          29        54         0           54        #   39
40          30        55         0           55        #   40
40          31        55         0           55        #   41
40          32        55         0           55        #   42
40          33        55         0           55        #   43
40          34        55         0           55        #   44
40          35        56         0           56        #   45
40          36        57         0           57        #   46
40          37        58         0           58        #   47
40          38        58         0           58        #   48
40          39        58         0           59        #   49
40          40        58         0           59        #   50
40          41        58         0           59        #   51
40          42        58         0           59        #   52
40          43        58         0           59        #   53
40          44        58         0           59        #   54
40          45        58         0           59        #   55
40          46        58         0           59        #   56
40          47        58         0           59        #   57
40          48        58         0           59        #   58
20          49        59         32000       59        #   59

Первая строка, в которой указано значение RES, определяет, в чем измеряется время во всей таблице приоритетов данного класса. Величина RES фактически задает дискретность измерения времени для столбца ts_quantum таблицы диспетчера. Ее значение по умолчанию 1000. Изменять дискретность не рекомендуется. Обратная к RES величина равна 0,001, и это интерпретируется как одна тысячная секунды, т.е. одна миллисекунда. Стало быть, по умолчанию время в столбце ts_quantum измеряется в миллисекундах.

Как было показано в разделе "Диспетчер" выше, смысл значений в столбцах таблицы диспетчера следующий:

В таблицах диспетчера указываются относительные приоритеты (которые имеют силу внутри класса планирования). Глобальный (иначе говоря – абсолютный) приоритет вычисляется из относительного в соответствии с табл. 9.1.

Обратите внимание на то, что более высокоприоритетные процессы имеют меньшие кванты времени. Значение maxwait для самого выского приоритета, 59, настолько высоко, что ему придется ждать дольше других, если он лишится процессорного времени в пользу ядра (ядро имеет более высокий проритет, чем любой процесс разделения времени).

Посмотрим, как работает эта схема динамического назначения приоритетов. Предположим, процесс начал выполняться с приоритетом 0. Подождав, пока ему дадут управление в течение одной секунды ( ts_maxwait ), процесс получил новый приоритет 50 ( ts_lwait ).

Вместе с новым приоритетом процесс обрел новое значение кванта (меньшее, так как чем выше приоритет, тем меньше квант, для того, чтобы высокоприоритетные задачи не забивали процессор). Вместо прежних 200 миллисекунд процесс получил квант в 40 миллисекунд. Зато с этим приоритетом процесс получил возможность вытеснять из процессора менее приоритетные процессы.

Если процесс продолжает все время использовать процессорное время, не отвлекаясь на ввод-вывод (например, это вычислительный процесс программы моделирования полета ракеты), то по истечении кванта времени он получит новый приоритет 40 ( ts_tqexp ).

Дальнейшие назначения приоритетов показаны ниже:

Такая схема динамического назначения приоритетов позволяет быстро выполниться коротким высокоприоритетным процессам и дает возможность работать низкоприоритетным процессам. В то же время, процессы, постоянно потребляющие процессорное время, перемещаются к более низким приоритетам, получают большие кванты времени и будут больше времени проводить с низким приоритетом. Если же низкоприоритетный поток будет постоянно прерываться более высокоприоритетными, то его приоритет будет быстро повышен – как только пойдет ts_maxwait секунд. Фактически, это означает, что в сильно загруженной высокоприоритетными потоками системе низкоприоритетный поток через секунду будет становиться высокоприоритетным.

Класс реального времени (RT) описывается более простой таблицей диспетчера:

# Real Time Dispatcher Configuration RES=1000

TIME QUANTUM(rt_quantum)                 PRIORITY LEVEL
1000                               #     0
1000                               #     1
1000                               #     2
1000                               #     3
1000                               #     4
1000                               #     5
1000                               #     6
1000                               #     7
1000                               #     8
1000                               #     9
800                                #     10
800                                #     11
800                                #     12
800                                #     13
800                                #     14
800                                #     15
800                                #     16
800                                #     17
800                                #     18
800                                #     19
600                                #     20
600                                #     21
600                                #     22
600                                #     23
600                                #     24
600                                #     25
600                                #     26
600                                #     27
600                                #     28
600                                #     29
400                                #     30
400                                #     31
400                                #     32
400                                #     33
400                                #     34
400                                #     35
400                                #     36
400                                #     37
400                                #     38
400                                #     39
200                                #     40
200                                #     41
200                                #     42
200                                #     43
200                                #     44
200                                #     45
200                                #     46
200                                #     47
200                                #     48
200                                #     49
100                                #     50
100                                #     51
100                                #     52
100                                #     53
100                                #     54
100                                #     55
100                                #     56
100                                #     57
100                                #     58
100                                #     59

Потоки реального времени выполняются до завершения или до истечения их кванта (если в очереди стоят несколько потоков реального времени). Потокам реального времени присваивается самый высокий абсолютный приоритет, даже более высокий, чем потокам ядра, потому что относительные приоритеты отображаются в абсолютные, как показано в табл. 9.1.

Планирование на основе долевого распределения

В Solaris стандартный планировщик задач (диспетчер) старается предоставить процессам, которые по умолчанию запускаются с классом планирования timesharing (в режиме с разделением времени) примерно одинаковый доступ к процессору. Однако, если на самом деле некоторые процессы в системе более важны, чем другие (сервер баз данных, веб-сервер крупного портала и т.п.), можно использовать другой метод планирования, а именно долевое распределение (fair share scheduler – FSS). В этом случае можно будет назначить группам процессов разные "порции" процессорного времени, которые те будут получать в единицу времени. Грубо говоря, можно потребовать от планировщика отдать 70% времени веб-серверу, а 30% – всем остальным процессам. Если этого не сделать, время будет делиться поровну. Кроме соответствующего алгоритма, в Solaris начиная с версии Solaris 9 появился новый класс планирования, который тоже называется планированием на основе долевого распределения.

В более ранних версиях Solaris этот алгоритм планирования (и соответствующий ему класс) отсутствовал, хотя в других системах аналогичный алгоритм был реализован в середине девяностых годов, например, в IRIX 6.2.

Более детальное описание этой возможности дано по адресу http://docs.sun.com/db/doc/816-4882/6mb2ipq5n?q=scheduling+classa=view

В лекции 5 курса "Системное администрирование ОС Solaris 10" показано, как использовать планирование на основе долевого распределения для управления ресурсами системы.

Распределение памяти. Swaping

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

В UNIX вся память разделена на страницы определенного одинакового размера. Каждый процесс получает от системы запрошенное количество памяти, выделение памяти в UNIX осуществляется постранично. Процессы реального времени и часть кода ядра (например, та, что отвечает за обмен страницами между оперативной памятью и диском) всегда находятся в памяти, страницы остальных процессов могут быть выгружены на диск. В большинстве систем UNIX размер страницы составляет 4 Кб. В Solaris для x86 он ровно такой же, но на платформе SPARC может быть другой размер страницы, т.к. это свойство системы зависит от платформы. Узнать размер страницы памяти в Solaris можно по команде pagesize.

Традиционно в литературе по системам UNIX для описания процесса обмена страницами между памятью и диском используетcя термин "свопинг" (swaping). Этот термин в действительности означает полную выгрузку страниц процесса на диск. На самом деле менеджер виртуальной памяти в UNIX обычно выполняет "пейджинг" (paging), что означает постраничную (частичную) выгрузку процесса на диск. Свопинг выполняется в том случае, если памяти критически не хватает, что при нормальной работе системы не наблюдается.

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

Более подробно алгоритм работы менеджера виртуальной памяти рассмотрен в лекции 8 курса "Системное администрирование ОС Solaris 10".

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

При планировании дисковой подсистемы (в частности, размера swap-разделов) важно хорошо представлять, как много памяти нужно тем программам, которые будут одновременно работать в системе. В самом деле, если в системе планируется одновременно запускать сервер баз данных, веб-сервер и несколько почтовых служб, можно предположить, что памяти потребуется много. Вполне реально оценить потребности в ней эмпирически – запустите по одной копии каждого демона, умножьте объем памяти, занятой каждым из них, на число предполагаемых демонов такого типа в рабочей системе и умножьте сумму получившихся чисел еще на два – для получения разумного запаса. Если такое количество оперативной памяти физически возможно установить в компьютер, нам светит счастливая звезда! Если нет, надо прикинуть, какой объем памяти критически важен (программы должны работать одновременно, а не лежать в swap-разделе по-очереди или, не дай Бог, все вместе!), и решить, сколько при этом останется программ, которым все-таки придется отдохнуть на диске.

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

Доступ процессов к файлам

В ходе работы процессы обращаются к внешним устройствам, файлам и каталогам. При обращении к внешнему устройству права доступа к нему определяются правами доступа к соответсвующему файлу устройства. Права доступа к файлу и каталогу определяются одинаково, исходя из фактических прав доступа, определенных в файловой системе, включая расширенные права доступа (ACL).

То, какие права доступа к файлу получит процесс, зависит от эффективных идентификатора владельца (eUID) и группы (eGID) этого процесса. При обращении процесса к файлу ядро проверяет, кем по отношению к этому файлу является владелец процесса. Если эффективный идентификатор владельца процесса совпадает с идентификатором владельца файла, то процесс получает права доступа к файлу, определенные для владельца файла. Если владелец процесса входит в группу файла, но не является владельцем файла, он получает права, определенные для группы файла. Если ни то, ни другое не соблюдено, процесс получает права доступа к файлу, определенные для "всех остальных".

Новый файл по умолчанию получает идентификаторы владельца и группы по наследству от процесса, который его создал, а права доступа к нему – по умолчанию – исходя из маски прав доступа umask.

Эффективный идентификатор группы процесса не играет роли в вычислении фактических прав доступа к файлу. Он используется исключительно для того, чтобы назначить его (по наследству) новому файлу, который будет создан процессом.

Запуск приложения от имени владельца файла приложения

Идентификаторы владельца и группы процесса называются эффективными из-за того, что они не всегда передается по наследству. На деле они вычисляются, исходя из специального права доступа, о котором сейчас пойдет речь. Поэтому результат этих вычислений решили назвать "эффективным", т.е. тем, что действительно оказывает воздействие на права процесса. Дело в том, что иногда нужно запустить процесс от имени другого пользователя. Конечно, это не для того, чтобы начинающий программист мог послать веселую картинку начальнику от имени Вашего секретаря.

Обычно эффективные идентификаторы владельца и группы процесса достаются процессу по наследству от процесса-родителя. Но в некоторых ситуациях необходимо запустить программу с правами, большими, нежели права запускающего ее пользователя. Например, вам надо изменить свой пароль. Для этого требуется осуществить запись в файл /etc/shadow. С другой стороны, нельзя давать каждому пользователю такое право: вдруг он поменяет не только свой пароль? Кто откажется сделать милый сюрприз коллеге? Как быть? Если вы подумали, что выход в том, чтобы все пароли менял только администратор, вы далеки от истины.

Идея в том, чтобы право записи в /etc/shadow дать не конкретному пользователю, а программе passwd (как нам известно, пароль меняет именно эта программа). К сожалению, в UNIX нет механизма, который позволяет давать какие-либо права отдельному процессу или приложению. Поэтому право записи в /etc/shadow дали пользователю root (назначив его владельцем этого файла и разрешив запись в файл владельцу – вы помните, как это сделать с помощью chmod?), а программу passwd разрешили всем запускать от имени ее владельца – root.

Это право (запускать программу от имени владельца) является специальным правом доступа к файлу, оно называется SUID (от set User ID). Фактически, файл с установленным битом SUID,отвечающим за это правом доступа, всегда запускается на выполнение с эффективным идентификатором владельца процесса, равным идентификатору владельца файла.

Как мы помним, полный вид слова прав доступа таков:

Старшие три бита –SUID (su), SGID (sg) и sticky bit (t).

Suid и Sgid

Установить бит suid или sgid можно, указав chmod права доступа в числовом виде:

chmod 4755 файл

или мнемоническом виде:

chmod u+s файл

В некоторых системах UNIX доступна только одна из этих двух форм.

Бит установки эффективного группового идентификатора (SGID) при запуске файла на выполнение действует сходным с SUID образом: как и в случае установленного бита SUID, установленный SGID вызывает присвоение процессу, чей исполняемый код содержится в запущенном файле, эффективного идентификатора группы, равного идентификатору группы этого файла.

В выводе команды ls файлы с установленными битами SUID и SGID отличаются от прочих тем, что в поле, где обычно стоит "x" (бит выполняемости), оказывается символ "s":

-r-xr-sr-x    1 root   tty   10040 Nov  4  2002 /usr/sbin/wall
-r-sr-sr-x    1 root   sys   22168 Nov  4  2002 /usr/bin/passwd

Это означает, что присутствуют оба бита: и бит запускаемости, и бит SUID (или SGID, соответственно). Если попытаться установить бит SUID или SGID на файл, для которого в соответствующем праве доступа (владельца или группы) не будет бита запускаемости, то система не даст это сделать. Поскольку для каталога биты SUID и SGID имеют другое значение, то биты SUID/SGID и биты права поиска в каталоге могут быть установлены по отдельности. В выводе ls в правах доступа к каталогу при отсутствии права поиска и наличии битов SUID/SGID буква S в выводе прав доступа будет большой:

dr-Sr-xr-x    2 root   other   512 May 10 01:48 enum
-rw-r--r--    1 root   other     0 May 10 01:47 q

Обратите внимание на права доступа к каталогу enum. Объяснение смысла SUID/SGID для каталога дано в лекции 7.

Найти все файлы, у которых установлен бит SUID, можно с помощью команды

find / -perm –u+s

а файлы с установленным битом SGID – по команде

find / -perm –g+s

Относитесь внимательно к файлам, права доступа к которым разрешают запускать их от чужого имени. Появление таких файлов в системе может облегчить жизнь взломщику. Программа passwd, например, написана таким образом, что запускающий ее пользователь точно не сможет с ее помощью сделать ничего, кроме изменения собственного пароля. Поэтому ей можно доверить запускаться с правами root'a. Где гарантия, что все остальные программы с установленным SUID такие же? Устанавливайте бит suid только тем программам, которым доверяете на все сто!

Появление новых файлов с такими правами доступа к ним может говорить о попытке взлома системы, поэтому в некоторых ОС при установке автоматически устанавливается простой сценарий, использующий вышеописанную команду поиска таких файлов для поиска добавленных за последние сутки файлов с установленным битом suid. Например, во FreeBSD это делается в сценарии /etc/daily, ежедневно проверяющем состояние системы.

Имеет смысл удостоверится в том, что все новые файлы появились по известной вам причине.

Интерактивные и фоновые процессы

Процесс в UNIX может быть интерактивным и фоновым. Процесс, который имеет доступ к вводу с терминала и к выводу на него, называется интерактивным (foreground). Таким процессом является почтовая программа mail, редактор текста vi и другие программы. Фоновый процесс не имеет доступа к вводу с терминала и имеет условный доступ к выводу на терминал. Условие состоит в том, что вывод на терминал разрешен фоновому процессу, если терминал настроен для работы в режиме -tostop. Эту настройку можно выполнить командой

stty -tostop

Обратная настройка выполняется командой

stty tostop

Если фоновый процесс пытается выводить что-либо на терминал, настроенный для работы в режиме tostop, то процессу посылается сигнал SIGSTOP. Процесс, получивший такой сигнал, останавливается (переводится в состояние STOPPED).

Для запуска фонового процесса из командного интерпретатора следует дать команду, завершив ее знаком "" (амперсэнд):

команда 

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

make all 

Взаимодействие процессов

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

С каждым процессом связаны три независимых потока данных: стандартный ввод (stdin), стандартный вывод (stdout) и стандартный поток сообщений об ошибках (stderr). По умолчанию все три потока связаны с тем терминалом, с которого запущен процесс (стандартный ввод – с клавиатуры, вывод данных и ошибок – на экран). Стандартный ввод также называют входным потоком, а стандартный вывод – выходным.

Каждому из этих потоков сопосотавлены внутренние дескрипторы файлов: входному потоку – 0, выходному потоку – 1, потоку сообщений об ошибках – 2. Внутренний дескриптор файла существует только в пределах того процесса, с которым он связан. Внутренние дескрипторы в разных процессах имеют одинаковые номера, но это физически разные внутренние дескрипторы, и каждый процесс имеет свои собственные внутренние дескрипторы.

Перенаправление потоков

Поток данных, связанный с процессом, может быть перенаправлен в файл или другой поток данных. Например, если требуется, чтобы программа find выдала список имен файлов в файл names, а не на терминал, следует выполнить команду

find / -name "some_name" > names

Символ правой угловой скобки > означает перенаправление выходного потока запущенной программы в файл. При использовании этой конструкции файл names будет создан, а если он уже существует, то он будет уничтожен и будет создан новый файл с таким именем и новым содержимым.

Для добавления вывода программы в конец файла следует применять конструкцию "две правые угловые скобки" >>

find / -name "some_name" >> names

В этом случае файл names будет создан, если он не существует, а если существует, выходной поток программы find добавится в конец файла.

Можно перенаправить текст из файла во входной поток.

Если время от времени вы отправляете письма по стандартной форме, например, уведомляя пользователей о том, что их домашние каталоги превышают допустимый размер, можно подготовить такое письмо в текстовом редакторе и автоматически отправлять его из скрипта, проверяющего размер каталогов, с помощью команды

mail пользователь@компьютер < файл_с_письмом

Бывает необходимо отправлять пользователям не совершенно одинаковые письма, а письмо, где стандартный текст перемешан с личными обращениями и конкретными подробностями. Тогда на помощь приходит перенаправление потока посредством конструкции "документ здесь".

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

mail пользователь@компьютер <<FINAL
Дорогой(ая) $TARGETUSER,
Вы превысили допустимый размер домашнего каталога на $OVERSIZE
килобайт. Удалите ненужные Вам файлы, иначе это сделает робот!
Системный администратор
FINAL

Такой скрипт отправит по указанному адресу письмо, где вместо $TARGETUSER и $OVERSIZE будут подставлены имя того пользователя, которому предназначается письмо, и превышение лимита, соответственно. Естественно, этим переменным следует присвоить какое-то значение перед выполнением команды, но тот фрагмент скрипта, в котором это делается, вы с легкостью додумаете самостоятельно.

Указание в тексте значков << показывает что все, что следует непосредственно за ними до ближайшего символа-разделителя, является ограничителем текста. Символ-разделитель – это любой пустой символ: пробел, табуляция или конец строки. Все, что идет за ограничителем текста, передается во входной поток запущенного командой процеса вплоть до момента, когда в начале новой строки не встретится такой же ограничитель текста. Ограничитель может представлять собой любой набор непустых символов – неважно, просто ли это символ "точка", слово FINAL или что-то еще.

Кроме того, что потоки могут быть перенаправлены в файл или из файла, существует возможность перенаправить выходной поток одного процесса во входной поток другого. Направьте выходной поток программы ls во входной поток программы more, чтобы длинный список файлов вывести поэкранно:

ls –l | more

Символ вертикальной черты "|" означает перенаправление выходного потока программы, команда вызова которой находится слева от этого символа, во входной поток программы, вызываемой справа.

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

Например, для подсчета запущенных демонов httpd можно использовать такую конструкцию:

ps –auxw | grep httpd | wc –l

Программа ps выводит список всех процессов, запущенных в системе, grep выбирает из этого списка строки, в которых есть подстрока httpd, а wc с ключом l подсчитывает, как много строк оказалось в ее входном потоке.

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

Сигналы

Процессы могут взаимодействовать между собой, посылая друг другу сигналы. Список сигналов в Solaris ограничен сорока двумя сигналами, из которых наиболее употребительны TERM, KILL и HUP. В разных UNIX может быть разное количество сигналов, стандарт POSIX 1.1 определяет тридцать один сигнал. Каждый из них имеет свое мнемоническое обозначение и номер. В разных системах мнемонические обозначения остаются одинаковыми, а номер может быть разным.

Обычный процесс может послать сигнал только тому процессу, который имеет такой же эффективный идентификатор владельца, т.е. запущен тем же пользователем. Процесс, работающий от имени root, может послать любой сигнал любому процессу в системе.

С помощью команды

kill

можно послать сигнал с номером номер_сигнала процессу с идентификатором PID

kill –номер_сигнала PID

В некоторых системах UNIX есть возможность послать сигнал процессу с определенным именем с помощью программы killall:

killall –номер_сигнала имя_процесса

В Solaris эта программа имеет другое значение, а именно выполняет отправку сигнала завершения всем активным процессам:

killall

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

pkill sendmail

С помощью pkill можно отправлять сигнал завершения TERM процессу с тем или иным признаком, отправка сигнала процессу с определенным именем – не единственное умение pkill. Например,

pkill –HUP –G other,daemon

отправит сигнал HUP (SIGHUP) всем процессам, чья фактическая группа – other или daemon.

В табл. 9.2 приведен список сигналов, определенный стандартом POSIX 1.1, а в табл. 9.3 – список сигналов, определенных в Solaris 9.

Кроме команды pkill системный администратор может найти удобной команду pgrep, которая заменяет конструкцию

ps –ef | grep команда

В Solaris для получения того же результата можно ввести более короткую команду

pgrep команда

Каналы и сокеты

Процессы могут обмениваться данными друг с другом, и в UNIX предусмотрены механизмы такого обмена. Прежде всего, это каналы (pipes) и сокеты (sockets), которые служат для межпроцессной коммуникации, т.е. для передачи данных между одновременно запущенными процессами.

Канал – это последовательность байт, используемая как однонаправленный поток ввода/вывода.

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

Сокет – это объект, который используется для межпроцессных коммуникаций; он существует, пока какой-либо процесс хранит дескриптор, ссылающийся на него. Сокет создается системным вызовом socket, который возвращает его дескриптор. Имеется несколько типов сокетов, которые поддерживают различные возможности передачи данных.

Для каждого процесса ядро хранит таблицу внутренних дескрипторов. По-английски эта таблица называется "descriptor table", и чтобы не путать ее с таблицей дескрипторов в файловой системе, мы называем внутреннюю таблицу дескрипторов, относящуюся к конкретному процессу, "таблицей внутренних дескрипторов". Слово "внутренних" подчеркивает то, что эти дескрипторы существуют только в пределах процесса, который пользуется ими для обращения к файлам. Эта таблица наследуется от родительского процесса, поэтому вместе с ней наследуется и доступ к объектам, на которые ссылаются дескрипторы (файлам, каналам, сокетам).

Основными способами, при помощи которых процесс может получить дескриптор, является открытие или создание объекта, а также наследование от родительского процесса. Когда процесс завершается, ядро освобождает все дескрипторы, которые использовались этим процессом. Если процесс хранил последнюю ссылку на объект – файл или канал (т.е. в файловой системе больше не содержится записей об этом объекте), то система выполняет окончательное удаление файла (канала) или уничтожение сокета.

Подробнее о сокетах можно прочесть в socket (3).

Семафоры

Семафоры – это механизм, который принято использовать для контроля доступа нескольких процессов к одному ресурсу. Есть несколько реализаций программного интерфейса (API), связанного с семафорами:

Семафор по сути – это переменная, в зависимости от значения которой доступ к тому или иному ресурсу разрешается или блокируется до его освобождения. Семафоры широко используются в Oracle. Чтобы настроить подсистему семафоров в Solaris до версии 9 включительно (обеспечить достаточное количество семафоров в ядре), может потребоваться внести изменения в файл конфигурации ядра /etc/system. Для уточнения того, какие настройки требуются именно вашему программному обеспечению под Solaris, обратитесь к руководству по этому ПО.

Для Oracle8i в Oracle8i Installation Guide Release 3 рекомендуются следующие начальные значения параметров:

set semsys:seminfo_semmni=100
set semsys:seminfo_semmsl=<10+самое большое значение PROCESSES
                           среди ваших БД>
set semsys:seminfo_semmns=<столько, сколько объяснено ниже>
set semsys:seminfo_semopm=100
set semsys:seminfo_semvmx=32767

Значение seminfo_semmns рекомендуется установить равным сумме параметров PROCESSES всех баз данных сервера, причем самый большой из них должен быть просуммирован с коэффициентом 2, плюс еще 10 на каждую базу данных.

Посмотреть текущие значения параметров семафоров в Solaris до версии 9 включительно было можно по команде

sysdef | tail -25

Однако начиная с версии Solaris 10 для этого следует применять команду prctl, об использовании которой больше рассказывается в лекции 5 курса "Системное администрирование ОС Solaris 10".

Посмотреть текущие наборы семафоров в Solaris можно по команде

ipcs -sb

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

ipcrm -s semsetID

semsetID здесь означает идентификатор набора семафоров.

Управление процессами

Команды наблюдения за процессами

Для просмотра текущего списка и состояния процессов следует использовать программу ps. Она выдает "мгновенный снимок" таблицы процессов, которые запущены в системе.

Программа ps без аргументов сообщает список процессов, запущенных пользователем в текущей сессии. Обычно системного администратора интересуют все запущенные в системе процессы, список которых можно узнать по команде

ps –ef

В системах BSD и System V программа ps имеет разные ключи, поэтому если вы переходите от одной системы к другой, надо помнить об этих различиях или обращаться к man ps.

Разберем подробнее, какую информацию выдает программа ps.

ps -ef | more

UID    PID  PPID  C STIME     TTY  TIME  CMD
root   0    0     0 17:43:30  ?    0:03  sched
root   1    0     0 17:43:30  ?    0:00  /etc/init -s
root   2    0     0 17:43:30  ?    0:00  pageout
root   3    0     0 17:43:30  ?    0:00  fsflush
root   349  1     0 17:43:53  ?    0:00  /usr/lib/saf/sac –t 300
root   277  276   0 17:43:49  ?    0:00  htt_server –port 9010
                                         –syslog -message_locale C
root   180  1     0 17:43:45  ?    0:00  /usr/lib/autofs/automountd
root   59   1     0 17:43:39  ?    0:00  /usr/lib/sysevent/syseventd
root   73   1     0 17:43:40  ?    0:00  /usr/lib/picl/picld
root   133  1     0 17:43:43  ?    0:00  /usr/sbin/rpcbind
root   229  1     0 17:43:48  ?    0:00  /usr/lib/power/powerd
root   172  1     0 17:43:44  ?    0:00  /usr/lib/nfs/lockd
root   156  1     0 17:43:44  ?    0:00  /usr/sbin/inetd -s
root   217  1     0 17:43:47  ?    0:00  /usr/lib/lpsched
daemon 168  1     0 17:43:44  ?    0:00  /usr/lib/nfs/statd
root   189  1     0 17:43:45  ?    0:00  /usr/sbin/syslogd
root   203  1     0 17:43:46  ?    0:00  /usr/sbin/cron
root   205  1     0 17:43:46  ?    0:00  /usr/sbin/nscd
root   343  1     0 17:43:53  ?    0:00  /usr/sbin/vold
root   240  1     0 17:43:48  ?    0:00  /usr/lib/utmpd
root   324  1     0 17:43:51  ?    0:00  /usr/lib/snmp/snmpdx –y –c
                                         /etc/snmp/conf     
root   261  1     0 17:43:49  ?    0:00  /usr/sadm/lib/smc/bin/smcboot
root   355  329   0 17:43:56  ?    0:00  /usr/dt/bin/dtlogin -daemon
root   329  1     0 17:43:52  ?    0:00  /usr/dt/bin/dtlogin -daemon
root   262  261   0 17:43:49  ?    0:00  /usr/sadm/lib/smc/bin/smcboot
root   263  261   0 17:43:49  ?    0:00  /usr/sadm/lib/smc/bin/smcboot
root   354  1     0 17:43:55  ?    0:00  /usr/lib/ssh/sshd
root   338  1     0 17:43:52  ?    0:00  /usr/lib/dmi/snmpXdmid -s sunny
root   352  349   0 17:43:53  ?    0:00  /usr/lib/saf/ttymon
root   353  329   2 17:43:54  ?    1:41  /usr/openwin/bin/Xsun :0
                                         –nobanner –auth     
                                         /var/dt/A:0-KtaiPa     
root   356  329   0 17:43:56  ?    0:00  /usr/openwin/bin/fbconsole –d :0
root   358  324   0 17:43:57  ?    0:00  mibiisa -r –p 5248
root   337  1     0 17:43:52  ?    0:00  /usr/lib/dmi/dmispd

Ниже мы описываем смысл колонок этого вывода. Некоторые колонки появятся только при использовании специфических ключей, отличных от ключей ef. Для получения еще более детальной информации следует обратиться к man ps.

UID – эффективный идентификатор владельца процесса (реальный выводится при использовании ключа –f ).

В колонке F – flags (флаги) – выводятся флаги процесса; это устаревшее поле, сохраненное для совместимости.

В колонке S – state (состояние) – указывается состояние процесса. Состояния бывают следующие:

Идентификатор PID – уникальный идентификатор процесса, используется при передаче ему сигналов.

PPID – идентификатор родительского процесса.

C – загрузка процессора на планирование задачи (устарело, выводится для совместимости).

CLS – класс планирования.

PRI – приоритет процесса; когда указан ключ -с, б о льшие значения означают б о льший приоритет, без ключа –с б о льшие значения означают меньший приоритет.

NI – значение NICE (показателя уступчивости), используется при вычислении глобального приоритета процессов в классе разделения времени.

ADDR – адрес в памяти.

SZ – размер процесса в виртуальной памяти, включая все отображенные файлы и устройства, измеряется в страницах памяти; для получения размера в килобайтах в большинстве случаев это значение надо умножить на 4, точнее – см. команду pagesize.

WCHAN – адрес события, ради которого процесс перешел в состояние сна; если поле пусто – процесс запущен.

STIME – время запуска процесса, в часах, минутах и секундах; для запущенных более суток назад процессов указываются месяцы и дни.

TTY – управляющий терминал (то же, что и терминальная группа), символ вопросительного знака "?" печатается для процесса без управляющего терминала.

TIME – сколько времени процесс отнял у процессора.

CMD – команда, которой был запущен процесс.

При указании ключа j выводятся дополнительные сведения:

При указании ключа L выводятся дополнительные сведения, причем информация выдается по одной строке на каждый легковесный процесс. Обычные однопоточные процессы соотносятся только с одним легковесным процессом:

Процессы, которые завершились, но чей код заверешния не был востребован родительским процессом, помечаются как <defunct>.

Кроме программы ps в UNIX для получения информации о запущенных в данный момент процессах широко используется команда top:

top
last pid: 923;     load averages:  4.56,     1.18,     0.50  17:54:22
64 processes:   63 sleeping, 1 on cpu
CPU states: 0.0% idle, 0.5% user, 99.5% kernel, 0.0% iowait, 0.0% swap
Memory: 128M real, 18M free, 101M swap in use, 499M swap free
PID USERNAME LWP PRI NICE  SIZE    RES  STATE  TIME    CPU  COMMAND
909 root     1   60  0      17M  3340K  sleep  0:00  0.92%  pagein
353 root     1   58  0      32M    16M  sleep  0:05  0.37%  Xsun
893 root     1   49  0    2228K  1172K  cpu    0:00  0.15%  top
753 root     1   49  0      15M  8112K  sleep  0:00  0.13%  dtterm
911 root     1   59  0    3352K   752K  sleep  0:00  0.03%  sh
912 root     1   49  0    3360K   600K  sleep  0:00  0.03%  sh
894 root     1   59  0    3064K  1816K  sleep  0:00  0.03%  dtexec
656 root     5   59  0      22M    10M  sleep  0:01  0.02%  dtwm
648 root     1   59  0    6644K  2280K  sleep  0:00  0.02%  ttsession
667 root     1   59  0    1844K   512K  sleep  0:00  0.02%  rpc.rstatd
277 root     29  59  0    5612K  1724K  sleep  0:00  0.01%  htt_server
895 root     1   59  0    3360K   756K  sleep  0:00  0.01%  soffice
720 root     4   49  0      42M    26M  sleep  0:03  0.00%  mozilla-bin
649 root     1   49  0      18M  6288K  sleep  0:00  0.00%  dtsession
760 root     1   49  0    4752K  1656K  sleep  0:00  0.00%  bash

В Solaris вместо команды top принято использовать похожую по функциональности команду prstat.

Кроме этого, в Solaris для удобства получения информации о процессах с определенными именами есть команда

pgrep имя

Она является эквивалентом команды

ps –ef | grep имя

С помощью pargs можно посмотреть, какие аргументы переданы конкретному процессу и какая у него среда окружения:

pargs 2793
2793:    dtterm -name Run -xrm *menuBar: False -iconic -map -e /usr/dt/
bin/dtexec -open
argv[0]: dtterm
argv[1]: -e
argv[2]: /usr/dt/bin/dtexec
argv[3]: -open
argv[4]: -1
argv[5]: -ttprocid
argv[6]: 2.10fX-r 01 648 1289637086 1 1 0 192.168.5.33 5 sunny_105_1
argv[7]: /export/home/mozilla_bin/sfw/bin/mozilla
argv[8]: <NULL>
argv[9]: -open
argv[10]: -1
argv[11]: -ttprocid
argv[12]: 2.10fX-r 01 648 1289637086 1 1 0 192.168.5.33 5 sunny_105_1
argv[13]: /export/home/mozilla_bin/sfw/bin/mozilla

pargs -e 2793
2793:    dtterm -name Run -xrm *menuBar: False -iconic -map -e /usr/dt/
bin/dtexec -open
envp[0]: AB_CARDCATALOG=/usr/dt/share/answerbooks/ru_RU.UTF-8/
ab_cardcatalog
envp[1]: DISPLAY=:0.0
envp[2]: DTAPPSEARCHPATH=//.dt/appmanager:/etc/dt/appconfig/
appmanager/%L:/etc/dt/appconfig/appmanager/C:/usr/dt/appconfig/
appmanager/%L:/usr/dt/appconfig/appmanager/C
envp[3]: DTDATABASESEARCHPATH=//.dt/types,/etc/dt/appconfig/types/%L,/
etc/dt/appconfig/types/C,/usr/dt/appconfig/types/%L,/usr/dt/appconfig/
types/C

Вывод команды pargs значительно сокращен, ключ –e требует вывести все содержимое среды окружения, а для графических программ типа dtterm, как в нашем примере, среда окружения весьма велика.

Команда prstat позволяет в динамике, подобно команде top, отслеживать состояние процессов:

prstat

PID  USERNAME SIZE   RSS  STATE  PRI NICE  TIME    CPU   PROCESS/NLWP
3576 root    3412K  868K  run    13   0   0:00:02  6,3%  find/1
353  root      45M   19M  sleep  59   0   0:02:30  0,2%  Xsun/1
753  root      15M 3620K  run    49   0   0:00:02  0,1%  dtterm/1
3577 root    6640K 4108K  cpu0   49   0   0:00:00  0,1%  prstat/1
205  root    2872K  624K  sleep  59   0   0:00:00  0,0%  nscd/18
895  root     123M   21M  sleep  49   0   0:00:49  0,0%  soffice.bin/4
667  root    1844K  488K  sleep  59   0   0:00:00  0,0%  rpc.rstatd/1
217  root    5364K  536K  sleep  59   0   0:00:00  0,0%  lpsched/1
324  root    4360K  196K  sleep  59   0   0:00:00  0,0%  snmpdx/1
240  root    1100K  288K  sleep  59   0   0:00:00  0,0%  utmpd/1
343  root    4892K    0K  sleep  59   0   0:00:00  0,0%  vold/3
276  root    3240K    0K  sleep  59   0   0:00:00  0,0%  htt/1
633  root    3784K    0K  sleep  59   0   0:00:00  0,0%  sdt_shell/1
657  root      16M 2496K  sleep  49   0   0:00:00  0,0%  dtfile/1
203  root    4484K  568K  sleep  59   0   0:00:00  0,0%  cron/1
189  root    5636K 1092K  sleep  59   0   0:00:00  0,0%  syslogd/13
168  daemon  2444K  820K  sleep  59   0   0:00:00  0,0%  statd/1
156  root    2412K  688K  sleep  59   0   0:00:00  0,0%  inetd/1
172  root    2160K  748K  sleep  59   0   0:00:00  0,0%  lockd/2
229  root    1348K    0K  sleep  59   0   0:00:00  0,0%  powerd/2
133  root    2212K  604K  sleep  59   0   0:00:00  0,0%  rpcbind/1
Total: 61 processes, 161 lwps, load averages: 0,25, 0,17, 0,27

Вы можете получить информацию только о тех процессах, которые запущены вами. Пользователь root может получть информацию о любых процессах.