Европейский Университет в Санкт-Петербурге
Опубликован: 19.10.2005 | Доступ: свободный | Студентов: 1763 / 169 | Оценка: 4.31 / 3.82 | Длительность: 18:28:00
Лекция 1:

Оптимизация работы процессов

Лекция 1: 1234 || Лекция 2 >
Аннотация: Лекция описывает процесс оптимизации работы процессов для увеличения производительности компьютера. Рассматриваются наиболее вероятные причины снижения скорости работы и способы их устранения.

Что будем оптимизировать?

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

Оптимизации подлежит следующее:

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

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

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

Виртуальная память в Solaris

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

Вся виртуальная память разбита на страницы объемом 4 Кбайт.

Некоторые компьютеры в силу их аппаратной реализации используют страницы памяти по 8 Кбайт. К ним относятся компьютеры с микропроцессорами DEC Alpha, первыми процессорами Sun SPARC (например, Ross RT601/Cypress CY7C601/Texas Instruments TMS390C601A, устанавливавшиеся в SPARCstation 2) и модели Sun UltraSPARC. В Solaris для определения фактического размера страницы памяти следует использовать программу /usr/bin/pagesize или функцию getpagesize(3C).

Потребителями виртуальной памяти в Solaris являются ядро системы, кэши файловой системы, тесно разделяемая память (intimately shared memory) и процессы. Тесно разделяемая память специфична для Solaris и представляет собой область разделяемой памяти, которую нельзя выгружать на диск. Тесно разделяемую память используют такие программы, как Oracle, Sybase, Informix.

Виртуальная память построена на четырех принципах, реализованных в системе.

Во-первых, каждый процесс получает отдельное виртуальное адресное пространство (virtual address space). Это значит, что процессу доступен определенный диапазон ячеек памяти. Максимальный размер этого диапазона памяти определяется длиной слова адреса в компьютере. Процесс, запущенный в 32-разрядной системе, будет иметь виртуальное адресное пространство размером 4 гигабайта (длина адреса - 32 бита). Подсистема виртуальной памяти соотносит (отображает) пользовательский кусочек виртуального адресного пространства и реальные страницы физической памяти.

Во-вторых, адресные пространства нескольких процессов могут перекрываться незаметно для процессов, если они используют общий код. Например, одновременно могут быть запущены три экземпляра одного и того же командного процессора (пусть это будет bash ). Они имеют отдельные виртуальные адресные пространства. В каждом виртуальном пространстве находится экземпляр процесса командного интерпретатора, копия библиотеки libc и (возможно) копии других разделяемых процессами ресурсов. Подсистема виртуальной памяти незаметно для процессов отображает эти разделяемые куски памяти в одну и ту же область физической памяти так, что в физической памяти содержится всего один экземпляр разделяемого ресурса. Похоже на создание жестких ссылок на файл, верно?

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

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

Оценка необходимого размера оперативной памяти

Для оценки памяти, занимаемой каждым из процессов, можно использовать как уже известные команды top и ps, так и команду pmap (последняя дает более подробное распределение памяти процесса по типам - разделяемая память и т.п.):

pmap -х

Вообще говоря, в Sоlaris существует целое семейство так называемых процессных утилит (proc tools) или p-команд, работающих с файловой системой /proc, в которую отображаются многие структуры ядра, в частности, таблица процессов. Эти программы позволяют получать самую разную информацию о процессах, а некоторые из них могут также проанализировать завершившийся аварийно процесс, если от него остался файл core 1Файл core записывается в текущий каталог процесса в случае аварийного завершения; слу- чаи прерывания процесса по сигналам KILL, TERM и HUP к этому не относятся. Имя файла - всегда core, независимо от имени файла, который был запущен для порождения аварийного процесса. Файл core представляет собой дамп памяти (всех сегментов) процесса, поэтому его можно проанализировать так же, как и запущенный процесс, это - моментальный снимок памяти процесса на момент аварийного завершения (прим. авт.)..

Не следует забывать, что память потребляется не только процессами, но и кэшем файловой системы, тесно разделяемой памятью и ядром! Если в системе не запускается СУБД Oracle или другое подобное приложение, скорее всего, тесно разделяемая память в системе не используется. В Solaris 8 и Solaris 9 для ядра и обязательно запускающихся системных приложений следует заранее предусмотреть не менее 32 Mбайт памяти и еще 16 Mбайт, если CDE тоже запускается. Рекомендованным для Solaris 9 объемом памяти (не считая память, которая требуется для специфических приложений - СУБД, почтового сервера и т.п.) считается 64 Мбайт, но оптимальным для системы, в которой работают с графическим интерфейсом, считается 128 Мбайт. Если планируется одноврменно запускать несколько ресурсоемких графических приложений, например, Mozilla и OpenOffice, следует, по крайней мере, удвоить этот рекомендованный объем.

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

Лекция 1: 1234 || Лекция 2 >