Управление пулами ресурсов. Проекты. Зоны и контейнеры

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

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

Отметим, что при использовании файловой системы ZFS в Solaris задачи расширения объема файловой системы решаются проще – добавлением нового устройства или раздела в пул; после этого все файловые системы, размещенные в этом пуле, могут пользоваться появившимся пространством. Ниже описанные процедуры более актуальны для использования более старой файловой системы UFS.

Чтобы физически изменить размер раздела, надо, чтобы на диске вслед за этим разделом было свободное пространство, еще не отданное ни одному разделу. Если там есть какой-то другой раздел, то его придется удалить, предварительно сохранив нужные данные, которые в нем находятся. После этого потребуется выполнить резервное копирование всех данных увеличиваемого раздела в какой-то каталог другого раздела, удалить старый раздел, создать на его месте новый, больший, с помощью команды 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 руководствуется значением двух переменных, autoup и tune_t_fsflushr, – значение им можно присвоить в файле /etc/system.

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда

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%)

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

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

При создании файловой системы для индексных дескрипторов выделяется отдельное пространство на разделе. Индексные дескрипторы хранят свойства файла, в том числе теневые индексные дескрипторы – расширенные права доступа. Количество индексных дескрипторов – это неизменяемая величина. Отсутствие свободных индексных дескрипторов в файловой системе приводит к невозможности записывать файлы в те каталоги, которые расположены в этой файловой системе. Количество свободных индексных дескрипторов можно определить, проанализировав вывод команды 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 KB. Такое значение по умолчанию связано с ограничениями конструкции в раннем оборудовании Sun: системы, основанные на архитектуре sun4, не способны передавать за одну операцию более 64 KB. В архитектурах sun4c, sun4m, sun4d и sun4u таких ограничений нет. В Solaris 8 значение по умолчанию изменилось и составляет 16 блоков (128 Kb).

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

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

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