Утилизация диска что это

Опубликовано: 19.05.2024

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

Диски необходимо утилизировать надежно.

Дискеты

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

CD-ROM

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

Жесткие диски

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

выбытие

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

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

await (await) - Среднее время ожидания обработки одного запроса (миллисекунды). Время нахождение и на обработку в очереди - всключено.
read await (r_await) - Среднее время (в миллисекундах) обработки запроса на чтение. Время нахождение и на обработку в очереди - всключено.
write await (w_await) - Среднее время (в миллисекундах) обработки запроса на запись. Время нахождение и на обработку в очереди - всключено.

Состояние очереди

Позволяет оценить характер нагрузки и степень загруженности устройства.

average queue size (avgqu-sz) - средняя длина очереди запросов в драйвере диска.
average requests size (avgrq-sz) - средний размер запроса (в секторах).

Вывод:
avgqu-sz - должна стремится к нулю если стабильно больше 1 то очевидно диск не справляется.
avgrq-sz - говорит лишь о харрактере нагрузки.

Операции слияния в очереди

Количество запросов чтения/записи (в секунду) объединенных при постановке в очередь на выполнение.
Число запросов, которые приложения запросили выполнить,а система смогла их объединить в блоки в среднем по avgrq-sz байт, для экономии.

write requests merge per second (wrqm/s) - IOPs на запись в очереди
read requests merge per second (rrqm/s)- IOPs на чтение в очереди

Вывод:
Принципы использования диска.
Random Access - когда чтение поверхности случайно, для него харрактерено: r/s,w/s начнут стремиться к rrqm/s и wrqm/s, и avgrq-sz падать. Естественно при таком сценаррии, диск HDD будет тормозить.
Sequential Access - когда чтение последовательно, для него харрактерно rrqm/s и wrqm/s стремится к 0, avgrq-sz растет. При таком сценарии, HDD диск будет работать с максимальным КПД.

Текущие значения чтения/записи на устройство

Текущая скорость чтения/записи на устройство в килобайтах

read from device per second (rkB/s) - Колличество киллобайт прочитанных с устройства в секунду.
written to the device per second (wkB/s) - Колличество киллобайт записанных на устройство в секунду.

Утилизация блочного устройства

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

utilization (%util) - утилизация винта общая нагрузка на устройство.
write operations per second (w/s) - IOPs на запись.
read operations per second (r/s) - IOPs на чтение.

Перевод ComssПо материалам Windows Secrets

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

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

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

Современные жесткие диски являются потомками массивных устройств с небольшим количеством памяти, созданные в 1960-х годах компанией IBM для своих компьютерных систем. Согласно информации из Википедии, первые жесткие диски имели размер двух холодильников и вмешали 3,75 мегабайт данных.

С конца 1950-х и до рубежа тысячелетий фундаментальная конструкция жестких дисков оставалась практически неизменной. Данные хранились на магнитных дисках или пластинах, - которые отдаленно напоминают грампластинки. Эти пластины вращаются со скоростью от 5400 до 15000 оборотов в минуту, в зависимости от модели винчестера. Для сравнения виниловые пластинки вращались со скоростью 33,3 или 45 оборотов в минуту.

В 2000 году технология создания дисков была серьезно пересмотрена: Trek Technology и IBM стали продавать накопители, которые использовали чипы silicon power вместо вращающихся магнитных пластин. Новые устройства использовали медленный, но относительно недорогой вид энергонезависимой и перезаписываемой оперативной памяти.

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

В течение последующего десятилетия хранилища данных могут снова радикально поменяться. Согласно исследованиям, “диски”, построенные на углеродных нанотрубках (CNT) могут заменить как оперативную память, так и хранилища данных в персональных компьютерах, планшетах и смартфонах.

Особенности технологии хранения информации на твердотельных дисках

Технология создания твердотельных дисков для замены вращающихся носителей должна была имитировать HDD для ОС Windows и для компьютерного оборудования (например, использовать стандарта SATA для подключения). Microsoft на протяжении 30 лет разрабатывала код, оптимизированный для работы с вращающимися дисками. Для адаптации системы и приложений к поддержке новых SSD потребовалось бы еще несколько лет работы. Адаптация к другой новой технологии хранения данных может означать еще одну массивную кампанию по замене внутреннего кода.

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

Так называемая выравнивающая программа (wear leveling) отслеживает количество циклов перезаписи каждой ячейки памяти. Когда конкретная ячейка памяти становится изношенной, программа автоматически переносит данные в другое местоположение, характеризующееся лучшим состоянием. Это означает, что встроенный компьютер устройства содержит собственную таблицу перевода адресов, потому что Windows по-прежнему думает, что данные хранятся по адресу, указанному в “Главной файловой таблице” (Master File Table).

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

Обратите внимание, что эти “кусочки” могут содержать данные, которые ОС считает надежно удаленными. Другими словами, в отличие от обычных жестких дисков, SSD диски не соблюдают условия, необходимые для полного удаления данных. При использовании специализированных приложений для восстановления данных, пользователь сможет восстановить биты файлов, которые якобы были стерты.

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

Это очень важно знать, потому что программы для очистки и защищенного удаления данных имеют доступ только к переведенным адресам HDD. Приложения не могут получить доступ к данным, сохраненным в адресном пространстве SSD.

Приведем пример. Допустим, Вы используете компьютер с SSD диском, емкостью 1 терабайт. В окне свойств системы Windows отображается значение 1 терабайт. Тем не менее, твердотельный накопитель имеет еще 10-процентный запас пространства хранения для компенсации возможного отказа микросхемы. Со временем интегрированная программа для оптимизации износа перераспределяет данные между микросхемами диска. Когда придет время отказаться от эксплуатации диска, утилита очистки сотрет только 1 терабайт данных, видимый ОС, а оставшиеся 10 процентов останутся незатронутыми. Эти 100 гигабайт могут хранить приличное количество данных.

Эффективный способ обезопасить снятые с эксплуатации диски

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

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

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

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

Microsoft включает специализированное ПО для шифрования данных BitLocker в ОС Windows Pro, Enterprise и Ultimate. Программа работает с SSD накопителями, жесткими дисками и USB-флешками. Если на системе, использующей выводящийся из эксплуатации диск, не установлен BitLocker, Вы можете вытащить диск и подключить его как переносной носитель к системе, которая поддерживает систему шифрования от Microsoft.

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

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

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

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

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

Несколько интересных фактов об SSD и жестких дисках

Если Вы храните очень важные конфиденциальные данные на вашем ноутбуке, SecureDrives предлагает твердотельный накопитель с SED и функцией автоматического уничтожения. Накопитель имеет собственный GSM-модуль. В случае потери или кражи компьютера, Вы просто отправляете СМС-сообщение на диск. Кроме того, можно настроить саморазрушение, если он не может получить сообщение или с помощью других средств. Как и в фильмах про Джеймса Бонда, диск самоликвидируется с помощью воздействия на микросхемы памяти ультразвуковой ударной волны;

Данные хранятся на вращающимся диске в концентрических кругах, называемых дорожками. От 60 до 100 треков обычного винчестера вписываются в ширину человеческого волоса;

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

Стандарты министерства обороны США регламентируют не менее 3 циклов перезаписи для безопасного удаления данных. На современных HDD и SSD даже один цикл перезаписи приводит к уничтожению данных;

Новые диски хранят биты в перекрывающихся дорожках, подобно кровельной черепице. Технология называется черепичная магнитная запись (Shingled Magnetic Recording);

Наружный край стандартного компьютерного диска имеет скорость в 100 миль в час;

Магнитная пластина стандартного диска имеет плотность - три триллиона битов на квадратный дюйм.

Производительность — главный показатель работоспособности системы. Не обладая необходимой производительностью, она не способна выполнять возложенные на нее задачи. И примеров тому можно привести массу: невозможность своевременно отреагировать на изменение конъюнктуры рынка из-за задержки аналитической обработки данных (OLAP), отказ в обслуживании клиента из-за перегрузки системы (процессинг), срыв сроков поставок (ERP) или подачи отчетов в фискальные органы и т. д. В результате сроки выполнения бизнес-задач могут оказаться сорванными, что в конечном итоге приведет к финансовым потерям компании.

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

Чтобы падение производительности не стало неприятным сюрпризом, ее уровень надо постоянно отслеживать и корректировать. Сделать это помогает методика управления уровнем сервиса (Service Level Management, SLM), следование которой позволяет держать в заданных рамках все показатели — не только производительности, но и готовности информационных сервисов ИС.

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

Вопросы выбора показателей производительности системы, их измерения и анализа полученных данных рассматриваются далее на примере платформы SPARC/Solaris. В заключение статьи приводится ряд рекомендаций по оптимизации ОС Solaris для повышения производительности при работе с СУБД Oracle.

КАКИХ ЦЕЛЕЙ ХОЧЕТСЯ ДОСТИЧЬ

С момента появления вычислительной техники пользователи хотят, чтобы компьютеры работали быстрее. Но всегда ли нужно идти у них на поводу? Если сервер способен обработать 10 тыс. транзакций в секунду, много это или мало? На первый взгляд для банка, у которого всего 10 тыс. клиентов, такая производительность более чем достаточна, а для оператора мобильной связи с тем же числом абонентов вроде бы маловата. Однако если в банке одновременно с интерактивным обслуживанием клиентов сотня экспертов выполняет сложные аналитические задачи с использованием тех же финансовых транзакций, то сервер автоматизированной банковской системы (АБС) может не успеть выполнить запрос на обслуживание важного клиента, что грозит потерей денег — клиент предъявит иск или просто откажется от услуг банка. Напротив, если сервер биллинговой системы оператора мобильной связи не успеет обработать детальную запись о звонке абонента (Call Detailed Record, CDR), то он имеет возможность сделать это в следующую итерацию, поскольку коммутаторы сети мобильной связи обычно хранят CDR некоторое время.

Итак, 10 тыс. транзакций в секунду — это много или мало? Ответ зависит от того, выполнение каких задач возложено на сервер и какие требования при этом предъявляются. Например, в случае АБС банка сервер должен выполнить запрос клиента на осуществление финансовой транзакции не более чем за 30 с, а для биллинговой системы оператора мобильной связи требование может выглядеть иначе — сервер должен суметь обработать за 1 мин не менее 5000 CDR.

Если требования изначально не определены, то измерение производительности системы становится бессмысленным занятием. Требования обычно фиксируются в соглашении об уровне обслуживания (Service Level Agreement, SLA). SLA — это полноценный контракт между провайдером услуг и потребителем, который в наших примерах может быть заключен между службой ИТ банка и руководством банка, отделом эксплуатации биллинговой системы и службой биллинга. Он необходим для оценки уровня услуг ИТ и обеспечения управления этим уровнем. Как правило, SLA оговаривает такие параметры, как коэффициент готовности услуги (доступность), нормативы устранения сбоев, а также показатели производительности (Key Performance Indicator, KPI).

Зафиксированные в SLA требования (Service Level Objective, SLO) говорят о том, какую производительность системы необходимо поддерживать, а KPI позволяют установить, что производительность системы находится на должном уровне. (SLO для АБС банка и биллинговой системы уже были сформулированы выше.) Кроме того, в SLO указывают, как учитывается время обработки: в частности, для финансовых транзакций — это может быть интервал времени между отправкой запроса на выполнение транзакции и получением визуального подтверждения его выполнения. Для АБС банка KPI могут быть сформулированы как доля транзакций, время обработки которых превышает определенный порог, например 28 с. Если количество подобных финансовых транзакций вышло за заданный порог, например 5%, то можно говорить о падении производительности системы и следует принять меры к ликвидации данной ситуации. Для биллинговой системы KPI формулируются проще — как минимальное число CDR, обрабатываемых за 1 мин.

ЧТО ИЗМЕРЯТЬ?

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

Кроме того, измерение параметров KPI не всегда возможно или удобно осуществлять в том виде, в каком они заданы в SLA. Обычно значение KPI зависит от производительности множества компонентов системы: сети, прикладного программного обеспечения и сервера. У каждого из данных компонентов существуют индикаторы производительности. Для сервера такими индикаторами служат загруженность процессорных мощностей, используемый объем оперативной памяти, число выполняемых процессов и др. KPI являются интегральным показателем, и зачастую формулу их расчета невозможно вывести из индикаторов производительности отдельных компонентов системы, особенно если последняя состоит из большого числа серверов, сетевых коммутаторов, дисковых массивов, коммутаторов Fibre Channel и т. д. В таком случае измеряют показатели производительности компонентов работающей системы, когда она обеспечивает требуемую производительность. Полученные значения используют как базовые (baseline) для сравнения с текущими показателями производительности компонентов при дальнейших контрольных замерах. Если конфигурация системы изменяется или претерпевает модернизацию, то определение базовых значений производится вновь.

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

Производительность (throughput) — это объем работы, который может быть выполнен за указанный промежуток времени. Число транзакций в секунду, осуществляемых системой управления базами данных (СУБД), является одним из примеров единицы измерения производительности. Максимальная производительность — объем выполненной работы за указанный промежуток времени при 100-процентной загруженности ресурсов системы. Иногда производительность путают с пропускной способностью. Пропускная способность (bandwidth) — это максимальная теоретически достижимая скорость без учета накладных расходов (overhead). Например, у шины Fast Wide SCSI пропускная способность составляет 20 Мбайт/с, а максимальная производительность — 16 Мбайт/с вследствие накладных расходов на протокол SCSI.

Время отклика (response time) — время, которое необходимо для завершения той или иной работы, например выполнения транзакции СУБД. Латентность является синонимом, но обычно используется как характеристика протоколов.

Время обслуживания (service time) — время, затрачиваемое на выполнение запроса, оно отсчитывается с момента достижения запросом начала очереди. Если система свободна и, следовательно, длина очереди запросов равна нулю, то время отклика равно времени обслуживания.

Длина очереди (queue length) — число запросов, ожидающих обслуживания. Длинные очереди увеличивают время отклика, но не влияют на время обслуживания.

Утилизация (utilization) — процент ресурсов системы, необходимых для выполнения работы, например процент времени использования процессора от общего времени работы системы.

Приведенные показатели связаны следующими формулами:

service time = utilization/throughput

queue length = throughput * response time

Так какие же параметры системы необходимо измерять? Ответ вполне очевиден: те, которые в дальнейшем помогут выявить приводящие к потере производительности «узкие» места. Как уже говорилось ранее, в любой системе имеются три компонента, где могут возникать «узкие» места, — это сеть, прикладное ПО и сервер. Для каждого из них существует свой набор показателей, на основании которых оказывается возможным выявить проблемы с производительностью. Еще раз подчеркнем, что все эти показатели попадают в одну из четырех упомянутых ранее категорий: производительность, время отклика/обслуживания, длина очереди и утилизация.

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

/usr/bin/vmstat — статистика об использовании виртуальной памяти, обмене страниц физической памяти с диском (paging) и обобщенные показатели загрузки процессоров; /usr/bin/mpstat — детальная статистика о загрузке процессоров; /usr/bin/iostat — статистика о подсистеме дискового ввода/вывода и NFS; /usr/bin/netstat — статистика о работе сетевых интерфейсов.

В других системах UNIX, берущих свое начало от AT&T System V, для отображения статистики служат аналогичные команды. Так, в HP-UX 11i v1 — это vmstat, mpstat, iostat, netstat, причем они отображают практически ту же информацию, что и команды ОС Solaris. Однако методика анализа их результатов для ОС Solaris и для HP-UX различна в связи с отличиями во внутренних структурах указанных ОС.

Поиск «узких» мест, влияющих на производительность сервера, рекомендуется начинать с анализа статистики использования памяти. Зачастую недостаток памяти ошибочно диагностируется как медленный доступ к диску или нехватка процессорной мощности. Для получения статистики применяйте команду vmstat (см. Листинг 1). В первую очередь следует обратить внимание на значения в колонке sr (scan rate). Они показывают число страниц памяти, которые ядро операционной системы просматривало в попытке найти свободную страницу. Когда указанная величина в колонке sr возрастает, одновременно увеличивается значение в колонке po (page-outs), показывающее число страниц физической памяти, выгружаемых на диск в область swap. Если такая ситуация наблюдается постоянно, то серверу не хватает памяти для выполнения задач, и из-за этого падает производительность.

При поиске «узких» мест нужно обратить внимание и на статистику загрузки процессоров. Детальную информацию можно получить с помощью команды mpstat (см. Листинг 2). Важными для анализа являются следующие показатели:

Если значения в колонке idl постоянно близки к нулю, значит, серверу не хватает процессорной мощности для выполнения задач. Обратное не всегда верно. Время, которое процессор тратит на обработку прерываний сетевого ввода/вывода (и ряда других), учитывается как idl, поскольку приоритет таких прерываний выше, чем приоритет прерываний таймера сбора статистики. В результате якобы бездействующий сервер (высокие значения idl) в действительности может быть занят обработкой сетевого трафика. Помимо описанной возможен и ряд других подобных ситуаций, когда необходимо учитывать значения приведенных показателей в комплексе, что отражено в Таблице 1. На Листинге 2 видно, что сложная вычислительная задача (idl=0) не мешает серверу справляться с нагрузкой — все остальные параметры в норме.

Аналогично командам vmstat и mpstat, внимания заслуживает только часть показателей, выдаваемых командой iostat (см. Листинг 3). К ним относятся:

kr/s - число килобайт, прочитанных с диска за секунду; kw/s - число килобайт, записанных на диск за секунду; wait - число запросов ввода/вывода, ожидающих обслуживания; wsvc_t - среднее время ожидания в очереди на обслуживание (в миллисекундах); asvc_t - среднее время обслуживания запроса на ввод/вывод (в миллисекундах).

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

К сожалению, встроенная в Solaris команда netstat выдает очень ограниченный набор информации (см. Листинг 4), на основании которой можно было бы сделать адекватные выводы о проблемах с производительностью сети. Нужно обратить внимание лишь на то, чтобы число ошибок (errs) и коллизий (colls) было близко или равнялось нулю.

Применение рассмотренных выше команд удобно при анализе функционирования одного-единственного сервера. Если же необходимо контролировать работу нескольких серверов и своевременно выявлять неполадки, то лучше воспользоваться развитыми средствами, в частности коммерческими пакетами Sun Management Center, HP OpenView или BMC PATROL.

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

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

Но прежде, чем заниматься настройками, необходимо проанализировать статистику работы СУБД. С этой целью в Oracle используются специальные системные виды (View), названия которых начинаются с v$. Эти объекты представляют внутренние структуры Oracle, где накапливается статистика. Процесс накопления статистики должен быть включен, например, с помощью команды:

alter system set timed_statistics = true;

Для облегчения получения статистики в поставку Oracle входят два сценария: utlbstat.sql и utlestat.sql. Запуск utlbstat.sql инициализирует процесс сбора статистики и создания отчета, по окончании определенного промежутка времени необходимо запустить сценарий utlestat.sql, чтобы сгенерировать отчет о работе СУБД за этот период. Результат будет помещен в файл report.txt.

Детальное рассмотрение всех параметров СУБД ORACLE, которые необходимо проанализировать для выявления «узких» мест, опять же выходит за рамки данной статьи. (Более подробную информацию можно найти по указанным в «Ресурсах Internet» ссылках.)

ЧТО ПРЕДПРИНЯТЬ?

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

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

Относительно оптимизации производительности СУБД Oracle под управлением ОС Solaris можно дать следующие общие рекомендации.

Одним из «узких» мест в работе СУБД является ввод/вывод на диски. Встроенный в ОС Solaris механизм Kernel Asynchronous I/O (KAIO) позволяет сократить накладные расходы (перемещение блоков данных из SGA Oracle в кэш файловой системы и др.) при вводе/выводе данных Oracle на диски. Но для этого необходимо, чтобы файлы данных Oracle (datafiles) располагались на так называемых устройствах непосредственного доступа (raw device) OC Solaris. Это не всегда удобно, поскольку на raw device, где хранятся datafiles Oracle, файловая система отсутствует. Устранить данное неудобство позволяет опция Quick I/O файловой системы VERITAS (стандартная файловая система UFS в ОС Solaris имеет подобную опцию — Direct I/O, но та менее эффективна), она дает тот же эффект по устранению накладных расходов, но на файловой системе VxFS. Данная опция лицензируется в составе пакета VERITAS Database Edition for Oracle.

Переключение процессора с выполнения одного процесса на другой ведет к дополнительным нежелательным задержкам. Чтобы процессы Oracle не конкурировали между собой и с другими процессами, в многопроцессорной системе рекомендуется назначить им конкретные процессоров или группу процессоров, посредством команды pbind или psrset. Для более гибкого распределения вычислительных ресурсов сервера между процессами и управления ими рекомендуется воспользоваться программным средством Resource Manager, входящим в состав Solaris 9 OE.

Серверы Sun Fire моделей от F3800 до 15K имеют разные уровни латентности между компонентами. Это означает, что при доступе процессора к памяти, находящейся на другой процессорной плате, времени тратится больше, чем при доступе к памяти, размещенной на той же плате, что и сам процессор (практически архитектура NUMA). Часть процессов Oracle имеет свою «внутреннюю» память, и при этом все обращаются к общей — SGA. Чтобы оптимизировать процесс обращения к памяти, в Solaris 9 была включена функция Memory Placement Option. Эта опция в полном объеме работает для указанных серверов, начиная с редакции Solaris 9 12/02 OE. По возможности, рекомендуется использовать Solaris 9 названной или более поздней редакции. СУБД Oracle 9i «умеет» пользоваться данной опцией.

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

Для начала определимся с терминологией. Есть несколько терминов и аббревиатур близких по смыслу: СХД, дисковый массив, SAN, Storage Array или просто Storage. Попробую внести ясность.

SAN — Storage Area Network или сеть хранения данных, это совокупность оборудования осуществляющая передачу трафика между сервером и системой хранения данных.

СХД — система хранения данных или дисковый массив, оборудование на котором хранятся данные с возможностью оперативного доступа. Есть еще архивные хранилища, но здесь мы их рассматривать не будем. Аббревиатура СХД так же может употребляться как сокращение от сеть хранения данных, но среди русскоговорящих специалистов термин СХД закрепился именно за системой хранения данных.

СХД могут обеспечивать два способа доступа к данным:

Блочный доступ, операционная система сервера работает с СХД как с SCSI жестким диском (упрощенно).
Файловый доступ, операционная система сервера работает с СХД как с файловым хранилищем по протоколу NFS, SMB и тд.

Для оценки производительности СХД используют три основные метрики

Service Time, часто именуемый latency или responce time, измеряется в миллисекундах и обозначает:
- при чтении: время с момента получения СХД задания на чтение блока информации до отправки запрошенной информации.
- при записи: время с момента получения записываемого блока информации до подтверждения о его успешной записи.
IO/s — количество операций ввода вывода в секунду.
MB/s — количество переданных мегабайт в секунду.

Рассмотрим наиболее типичные проявления проблем производительности СХД по показателям Service Time, IO/s и MB/s.

Повышенный Service Time

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

Для примера, ниже графики зависимости Service Time от IOPS для двух конфигураций СХД.

ST для All flash СХД, 2 Node, 24x1.9 TB SSD, RAID 5, Random 32k, 50/50 Read/Write.

ST для классического СХД, 2 Node, 24x1.8 TB HDD, RAID 5, Random 32k, 50/50 Read/Write.

В общих случаях для All Flash СХД приемлемым считается Service time меньше 1ms, а для классических СХД до 20ms. Порог приемлемого Service time зависит от числа контроллеров, скорости дисков и конечно модели самой СХД, и может отличаться от приведенных значений.
Также нужно учитывать до какого уровня задержек дисковой подсистемы сохраняется нормальная работоспособность приложения, и всегда иметь необходимый запас.

Планка по MB/s

Чаще всего свидетельствует об исчерпании пропускной способности канала или FC адаптера.

Конкурирующие значения по MB/s или IO/s

Сумма (оранжевый график) двух или более параметров на отрезке времени имеет константу и не превышает ее в какой-либо момент. Такая ситуация может наблюдаться в случае конкуренции за пропускную способность канала или порта СХД.

Понижение IO при возрастании ST

В случае если процентное распределение размеров блока не изменилось, но при этом ST начинает повышаться, а IO падать, это может свидетельствовать об аппаратных проблемах с СХД, деградации одного из контроллеров или высокой утилизации CPU.

Утилизация CPU

Утилизация CPU контроллеров СХД в общих случаях не должна превышать 70%, если она постоянно выше 70%, то это свидетельствует об отсутствии запаса производительности СХД.
Тут нужно отметить, что СХД можно разделить на две большие группы:

С использованием ASIC, в таких СХД передача данных внутри массива обрабатывается отдельным высокопроизводительным чипом, а CPU остаются сервисные задачи, такие как создание и удаление дисков и снапшотов, сбор статистики и тд.
Без использования ASIC, в таких СХД все задачи выполняет CPU.

Медленный рост IO на чтение

Такая проблема может наблюдаться в случае если СХД использует тиринг размещения данных между носителями разной скорости (например, SSD и NL SATA).

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

Какой характер нагрузки не свидетельствует о проблемах?

Пилообразный график IO

Скачки по MB

Прыгающие значения IO

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

Как определить трешхолды для Service Time, IO/s и MB/s?

Данные параметры можно рассчитать теоретически, складывая производительность дисков и считая пенальти выбранного уровня RAID, также можно воспользоваться сайзерами при наличие оных, но расчет будет очень приблизительным, поскольку не будет учитываться реальный профиль нагрузки. Для определения точных пороговых значений, свидетельствующих например о 90% загрузке СХД, необходимо провести нагрузочное тестирование при помощи специального ПО, сформировав профиль нагрузки близкий к реальному и замерить максимальные значения IO/s и MB/s. Но как быть с Service Time? Тут зависимость нелинейная. Для определения Service Time соответствующего 90% загрузке нужно просто сгенерировать 90% от максимально достигнутого значения по IO. Полученные результаты можно экстраполировать на близкие по конфигурации СХД.

Читайте также: