Администрирование ОС Solaris 9

Настройка производительности системы

Разбить на страницы
Показывать лекцию целиком

Какая аппаратура быстрее?

Естественно, для разных задач подходят разные компьютеры. Например, компьютеры с процессором Alpha обычно быстрее своих Intel-собратьев выполняют расчеты с числами с плавающей запятой. Это значит, что вычисления, связанные с расчетами координат, решением уравнений или моделированием молекул, быстрее выполнит компьютер с процессором Alpha.

В настоящее время процессоры Alpha широко используются в высокопроизводительных серверах от Hewlett-Packard и в других, еще более специализированных системах, таких как суперкомпьютеры Cray и Fujitsu.

Если же речь идет о целочисленных вычислениях, пусть и достаточно громоздких, например, рендеринге, преобразовании графических объектов, 3D-визуализации, где координаты могут быть заданы только целыми числами, процессоры Intel отлично справятся с ними.

Сейчас мы говорили о процессорах Alpha и Intel, но на деле разговор касается двух разных архитектур - RISC и CISC. Процессоры Intel традиционно тяготеют к последней, в то время как процессоры SPARC - к первой. ОС Solaris выпускается в версиях для обеих архитектур, хотя изначально компания Sun не выпускала версию Solaris для Intel, а многочисленные пользователи этой системы во всем мире до сих пор утверждают, что версия для SPARC более производительна и надежна. Это, в частности, объясняется тем, что механизмы обеспечения многозадачности тесно связаны с используемой аппаратурой, и версия Solaris под Intel "подогнана" под архитектуру процессоров Intel и архитектуру аппаратных средств, разработанных для них.

Надо отметить отличные результаты процессора Itanium, сравнительно нового процессора Intel с 64-разрядной архитектурой, который прекрасно показал себя в тесте вычислений с плавающей запятой SPECfp2000, что выгодно отличает его от предшествовавших 32-разрядных собратьев, но менее удачно выступил в целочисленном тесте.

В заключение разговора о предпочтительности той или иной аппаратуры следует сказать, что:

  • Для работы Solaris под серьезной нагрузкой, такой как СУБД Oracle с тысячами клиентов и важностью высокой скорости реагирования, система на базе процессоров RISC скорее всего окажется более результативной.
  • Независимо от используемой аппаратной платформы конфигурация компьютера должна быть хорошо согласована: быстрый процессор должен работать с быстрой оперативной памятью, а дисковая подсистема (контроллеры и диски ) обязана без задержек отрабатывать команды чтения и записи. Недостаточный объем кэша любого уровня - как кэша процессора на кристалле, так и кэша дискового контроллера - может привести к значительному снижению производительности.
    •
    Сравнение производительности разных систем
    Процессор, частота CPECint2000 (base) CPECfp2000 (base) Система
    Alpha21264C, 1.01 GHz 561 585 Compaq AlphaServer GS160
    Alpha21264C, 1 GHz 776 621 Compaq AlphaServer ES45
    Alpha21264B, 833 MHz 518 621 Compaq AlphaServer ES40
    Itanium, 800 MHz 379 701 HP rx4610
    Itanium, 800 MHz 358 655 HP i2000
    UltraSPARC III 1.05 GHz 537 701 Sun Blade 2050
    UltraSPARC III 900 MHz 470 629 Sun Blade 1000
    UltraSPARC III 750 MHz 363 312 Sun Blade 1000
    Power4, 1.3. GHz 790 1098 IBM eServer 690

    Оценка ситуации: программы надзора за системой

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

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

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

    Для оценки загрузки процессора и состояния памяти (достаточно ли оперативной памяти, не перегружена ли дисковая подсистема свопингом и т.п.) служат программы top и sar. Конкретные примеры применения этих программ даны ниже, в разделе "Эффективное использование памяти и свопинга ". Программа top выводит информацию о процессах, которые наиболее активно занимают процессор:

    top
last pid:  501; load averages: 0.08, 0.34, 0.40     19:12:00
59 processes: 58 sleeping, 1 on cpu
CPU states: 96.2% idle, 0.8% user, 1.0% kernel, 2.0% iowait, 0.0% swap
Memory: 128M real, 3596K free, 132M swap in use, 466M swap free
 PID USERNAME	LWP	PRI	NICE	SIZE	RES	STATE	TIME	CPU	COMMAND
 345 root 	1	59	0	24M	9972K	sleep	0:11	1.14%	Xsun
 470 root 	4	49	0	128M	71M	sleep	0:52	1.01%	soffice.bin
 501 root 	1	59	0	2228K	1336K	cpu	0:00	0.55%	top
 461 root 	1	59	0	15M	3184K	sleep	0:00	0.37%	dtterm
 467 root 	1	49	0	4708K	832K	sleep	0:00	0.00%	bash
 435 root 	1	49	0	16M	1760K	sleep	0:00	0.00%	dtfile
 434 root 	5	59	0	22M	6304K	sleep	0:01	0.00%	dtwm
 427 root 	1	49	0	18M	0K	sleep	0:00	0.00%	dtsession
 436 root 	1	59	0	14M	3292K	sleep	0:00	0.00%	sdtperfmeter
 265 root 	26	59	0	5480K	1456K	sleep	0:00	0.00%	htt_server
 460 root 	1	59	0	3064K	1372K	sleep	0:00	0.00%	dtexec
 315 root 	1	59	0	6900K	1324K	sleep	0:00	0.00%	dtlogin
 411 root 	1	59	0	3784K	1300K	sleep	0:00	0.00%	sdt_shell
 183 root 	3	59	0	5832K	1188K	sleep	0:00	0.00%	automountd
 195 root 	13	59	0	5660K	1100K	sleep	0:00	0.00%	syslogd

    Программа sar подобна vmstat и выдает статистику по работе системы, ее можно запустить для выдачи определенных параметров одномоментно или для периодического вывода сведений, например, для десятикратного измерения значений стандартного набора параметров с периодом 5 секунд:

    sar 5 10
SunOS sunny 5.9 Generic_112234-03 i86pc  07/03/2004
19:12:34	%usr	%sys	%wio	%idle
19:12:39 	0 	1 	0	99
19:12:44 	0 	0 	0	100
19:12:49 	0 	1 	0	99
19:12:54 	4 	1 	0	95
19:12:59 	0 	0 	0	100
19:13:04 	0 	1 	0	99
19:13:09 	5 	1 	0	94
19:13:14 	1 	24 	66 	8
19:13:19 	2 	35 	38 	25
19:13:24 	3 	20 	17 	60

    Решение проблем:изменение размеров разделов диска

    Если необходимо увеличить размер конкретного раздела, то есть два пути: физически изменить размер раздела или создать метаустройство, которое физически будет состоять из нескольких разделов на одном или нескольких дисках, но система будет его считать одним логическим разделом. Второй путь напоминает создание Volume Set в системах Windows.

    Чтобы физически изменить размер раздела, надо, чтобы на диске вслед за этим разделом было свободное пространство, еще не отданное ни одному разделу. Если там есть какой-то другой раздел, то его придется удалить, предварительно сохранив нужные данные из него. После этого потребуется выполнить резервное копирование всех данных увеличиваемого раздела в какой-то каталог другого раздела, удалить старый раздел, создать на его месте новый, больший, с помощью команды newfs, и затем восстановить файлы из резервной копии. Этот метод рекомендован для использования в любых системах UNIX. Однако он требует значительных затрат времени и дискового (или ленточного, в зависимости от того, где вы создаете резервную копию) пространства.

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

    Синтаксис команды growfs:

    /usr/sbin/growfs 	[-M точка_монтирования] [параметры_newfs]
[rawdevice]

    Аргументы команды growfs обозначают:

  • точка_монтирования - точка монтирования файлововй системы, которую требуется расширить. При этом на время расширения произойдет блокировка файловой системы функцией lockfs().
  • параметры_newfs - те же параметры, которые может принимать программа newfs при создании новой файловой системы, см. описание newfs.
  • rawdevice - имя файла прямого доступа для метаустройства в каталоге /dev/md/rdsk.
  • Команда growfs увеличивает размер файловой системы до размера указанного раздела.
    •

    Увеличение размера раздела выполняется посредством добавления нового раздела к метаустройству и последущего запуска growfs. При увеличении размера зеркала (т.е. уже существующего метаустройства с реализованным зеркалированием, или, иначе говоря, с RAID уровня 1) следует вначале увеличить каждую из частей зеркала с помощью metaattach, как показано ниже, а затем - всю файловую систему с помощью growfs.

    Особым случаем является расширение журналируемого метаустройства (trans metadevice), которое состоит из двух устройств - главного и журналирующего. Увеличивается только размер главного устройства, а затем growfs "напускается" на само журналируемое метаустройство. Вообще говоря, можно увеличить и размер журналирующего устройства, но это не является обязательным.

    Програма growfs на время модификации файловой системы блокирует запись в нее. Можно сократить время блокировки файловой системы, выполняя ее увеличение по частям. Например, мы хотим увеличить файловую систему размером 2 Гбайт до размера 8 Гбайт. Можно это делать поэтапно, добавляя по 16 Мбайт за этап, дав ключ s для явного указания размера общего размера новой файловой системы на каждом этапе. Число, следующее за ключом s, интерпретируется как общее число секторов новой файловой системы на каждом этапе и должно быть кратно размеру цилиндра в секторах. Иначе говоря, файловая система должна содержать целое число цилиндров.

    Подробнее об ограничениях, связанных с размером разделов, рассказано в руководстве по newfs и growfs.

    Представим себе, что требуется увеличить размер раздела /dev/dsk/c1t0d0s3, на котором расположена файловая система /export. Для этого нам потребуется вначале преобразовать этот раздел в метаустройство, поскольку добавлять дополнительное пространство можно только к метаустройству. Допустим, добавлять к существующему разделу мы будем пока еще пустой, не содержащий файловой системы раздел /dev/dsk/c2t0d0s3:

    metainit -f d8 2 1 c1t0d0s3 1 c2t0d0s3

    Эта команда вызывает объединение разделов /dev/dsk/c1t0d0s3 и /dev/dsk/c2t0d0s3 в новое метаустройство d8. Теперь изменяем /etc/vfstab так, чтобы файловая система /export монтировалась на метаустройство d8:

    #device 	device	mount	FS	fsck	mount	mount
#to mount 	to fsck	point	type	pass	at boot	options
/dev/md/dsk/d8	/dev/md/dsk/d8	/export	ufs	2	yes	-

    Демонтируем /export и снова монтируем его (при монтировании будет использовано новое устройство из /etc/vfstab ):

    umount /export
mount /export

    Запускаем growfs для расширения файловой системы на новый раздел:

    growfs -M /export/dev/md/rdsk/d8

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

    Файл /etc/lvm/md.tab содержит таблицу метаустройств, которая служит файлом настроек для запуска программы metainit при старте системы.

    Ограничения при работе с growfs

    С помощью growfs можно расширять только файловые системы UFS (не важно, смонтированные они или несмонтированные). Расширенная файловая система не может быть уменьшена. Расширение файловой системы невозможно, если:

  • на задействованном в ней устройстве находится файл учета запущенной системы acct, или
  • включена система безопасности на уровне C2 и файл журналирования находится на расширяемом устройстве, или
  • на ней находится локальный файл свопинга, или
  • эта файловая система монтируется в каталог /usr или корневой каталог или является активным разделом свопинга.
    •

    Увеличение производительности дисковой подсистемы

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

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

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

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

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

    Снижение частоты синхронизации файлового кэша с диском

    При частых и объемных операциях с файлами, файловый кэш быстро заполняет значительный объем памяти. В системах Solaris до версии 8 он даже конкурировал с процессами за оперативную память. Процесс fsflush регулярно (по умолчанию - раз в 30 секунд) "сбрасывает" на диск содержимое кэша, обеспечивая таким образом синхронизацию кэша и файловой системы. Если количество открытых файлов велико, эта синхронизация может приводить и к потерям времени и к чересчур высокой загрузке дисковой подсистемы.

    Демон fsflush руководствуется значением двух переменных, squid и tune_t_fsflushr, - значение им можно присвоить в файле /etc/system. Для систем с большим объемом памяти установленное по умолчанию значение squid в 30 с делает процесс fsflush чересчур дорогостоящим.

    Для того чтобы поубавить аппетит fsflush, время цикла синхронизации следует увеличить, изменив в большую сторону значение squid. Поскольку fsflush оказывает влияние на всю систему, лучше всего, чтобы он работал в течение более коротких промежутков времени. Для этого значение tune_t_fsflushr (время, отведенное fsflush на синхронизацию) должно быть меньше: выделив демону меньшее число секунд, вы заставите его выполнять меньшую по объему запись.

    Приостановка записи (write throttle) в файловой системе UFS

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

    Переменная ядра ufs:ufs_WRITES отвечает за включение механизма write throttling (приостановки записи в файл). Если эта переменная равна 1, то приостановка записи разрешена. По умолчанию это именно так.

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

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

    Такое увеличение вполне допустимо и даже полезно при использовании метаустройств с расщеплением (striping metadevices), когда данные одного файла поблочно пишутся на несколько устройств одновременно (первый блок - на первый диск, следующий - на второй и т.д.), так как совокупная пропускная способность метаустройства выше, чем у одного физического диска. То же относится и к массивам RAID. Значения ufs:ufs_LW и ufs:ufs_HW не должны быть слишком близкими, но и не должны очень сильно отличаться. Если они слишком близки, то приостановки записи будут случаться очень часто: как только объем буфера окажется у нижнего предела и запись будет разрешена, буфер сразу превысит верхний предел и запись приостановится. Большая разница между значениями приведет к тому, что запись в файл будет заблокирована при превышении верхнего предела, и после этого пройдет значительное время до разблокировки записи, так как буфер не может быть мгновенно "сброшен" на диск, и до достижения нижнего предела придется ждать относительно долго.

    Рекомендуется нижний предел устанавливать равным 1/32 объема оперативной памяти, а верхний - 1/16 этого объема.

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

    Кэш поиска имен каталогов (DNLC)

    Чтобы не искать номер индексного дескриптора по имени файла каждый раз, когда к файлу происходит обращение, система кэширует имена файлов и каталогов вместе с номерами их виртуальных индексных дескрипторов. Этот специальный кэш называется кэш поиска имен каталогов (directory name lookup cache - DNLC).

    При открытии файла DNLC вычисляет соответствующий индексный дескриптор по имени этого файла. Если имя уже находится в кэше, то оно отыскивается очень быстро, поскольку не происходит сканирования каталогов на диске. Каждая запись DNLC в ранних версиях системы имела фиксированный размер, поэтому пространство для имени файла не могло превышать 30 символов, а более длинные имена файлов не кэшировались. Начиная с Solaris 7, это ограничение снято. Если каталог содержит несколько тысяч записей, поиск номера индексного дескриптора конкретного файла отнимет много времени. В том случае, когда в системе открыто много файлов, а количество файлов в рабочих каталогах велико, высокая частота успешных обращений к DNLC очень важна.

    Кэш имен каталогов не нуждается в настройке, хотя его размер зависит от значения maxusers. По умолчанию он определяется как (17x maxusers )+90 (в Solaris 2.5.1) или 4x( maxusers + max_nprocs )+320 (в Solaris 2.6 и выше). Другие параметры, на которые тоже оказывает влияние maxusers, обсуждены в лекции 10.

    Команда

    vmstat -s

    показывает частоту успешных попаданий в DNLC с момента начала работы системы.

    Если частота промахов велика (попаданий обычно не должно быть меньше 90%), следует подумать об увеличении размера DNLC. Проверим этот показатель работы системы командой

    vmstat -s |grep 'name lookups'
	422920 total name lookups (cache hits 99%)

    Количество запросов к DNLC в секунду можно получить из поля namei/s в выводе команды sar -a:

    sar -a  1 5 
SunOS sunny 5.9 Generic_112234-03 i86pc  07/03/2004
19:26:50 	iget/s 	namei/s 	dirbk/s
19:26:51	0	1	0
19:26:52 	0 	0 	0
19:26:53 	0 	0 	0
19:26:54 	0 	4 	0
19:26:55 	0 	0 	0

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

    find / -name "top" 
[1] 577
sar -a 1 5
SunOS sunny 5.9 Generic_112234-03 i86pc  07/03/2004
19:27:14 	iget/s 	namei/s 	dirbk/s
19:27:15  	1675  	2592  	1922
19:27:16  	1220  	2365  	1474
19:27:17   	968  	1882  	1172
19:27:18  	1057  	2107  	1292
19:27:19  	1231  	2211  	1443
vmstat -s |grep 'name lookups'
  503370 total name lookups (cache hits 86%)

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

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

    Как уже обсуждалось в лекциях 5 и 6, при создании файловой системы для индексных дескрипторов выделяется отдельное пространство на разделе. Индексные дескрипторы хранят свойства файла, в том числе теневые индексные дескрипторы - расширенные права доступа. Количество индексных дескрипторов - это неизменяемая величина. Отсутствие свободных индексных дескрипторов в файловой системе приводит к невозможности записывать файлы в те каталоги, которые расположены в этой файловой системе. Количество свободных индексных дескрипторов можно определить, проанализировав вывод команды df -e:

    df -e
Filesystem					ifree
/proc							862
/dev/dsk/c0t0d0s0 		294838
fd 							0
/dev/dsk/c0t0d0s4		246965
swap 							9796
/dev/dsk/c1t0d0s0 		3256077

    Количество одновременно записываемых блоков

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

    Количество группируемых блоков равно параметру файловой системы maxcontig . В версиях, предшествующих Solaris 8, этот параметр по умолчанию был равен семи, и, таким образом, операция ввода-вывода происходила одновременно с семью последовательными блоками и позволяла одновременно записать порцию данных размером 56 Kбайт. Такое значение по умолчанию связано с ограничениями конструкции в раннем оборудовании Sun: системы, основанные на архитектуре sun4, не способны передавать за одну операцию более 64 Kбайт. В архитектурах sun4c, sun4m, sun4d и sun4u таких ограничений нет. В Solaris 8 значение по умолчанию изменилось и составляет 16 блоков (128 Kбайт).

    Изменение параметра maxcontig может серьезно повлиять на производительность файловой системы , при работе с которой преобладают последовательные операции по записи средних и больших (более нескольких десятков килобайт) файлов на диск. Если при доступе к файловой системе большинство операций ввода-вывода совершается с данными малого размера, то изменение maxcontig не принесет особой пользы.

    Размер кластера файловой системы задается с помощью ключа -С blocks команды newfs при создании файловой системы. Для существующей файловой системы его можно изменить с помощью ключа -a команды tunefs.

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

    Настройка параметров файловой системы

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

    iostat -x 5

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

    ...
device 	r/s 	w/s 	kr/s  	kw/s 	wait 	actv 	svc_t 	%w 	%b 
cmdk0 	17.6 	2.9 	138.4 	53.1 	1.1 	0.2 	60.1 	3 	13
fd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
sd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
nfs1 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	9.3  	0  	0
		extended device statistics 
device 	r/s 	w/s 	kr/s  	kw/s 	wait 	actv 	svc_t 	%w 	%b 
cmdk0   307.7  0.2 766.1  2.0 0.0 0.9  2.9  0 89 
fd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
sd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
nfs1 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
		extended device statistics 
device 	r/s 	w/s 	kr/s  	kw/s 	wait 	actv 	svc_t 	%w 	%b 
cmdk0   253.4  0.7 768.0  6.0 0.0 0.9  3.6  0 88 
fd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
sd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
nfs1 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
...

    Средние значения загрузки можно получить из колонок kr/s и kw/s, в более ранних версиях системы для получения таких значений приходилось делить содержимое колонок "K/r" и "K/w" на "r/s" и "w/s" соответственно для получения средних показателей "прочитано килобайт в секунду" и "записано килобайт в секунду".

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

    quot -c file_system

    Например, вот каково распределение в моей тестовой системе:

    quot -c /export/home
...
1128 	1 	165156
1136 	1 	166292
1160 	1 	167452
1176 	1 	168628
1184 	1 	169812
1192 	1 	171004
1224  	1 	172228
1232 	1 	173460
1240 	1 	174700
1264 	1 	175964
1360 	1 	177324
1376 	1 	178700
1440 	1 	180140
1488 	1 	181628
1536 	1 	183164
1608 	1 	184772
1648 	1 	186420
1704 	1 	188124
1768 	1 	189892
1792 	1 	191684
1832 	1 	193516
2047 	40 	437396
...

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

    Эффективное использование памяти и свопинга

    Вопрос об установке в систему дополнительной оперативной памяти представляет собой классический вопрос выбора между ценой и производительностью. Если цена важнее производительности, то при нехватке памяти увеличивают размер раздела свопинга, если важнее производительность - увеличивают объем оперативной памяти. Если же нет возможности сделать ни то ни другое, новые процессы не смогут быть запущены при нехватке виртуальной памяти (это можно заметить по сообщениям "Not enough space" или "WARNING: /tmp: File system full, swap space limit exceeded").

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

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

    При этом высокая активность может быть временной или постоянной. В любом случае, имеет смысл уяснить ее причину.

    Частота сканирования страниц

    Повышенная частота сканирования страниц (scan rate) - главный показатель того, что в системе перестало хватать оперативной памяти. Для просмотра значения scan rate используйте команды

    sar -g

    или

    vmstat

    При анализе частоты сканирования с помощью vmstat имеет смысл запустить эту программу с параметром 60 для получения статистики каждые 60 секунд:

    vmstat 60
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr cd f0 s0 -- in sy cs us sy id
0 0 0 482100 7288 23 63 126 31 46 8 54 28 0 0 0 333 1519 327 5 11 84
0 1 0 470816 2060 0 26 1 51 103 0 123 240 0 0 0 960 969 649 4 92 4
...

    Первую строку (суммарную статистику) можно игнорировать. Если показатель page/sr остается выше 200 страниц в секунду в течение длительного времени, это говорит о вероятной нехватке оперативной памяти в системе.

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

    Активность свопинга

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

    iostat -xPnce

    для получения информации об активности передачи данных в/из конкретных разделов дисков, в Solaris 2.5.1 доступна команда

    iostat -xc

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

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

    Можно также использовать

    sar -d

    или

    vmstat

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

    Использование памяти процессами

    В системах Solaris, начиная с версии 2.6, есть возможность выяснить, какие программы сколько памяти занимают (и подробнее - размеры сегментов данных, кода и т.п.) с помощью программы pmap.

    Для получения детальной информации дайте команду

    /usr/proc/bin/pmap -x PID

    Информация о размере процесса в оперативной памяти также содержится в колонке RSS вывода программ top и ps (используйте ps -ly ).

    В пакете SunPro есть отладчик dbx, который помогает находить источник утечки памяти в программе; для такой работы следует компилировать программу компилятором SunPro с ключом -g.

    Статистику использования разделяемой памяти вы получите по команде

    ipcs -mb

    Эти программы следует использовать для определения размера процессов и основных потребителей памяти в системе.

    Размер пространства свопинга

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

    Для управления пространством свопинга (получения информации о нем, добавления и удаления разделов свопинга ) используется программа swap. Получить информацию о текущем состоянии пространства свопинга можно с помощью swap -l.

    Для выяснения общего объема виртуальной памяти, который включает в себя объем оперативной памяти и пространства свопинга вместе, следует использовать swap -s или sar -r.

    Если своп-раздел смонтирован в /tmp как файловая система типа tmpfs, команда

    df -k /tmp

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

    Алгоритм пейджинга

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

    Параметры ядра и пейджинг

    physmem: общее количество страниц в оперативной памяти.

    lotsfree: сканер страниц начинает работать, когда количество свободной оперативной памяти становится меньше lotsfree.

    Значение по умолчанию - physmem/64, но оно может быть изменено в /etc/system. Сканер страниц по умолчанию запускается в режиме пейджинга. Частота сканирования ( scan rate, столбик sr в выводе vmstat ) устанавливается равной параметру slowscan , который по умолчанию равен fastscan/10.

    minfree: пока объем свободной памяти находится между lotsfree и minfree, частота сканирования страниц растет линейно от slowscan к fastscan по мере уменьшения размера свободной памяти (рис. 20.1). Значение minfree по умолчанию - desfree/2, значение fastscan по умолчанию - physmem/4. Если свободной памяти становится меньше, чем desfree (что по умолчанию равно lotsfree/2 ), сканер страниц начинает запускаться с частотой 100 раз в секунду. За каждый свой запуск сканер страниц проверяет desscan страниц. Этот параметр изменяется динамически вместе с частотой сканирования.

    maxpgio: этот параметр (в зависимости от конкретной аппаратуры он имеет значение 40 или 60) по умолчанию ограничивает частоту ввода-вывода на устройство пейджинга. Для современных дисков с частотой вращения больше 7200 оборотов в минуту можно установить значение maxpgio в сто раз больше количества жестких дисков, задействованных в свопинге.

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

    cachefree: имеет значение для систем Solaris 7 (или систем 2.5.1 и 2.6 с установленными самыми свежими обновлениями); если в этих системах параметр priority_paging установлен равным 1 (т.е. priority paging включен), то пока свободной памяти больше, чем lotsfree, освобождаются только страницы файлового кэша в памяти, а страницы процессов не затрагиваются. Значение по умолчанию - удвоенное lotsfree. Системы Solaris более поздних версий, начиная с 8-й, имеют другой алгоритм освобождения оперативной памяти, и в них НЕ следует включать priority paging и устанавливать значение cachefree.

    В системах Solaris до версии 7 включительно сканер страниц работает так: для выбранных сканером страниц обнуляется флаг "используемости" страницы, выбор страниц происходит со скоростью, которую можно посмотреть с помощью vmstat или sar -g (scan rate). После обработки handspreadpages страниц сканер проверяет, установлен ли флаг "используемости". Фактически, сканер состоит из двух процессов, один из которых идет по памяти и очищает флаги встреченных страниц, а второй следует за ним на некотором расстоянии и проверяет,не было ли новых обращений к этой странице (не установился ли снова этот флаг). Если флаг не установлен (обращений к странице за то время, пока сканер отмечал handspreadpages страниц, не произошло), то страница отправляется в своп. Параметр handspreadpages по умолчанию равен physmem/4.

    (рис 17.1) Зависимость частоты запуска сканера страниц от объема свободной памяти

    В системах Solaris 8 и более новых алгоритм освобождения памяти иной (он называется cyclical page cache ). Он рассчитан на то, что при нехватке памяти выгружаются прежде всего страницы файлового кэша, и только затем - страницы процессов. Этот алгоритм разработан для тех же целей, что и priority paging в Solaris 7. Новый алгоритм использует два списка свободных страниц. Один - для помещения в него освобождающихся страниц файлового кэша, другой - для помещения прочих освобождающихся страниц (разделяемой памяти, процессов и т.п.). При таком подходе файловый кэш ни с кем не соперничает за место в памяти.

    В результате этих изменений в системах Solaris, начиная с версии 8, vmstat сообщает иные цифры, чем в той же ситуации в более старых системах, а именно:

  • скорость возврата страниц выше;
  • весь файловый кэш показывается как свободная память ;
  • скорость сканирования страниц (scan rate) низкая (даже близка к нулю), за исключением ситуаций, когда в системе ощущается острая нехватка памяти для приложений.
    •

    Для получения отдельного отчета по пейджингу страниц приложений (executables), данных (anonymous) и файловой системы используйте команду

    vmstat -p

    Свопинг

    Если системе в течение некоторого времени (обычно 30 секунд подряд) не хватает памяти (объем свободной оперативной памяти падает ниже desfree ), то начинается свопинг процессов. Планировщик задач выгружает те процессы, которые не претендовали на процессорное время в течение более чем maxslp секунд. По умолчанию maxslp равно 20. Этот режим свопинга называется мягким.

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

    Не выгружаются:

  • процессы классов планирования SYS и RT;
  • процессы, запускаемые в данный момент или остановленные по сигналу (например, при отладке);
  • процессы, завершающие работу;
  • процессы, находящиеся в состоянии зомби;
  • системные потоки;
  • процессы, которые блокируют другие, более высокоприоритетные потоки.
    •

    Ввод-вывод без кэша

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

    Для этого можно использовать функцию directio() или параметр forcedirectio при монтировании файловой системы командой mount. Файловая система VxFS включает ввод-вывод в обход кэша всегда, когда объем операции ввода-вывода превышает значение параметра discovered_direct_iosz (см. man vxtunefs ) (по умолчанию - 256 Kбайт).

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

    Страницы:

    Какая аппаратура быстрее?

    Естественно, для разных задач подходят разные компьютеры. Например, компьютеры с процессором Alpha обычно быстрее своих Intel-собратьев выполняют расчеты с числами с плавающей запятой. Это значит, что вычисления, связанные с расчетами координат, решением уравнений или моделированием молекул, быстрее выполнит компьютер с процессором Alpha.

    В настоящее время процессоры Alpha широко используются в высокопроизводительных серверах от Hewlett-Packard и в других, еще более специализированных системах, таких как суперкомпьютеры Cray и Fujitsu.

    Если же речь идет о целочисленных вычислениях, пусть и достаточно громоздких, например, рендеринге, преобразовании графических объектов, 3D-визуализации, где координаты могут быть заданы только целыми числами, процессоры Intel отлично справятся с ними.

    Сейчас мы говорили о процессорах Alpha и Intel, но на деле разговор касается двух разных архитектур - RISC и CISC. Процессоры Intel традиционно тяготеют к последней, в то время как процессоры SPARC - к первой. ОС Solaris выпускается в версиях для обеих архитектур, хотя изначально компания Sun не выпускала версию Solaris для Intel, а многочисленные пользователи этой системы во всем мире до сих пор утверждают, что версия для SPARC более производительна и надежна. Это, в частности, объясняется тем, что механизмы обеспечения многозадачности тесно связаны с используемой аппаратурой, и версия Solaris под Intel "подогнана" под архитектуру процессоров Intel и архитектуру аппаратных средств, разработанных для них.

    Надо отметить отличные результаты процессора Itanium, сравнительно нового процессора Intel с 64-разрядной архитектурой, который прекрасно показал себя в тесте вычислений с плавающей запятой SPECfp2000, что выгодно отличает его от предшествовавших 32-разрядных собратьев, но менее удачно выступил в целочисленном тесте.

    В заключение разговора о предпочтительности той или иной аппаратуры следует сказать, что:

  • Для работы Solaris под серьезной нагрузкой, такой как СУБД Oracle с тысячами клиентов и важностью высокой скорости реагирования, система на базе процессоров RISC скорее всего окажется более результативной.
  • Независимо от используемой аппаратной платформы конфигурация компьютера должна быть хорошо согласована: быстрый процессор должен работать с быстрой оперативной памятью, а дисковая подсистема (контроллеры и диски ) обязана без задержек отрабатывать команды чтения и записи. Недостаточный объем кэша любого уровня - как кэша процессора на кристалле, так и кэша дискового контроллера - может привести к значительному снижению производительности.
    •
    Сравнение производительности разных систем
    Процессор, частота CPECint2000 (base) CPECfp2000 (base) Система
    Alpha21264C, 1.01 GHz 561 585 Compaq AlphaServer GS160
    Alpha21264C, 1 GHz 776 621 Compaq AlphaServer ES45
    Alpha21264B, 833 MHz 518 621 Compaq AlphaServer ES40
    Itanium, 800 MHz 379 701 HP rx4610
    Itanium, 800 MHz 358 655 HP i2000
    UltraSPARC III 1.05 GHz 537 701 Sun Blade 2050
    UltraSPARC III 900 MHz 470 629 Sun Blade 1000
    UltraSPARC III 750 MHz 363 312 Sun Blade 1000
    Power4, 1.3. GHz 790 1098 IBM eServer 690

    Оценка ситуации: программы надзора за системой

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

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

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

    Для оценки загрузки процессора и состояния памяти (достаточно ли оперативной памяти, не перегружена ли дисковая подсистема свопингом и т.п.) служат программы top и sar. Конкретные примеры применения этих программ даны ниже, в разделе "Эффективное использование памяти и свопинга ". Программа top выводит информацию о процессах, которые наиболее активно занимают процессор:

    top
last pid:  501; load averages: 0.08, 0.34, 0.40     19:12:00
59 processes: 58 sleeping, 1 on cpu
CPU states: 96.2% idle, 0.8% user, 1.0% kernel, 2.0% iowait, 0.0% swap
Memory: 128M real, 3596K free, 132M swap in use, 466M swap free
 PID USERNAME	LWP	PRI	NICE	SIZE	RES	STATE	TIME	CPU	COMMAND
 345 root 	1	59	0	24M	9972K	sleep	0:11	1.14%	Xsun
 470 root 	4	49	0	128M	71M	sleep	0:52	1.01%	soffice.bin
 501 root 	1	59	0	2228K	1336K	cpu	0:00	0.55%	top
 461 root 	1	59	0	15M	3184K	sleep	0:00	0.37%	dtterm
 467 root 	1	49	0	4708K	832K	sleep	0:00	0.00%	bash
 435 root 	1	49	0	16M	1760K	sleep	0:00	0.00%	dtfile
 434 root 	5	59	0	22M	6304K	sleep	0:01	0.00%	dtwm
 427 root 	1	49	0	18M	0K	sleep	0:00	0.00%	dtsession
 436 root 	1	59	0	14M	3292K	sleep	0:00	0.00%	sdtperfmeter
 265 root 	26	59	0	5480K	1456K	sleep	0:00	0.00%	htt_server
 460 root 	1	59	0	3064K	1372K	sleep	0:00	0.00%	dtexec
 315 root 	1	59	0	6900K	1324K	sleep	0:00	0.00%	dtlogin
 411 root 	1	59	0	3784K	1300K	sleep	0:00	0.00%	sdt_shell
 183 root 	3	59	0	5832K	1188K	sleep	0:00	0.00%	automountd
 195 root 	13	59	0	5660K	1100K	sleep	0:00	0.00%	syslogd

    Программа sar подобна vmstat и выдает статистику по работе системы, ее можно запустить для выдачи определенных параметров одномоментно или для периодического вывода сведений, например, для десятикратного измерения значений стандартного набора параметров с периодом 5 секунд:

    sar 5 10
SunOS sunny 5.9 Generic_112234-03 i86pc  07/03/2004
19:12:34	%usr	%sys	%wio	%idle
19:12:39 	0 	1 	0	99
19:12:44 	0 	0 	0	100
19:12:49 	0 	1 	0	99
19:12:54 	4 	1 	0	95
19:12:59 	0 	0 	0	100
19:13:04 	0 	1 	0	99
19:13:09 	5 	1 	0	94
19:13:14 	1 	24 	66 	8
19:13:19 	2 	35 	38 	25
19:13:24 	3 	20 	17 	60

    Решение проблем:изменение размеров разделов диска

    Если необходимо увеличить размер конкретного раздела, то есть два пути: физически изменить размер раздела или создать метаустройство, которое физически будет состоять из нескольких разделов на одном или нескольких дисках, но система будет его считать одним логическим разделом. Второй путь напоминает создание Volume Set в системах Windows.

    Чтобы физически изменить размер раздела, надо, чтобы на диске вслед за этим разделом было свободное пространство, еще не отданное ни одному разделу. Если там есть какой-то другой раздел, то его придется удалить, предварительно сохранив нужные данные из него. После этого потребуется выполнить резервное копирование всех данных увеличиваемого раздела в какой-то каталог другого раздела, удалить старый раздел, создать на его месте новый, больший, с помощью команды newfs, и затем восстановить файлы из резервной копии. Этот метод рекомендован для использования в любых системах UNIX. Однако он требует значительных затрат времени и дискового (или ленточного, в зависимости от того, где вы создаете резервную копию) пространства.

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

    Синтаксис команды growfs:

    /usr/sbin/growfs 	[-M точка_монтирования] [параметры_newfs]
[rawdevice]

    Аргументы команды growfs обозначают:

  • точка_монтирования - точка монтирования файлововй системы, которую требуется расширить. При этом на время расширения произойдет блокировка файловой системы функцией lockfs().
  • параметры_newfs - те же параметры, которые может принимать программа newfs при создании новой файловой системы, см. описание newfs.
  • rawdevice - имя файла прямого доступа для метаустройства в каталоге /dev/md/rdsk.
  • Команда growfs увеличивает размер файловой системы до размера указанного раздела.
    •

    Увеличение размера раздела выполняется посредством добавления нового раздела к метаустройству и последущего запуска growfs. При увеличении размера зеркала (т.е. уже существующего метаустройства с реализованным зеркалированием, или, иначе говоря, с RAID уровня 1) следует вначале увеличить каждую из частей зеркала с помощью metaattach, как показано ниже, а затем - всю файловую систему с помощью growfs.

    Особым случаем является расширение журналируемого метаустройства (trans metadevice), которое состоит из двух устройств - главного и журналирующего. Увеличивается только размер главного устройства, а затем growfs "напускается" на само журналируемое метаустройство. Вообще говоря, можно увеличить и размер журналирующего устройства, но это не является обязательным.

    Програма growfs на время модификации файловой системы блокирует запись в нее. Можно сократить время блокировки файловой системы, выполняя ее увеличение по частям. Например, мы хотим увеличить файловую систему размером 2 Гбайт до размера 8 Гбайт. Можно это делать поэтапно, добавляя по 16 Мбайт за этап, дав ключ s для явного указания размера общего размера новой файловой системы на каждом этапе. Число, следующее за ключом s, интерпретируется как общее число секторов новой файловой системы на каждом этапе и должно быть кратно размеру цилиндра в секторах. Иначе говоря, файловая система должна содержать целое число цилиндров.

    Подробнее об ограничениях, связанных с размером разделов, рассказано в руководстве по newfs и growfs.

    Представим себе, что требуется увеличить размер раздела /dev/dsk/c1t0d0s3, на котором расположена файловая система /export. Для этого нам потребуется вначале преобразовать этот раздел в метаустройство, поскольку добавлять дополнительное пространство можно только к метаустройству. Допустим, добавлять к существующему разделу мы будем пока еще пустой, не содержащий файловой системы раздел /dev/dsk/c2t0d0s3:

    metainit -f d8 2 1 c1t0d0s3 1 c2t0d0s3

    Эта команда вызывает объединение разделов /dev/dsk/c1t0d0s3 и /dev/dsk/c2t0d0s3 в новое метаустройство d8. Теперь изменяем /etc/vfstab так, чтобы файловая система /export монтировалась на метаустройство d8:

    #device 	device	mount	FS	fsck	mount	mount
#to mount 	to fsck	point	type	pass	at boot	options
/dev/md/dsk/d8	/dev/md/dsk/d8	/export	ufs	2	yes	-

    Демонтируем /export и снова монтируем его (при монтировании будет использовано новое устройство из /etc/vfstab ):

    umount /export
mount /export

    Запускаем growfs для расширения файловой системы на новый раздел:

    growfs -M /export/dev/md/rdsk/d8

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

    Файл /etc/lvm/md.tab содержит таблицу метаустройств, которая служит файлом настроек для запуска программы metainit при старте системы.

    Ограничения при работе с growfs

    С помощью growfs можно расширять только файловые системы UFS (не важно, смонтированные они или несмонтированные). Расширенная файловая система не может быть уменьшена. Расширение файловой системы невозможно, если:

  • на задействованном в ней устройстве находится файл учета запущенной системы acct, или
  • включена система безопасности на уровне C2 и файл журналирования находится на расширяемом устройстве, или
  • на ней находится локальный файл свопинга, или
  • эта файловая система монтируется в каталог /usr или корневой каталог или является активным разделом свопинга.
    •

    Увеличение производительности дисковой подсистемы

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

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

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

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

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

    Снижение частоты синхронизации файлового кэша с диском

    При частых и объемных операциях с файлами, файловый кэш быстро заполняет значительный объем памяти. В системах Solaris до версии 8 он даже конкурировал с процессами за оперативную память. Процесс fsflush регулярно (по умолчанию - раз в 30 секунд) "сбрасывает" на диск содержимое кэша, обеспечивая таким образом синхронизацию кэша и файловой системы. Если количество открытых файлов велико, эта синхронизация может приводить и к потерям времени и к чересчур высокой загрузке дисковой подсистемы.

    Демон fsflush руководствуется значением двух переменных, squid и tune_t_fsflushr, - значение им можно присвоить в файле /etc/system. Для систем с большим объемом памяти установленное по умолчанию значение squid в 30 с делает процесс fsflush чересчур дорогостоящим.

    Для того чтобы поубавить аппетит fsflush, время цикла синхронизации следует увеличить, изменив в большую сторону значение squid. Поскольку fsflush оказывает влияние на всю систему, лучше всего, чтобы он работал в течение более коротких промежутков времени. Для этого значение tune_t_fsflushr (время, отведенное fsflush на синхронизацию) должно быть меньше: выделив демону меньшее число секунд, вы заставите его выполнять меньшую по объему запись.

    Приостановка записи (write throttle) в файловой системе UFS

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

    Переменная ядра ufs:ufs_WRITES отвечает за включение механизма write throttling (приостановки записи в файл). Если эта переменная равна 1, то приостановка записи разрешена. По умолчанию это именно так.

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

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

    Такое увеличение вполне допустимо и даже полезно при использовании метаустройств с расщеплением (striping metadevices), когда данные одного файла поблочно пишутся на несколько устройств одновременно (первый блок - на первый диск, следующий - на второй и т.д.), так как совокупная пропускная способность метаустройства выше, чем у одного физического диска. То же относится и к массивам RAID. Значения ufs:ufs_LW и ufs:ufs_HW не должны быть слишком близкими, но и не должны очень сильно отличаться. Если они слишком близки, то приостановки записи будут случаться очень часто: как только объем буфера окажется у нижнего предела и запись будет разрешена, буфер сразу превысит верхний предел и запись приостановится. Большая разница между значениями приведет к тому, что запись в файл будет заблокирована при превышении верхнего предела, и после этого пройдет значительное время до разблокировки записи, так как буфер не может быть мгновенно "сброшен" на диск, и до достижения нижнего предела придется ждать относительно долго.

    Рекомендуется нижний предел устанавливать равным 1/32 объема оперативной памяти, а верхний - 1/16 этого объема.

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

    Кэш поиска имен каталогов (DNLC)

    Чтобы не искать номер индексного дескриптора по имени файла каждый раз, когда к файлу происходит обращение, система кэширует имена файлов и каталогов вместе с номерами их виртуальных индексных дескрипторов. Этот специальный кэш называется кэш поиска имен каталогов (directory name lookup cache - DNLC).

    При открытии файла DNLC вычисляет соответствующий индексный дескриптор по имени этого файла. Если имя уже находится в кэше, то оно отыскивается очень быстро, поскольку не происходит сканирования каталогов на диске. Каждая запись DNLC в ранних версиях системы имела фиксированный размер, поэтому пространство для имени файла не могло превышать 30 символов, а более длинные имена файлов не кэшировались. Начиная с Solaris 7, это ограничение снято. Если каталог содержит несколько тысяч записей, поиск номера индексного дескриптора конкретного файла отнимет много времени. В том случае, когда в системе открыто много файлов, а количество файлов в рабочих каталогах велико, высокая частота успешных обращений к DNLC очень важна.

    Кэш имен каталогов не нуждается в настройке, хотя его размер зависит от значения maxusers. По умолчанию он определяется как (17x maxusers )+90 (в Solaris 2.5.1) или 4x( maxusers + max_nprocs )+320 (в Solaris 2.6 и выше). Другие параметры, на которые тоже оказывает влияние maxusers, обсуждены в лекции 10.

    Команда

    vmstat -s

    показывает частоту успешных попаданий в DNLC с момента начала работы системы.

    Если частота промахов велика (попаданий обычно не должно быть меньше 90%), следует подумать об увеличении размера DNLC. Проверим этот показатель работы системы командой

    vmstat -s |grep 'name lookups'
	422920 total name lookups (cache hits 99%)

    Количество запросов к DNLC в секунду можно получить из поля namei/s в выводе команды sar -a:

    sar -a  1 5 
SunOS sunny 5.9 Generic_112234-03 i86pc  07/03/2004
19:26:50 	iget/s 	namei/s 	dirbk/s
19:26:51	0	1	0
19:26:52 	0 	0 	0
19:26:53 	0 	0 	0
19:26:54 	0 	4 	0
19:26:55 	0 	0 	0

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

    find / -name "top" 
[1] 577
sar -a 1 5
SunOS sunny 5.9 Generic_112234-03 i86pc  07/03/2004
19:27:14 	iget/s 	namei/s 	dirbk/s
19:27:15  	1675  	2592  	1922
19:27:16  	1220  	2365  	1474
19:27:17   	968  	1882  	1172
19:27:18  	1057  	2107  	1292
19:27:19  	1231  	2211  	1443
vmstat -s |grep 'name lookups'
  503370 total name lookups (cache hits 86%)

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

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

    Как уже обсуждалось в лекциях 5 и 6, при создании файловой системы для индексных дескрипторов выделяется отдельное пространство на разделе. Индексные дескрипторы хранят свойства файла, в том числе теневые индексные дескрипторы - расширенные права доступа. Количество индексных дескрипторов - это неизменяемая величина. Отсутствие свободных индексных дескрипторов в файловой системе приводит к невозможности записывать файлы в те каталоги, которые расположены в этой файловой системе. Количество свободных индексных дескрипторов можно определить, проанализировав вывод команды df -e:

    df -e
Filesystem					ifree
/proc							862
/dev/dsk/c0t0d0s0 		294838
fd 							0
/dev/dsk/c0t0d0s4		246965
swap 							9796
/dev/dsk/c1t0d0s0 		3256077

    Количество одновременно записываемых блоков

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

    Количество группируемых блоков равно параметру файловой системы maxcontig . В версиях, предшествующих Solaris 8, этот параметр по умолчанию был равен семи, и, таким образом, операция ввода-вывода происходила одновременно с семью последовательными блоками и позволяла одновременно записать порцию данных размером 56 Kбайт. Такое значение по умолчанию связано с ограничениями конструкции в раннем оборудовании Sun: системы, основанные на архитектуре sun4, не способны передавать за одну операцию более 64 Kбайт. В архитектурах sun4c, sun4m, sun4d и sun4u таких ограничений нет. В Solaris 8 значение по умолчанию изменилось и составляет 16 блоков (128 Kбайт).

    Изменение параметра maxcontig может серьезно повлиять на производительность файловой системы , при работе с которой преобладают последовательные операции по записи средних и больших (более нескольких десятков килобайт) файлов на диск. Если при доступе к файловой системе большинство операций ввода-вывода совершается с данными малого размера, то изменение maxcontig не принесет особой пользы.

    Размер кластера файловой системы задается с помощью ключа -С blocks команды newfs при создании файловой системы. Для существующей файловой системы его можно изменить с помощью ключа -a команды tunefs.

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

    Настройка параметров файловой системы

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

    iostat -x 5

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

    ...
device 	r/s 	w/s 	kr/s  	kw/s 	wait 	actv 	svc_t 	%w 	%b 
cmdk0 	17.6 	2.9 	138.4 	53.1 	1.1 	0.2 	60.1 	3 	13
fd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
sd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
nfs1 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	9.3  	0  	0
		extended device statistics 
device 	r/s 	w/s 	kr/s  	kw/s 	wait 	actv 	svc_t 	%w 	%b 
cmdk0   307.7  0.2 766.1  2.0 0.0 0.9  2.9  0 89 
fd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
sd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
nfs1 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
		extended device statistics 
device 	r/s 	w/s 	kr/s  	kw/s 	wait 	actv 	svc_t 	%w 	%b 
cmdk0   253.4  0.7 768.0  6.0 0.0 0.9  3.6  0 88 
fd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
sd0 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
nfs1 	0.0  	0.0  	0.0  	0.0 	0.0 	0.0  	0.0  	0  	0
...

    Средние значения загрузки можно получить из колонок kr/s и kw/s, в более ранних версиях системы для получения таких значений приходилось делить содержимое колонок "K/r" и "K/w" на "r/s" и "w/s" соответственно для получения средних показателей "прочитано килобайт в секунду" и "записано килобайт в секунду".

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

    quot -c file_system

    Например, вот каково распределение в моей тестовой системе:

    quot -c /export/home
...
1128 	1 	165156
1136 	1 	166292
1160 	1 	167452
1176 	1 	168628
1184 	1 	169812
1192 	1 	171004
1224  	1 	172228
1232 	1 	173460
1240 	1 	174700
1264 	1 	175964
1360 	1 	177324
1376 	1 	178700
1440 	1 	180140
1488 	1 	181628
1536 	1 	183164
1608 	1 	184772
1648 	1 	186420
1704 	1 	188124
1768 	1 	189892
1792 	1 	191684
1832 	1 	193516
2047 	40 	437396
...

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

    Эффективное использование памяти и свопинга

    Вопрос об установке в систему дополнительной оперативной памяти представляет собой классический вопрос выбора между ценой и производительностью. Если цена важнее производительности, то при нехватке памяти увеличивают размер раздела свопинга, если важнее производительность - увеличивают объем оперативной памяти. Если же нет возможности сделать ни то ни другое, новые процессы не смогут быть запущены при нехватке виртуальной памяти (это можно заметить по сообщениям "Not enough space" или "WARNING: /tmp: File system full, swap space limit exceeded").

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

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

    При этом высокая активность может быть временной или постоянной. В любом случае, имеет смысл уяснить ее причину.

    Частота сканирования страниц

    Повышенная частота сканирования страниц (scan rate) - главный показатель того, что в системе перестало хватать оперативной памяти. Для просмотра значения scan rate используйте команды

    sar -g

    или

    vmstat

    При анализе частоты сканирования с помощью vmstat имеет смысл запустить эту программу с параметром 60 для получения статистики каждые 60 секунд:

    vmstat 60
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr cd f0 s0 -- in sy cs us sy id
0 0 0 482100 7288 23 63 126 31 46 8 54 28 0 0 0 333 1519 327 5 11 84
0 1 0 470816 2060 0 26 1 51 103 0 123 240 0 0 0 960 969 649 4 92 4
...

    Первую строку (суммарную статистику) можно игнорировать. Если показатель page/sr остается выше 200 страниц в секунду в течение длительного времени, это говорит о вероятной нехватке оперативной памяти в системе.

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

    Активность свопинга

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

    iostat -xPnce

    для получения информации об активности передачи данных в/из конкретных разделов дисков, в Solaris 2.5.1 доступна команда

    iostat -xc

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

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

    Можно также использовать

    sar -d

    или

    vmstat

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

    Использование памяти процессами

    В системах Solaris, начиная с версии 2.6, есть возможность выяснить, какие программы сколько памяти занимают (и подробнее - размеры сегментов данных, кода и т.п.) с помощью программы pmap.

    Для получения детальной информации дайте команду

    /usr/proc/bin/pmap -x PID

    Информация о размере процесса в оперативной памяти также содержится в колонке RSS вывода программ top и ps (используйте ps -ly ).

    В пакете SunPro есть отладчик dbx, который помогает находить источник утечки памяти в программе; для такой работы следует компилировать программу компилятором SunPro с ключом -g.

    Статистику использования разделяемой памяти вы получите по команде

    ipcs -mb

    Эти программы следует использовать для определения размера процессов и основных потребителей памяти в системе.

    Размер пространства свопинга

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

    Для управления пространством свопинга (получения информации о нем, добавления и удаления разделов свопинга ) используется программа swap. Получить информацию о текущем состоянии пространства свопинга можно с помощью swap -l.

    Для выяснения общего объема виртуальной памяти, который включает в себя объем оперативной памяти и пространства свопинга вместе, следует использовать swap -s или sar -r.

    Если своп-раздел смонтирован в /tmp как файловая система типа tmpfs, команда

    df -k /tmp

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

    Алгоритм пейджинга

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

    Параметры ядра и пейджинг

    physmem: общее количество страниц в оперативной памяти.

    lotsfree: сканер страниц начинает работать, когда количество свободной оперативной памяти становится меньше lotsfree.

    Значение по умолчанию - physmem/64, но оно может быть изменено в /etc/system. Сканер страниц по умолчанию запускается в режиме пейджинга. Частота сканирования ( scan rate, столбик sr в выводе vmstat ) устанавливается равной параметру slowscan , который по умолчанию равен fastscan/10.

    minfree: пока объем свободной памяти находится между lotsfree и minfree, частота сканирования страниц растет линейно от slowscan к fastscan по мере уменьшения размера свободной памяти (рис. 20.1). Значение minfree по умолчанию - desfree/2, значение fastscan по умолчанию - physmem/4. Если свободной памяти становится меньше, чем desfree (что по умолчанию равно lotsfree/2 ), сканер страниц начинает запускаться с частотой 100 раз в секунду. За каждый свой запуск сканер страниц проверяет desscan страниц. Этот параметр изменяется динамически вместе с частотой сканирования.

    maxpgio: этот параметр (в зависимости от конкретной аппаратуры он имеет значение 40 или 60) по умолчанию ограничивает частоту ввода-вывода на устройство пейджинга. Для современных дисков с частотой вращения больше 7200 оборотов в минуту можно установить значение maxpgio в сто раз больше количества жестких дисков, задействованных в свопинге.

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

    cachefree: имеет значение для систем Solaris 7 (или систем 2.5.1 и 2.6 с установленными самыми свежими обновлениями); если в этих системах параметр priority_paging установлен равным 1 (т.е. priority paging включен), то пока свободной памяти больше, чем lotsfree, освобождаются только страницы файлового кэша в памяти, а страницы процессов не затрагиваются. Значение по умолчанию - удвоенное lotsfree. Системы Solaris более поздних версий, начиная с 8-й, имеют другой алгоритм освобождения оперативной памяти, и в них НЕ следует включать priority paging и устанавливать значение cachefree.

    В системах Solaris до версии 7 включительно сканер страниц работает так: для выбранных сканером страниц обнуляется флаг "используемости" страницы, выбор страниц происходит со скоростью, которую можно посмотреть с помощью vmstat или sar -g (scan rate). После обработки handspreadpages страниц сканер проверяет, установлен ли флаг "используемости". Фактически, сканер состоит из двух процессов, один из которых идет по памяти и очищает флаги встреченных страниц, а второй следует за ним на некотором расстоянии и проверяет,не было ли новых обращений к этой странице (не установился ли снова этот флаг). Если флаг не установлен (обращений к странице за то время, пока сканер отмечал handspreadpages страниц, не произошло), то страница отправляется в своп. Параметр handspreadpages по умолчанию равен physmem/4.

    (рис 17.1) Зависимость частоты запуска сканера страниц от объема свободной памяти

    В системах Solaris 8 и более новых алгоритм освобождения памяти иной (он называется cyclical page cache ). Он рассчитан на то, что при нехватке памяти выгружаются прежде всего страницы файлового кэша, и только затем - страницы процессов. Этот алгоритм разработан для тех же целей, что и priority paging в Solaris 7. Новый алгоритм использует два списка свободных страниц. Один - для помещения в него освобождающихся страниц файлового кэша, другой - для помещения прочих освобождающихся страниц (разделяемой памяти, процессов и т.п.). При таком подходе файловый кэш ни с кем не соперничает за место в памяти.

    В результате этих изменений в системах Solaris, начиная с версии 8, vmstat сообщает иные цифры, чем в той же ситуации в более старых системах, а именно:

  • скорость возврата страниц выше;
  • весь файловый кэш показывается как свободная память ;
  • скорость сканирования страниц (scan rate) низкая (даже близка к нулю), за исключением ситуаций, когда в системе ощущается острая нехватка памяти для приложений.
    •

    Для получения отдельного отчета по пейджингу страниц приложений (executables), данных (anonymous) и файловой системы используйте команду

    vmstat -p

    Свопинг

    Если системе в течение некоторого времени (обычно 30 секунд подряд) не хватает памяти (объем свободной оперативной памяти падает ниже desfree ), то начинается свопинг процессов. Планировщик задач выгружает те процессы, которые не претендовали на процессорное время в течение более чем maxslp секунд. По умолчанию maxslp равно 20. Этот режим свопинга называется мягким.

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

    Не выгружаются:

  • процессы классов планирования SYS и RT;
  • процессы, запускаемые в данный момент или остановленные по сигналу (например, при отладке);
  • процессы, завершающие работу;
  • процессы, находящиеся в состоянии зомби;
  • системные потоки;
  • процессы, которые блокируют другие, более высокоприоритетные потоки.
    •

    Ввод-вывод без кэша

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

    Для этого можно использовать функцию directio() или параметр forcedirectio при монтировании файловой системы командой mount. Файловая система VxFS включает ввод-вывод в обход кэша всегда, когда объем операции ввода-вывода превышает значение параметра discovered_direct_iosz (см. man vxtunefs ) (по умолчанию - 256 Kбайт).

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

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^