Что вызвало бы IO, Ожидают на SAN?
То, сколько времени 1.5 ТБ данных берут для копирования, зависит очень от типа данных. Если у Вас будут некоторые 1 500 файлов на 1 ГБ, то, вероятно, только потребуется несколько часов, но если у Вас будет полтора миллиарда файлов 1 КБ, то, вероятно, потребуются дни.
Это из-за двух спорящих спецификаций на дисках: пропускная способность и среднее время доступа. Традиционный диск с 100MB/sec пропускной способностью и время доступа на 10 мс довольно распространен. Если можно передать данные потоком последовательно, можно получить 100MB/sec. Однако, если необходимо перейти к другому месту, требуется 10 мс. Если бы Вы передавали потоком, то Вы, возможно, записали 1 МБ данных во время, которое требуется для перехода к другому местоположению.
Создание файла может взять, несколько ищут, так создание файла 1 КБ может "стоить" столько же сколько потоковая передача нескольких МБ данных.
Так, в некоторых случаях лучше сделать копию неструктурированного диска блочного устройства, чем копирование в файловой системе через что-то как rsync. Если Вы имеете много файлов, в файловой системе то есть, говорите, 50% или более полный, Вы часто более обеспечены просто копирование полного блочного устройства через "dd" до времени, которое требуется. Конечно, Вы не можете сделать этого, в то время как файловая система смонтирована, таким образом, это имеет недостатки также.
SSD могут помочь смягчить это, потому что их времена доступа приблизительно в 100 раз более быстры, но твердотельные диски MLC усложнили проблемы доступа в зависимости от доступности пула предварительно стертых блоков. SLC SSD может помочь этому.
RAID-контроллеры со встроенным кэшем могут помочь с исканием, как может что-то как flashcache модуль ядра, который позволяет Вам кэшировать блочное устройство через SSD.
Системы RAID могут допускать, несколько находят что-либо подобное, ищет, эффективно уменьшая среднее время доступа и также распараллеливание для увеличения пропускной способности. Но Ваша общая производительность будет часто зависеть от того, сколько файлов включено.
SAN имеет гораздо более высокую задержку ввода-вывода, чем локальный диск, из-за фундаментальных законов физики. Итак, если ваше приложение выполняет много небольших операций записи и fsync () после каждой, вы увидите много iowait.
Например, вот два репликанта mysql одного и того же набора данных, содержащих много мелких транзакций, вы увидите, что ведомое устройство в SAN тратит гораздо больше времени на ввод-вывод.
Сан:
Локальный:
Время ожидания SAN может означать, что ваше хранилище является узким местом. Это также могут быть настройки сервера или соединение между вашими серверами и хранилищем, но гораздо чаще, когда я вижу время ожидания для диска SAN, это просто занятый SAN.
Сначала проверьте производительность на дисках, поддерживающих объем. Вы ищете всплески операций ввода-вывода в секунду или МБ / с при чтении или записи и, возможно, всплеск использования кеша. Старайтесь смотреть только на оборудование, задействованное в исследуемом томе. Кроме того, посмотрите немного назад и вперед, чтобы увидеть, были ли более высокие всплески, которые не вызывали проблем. Если это так, то вряд ли проблема была в оборудовании хранения. Корректирующие действия для аппаратных узких мест в хранилище могут включать перенос этого тома в другой пул или RAID, или увеличение количества шпинделей или кеша.
Во-вторых, проверьте настройки глубины очереди на сервере. Если у вас очень большая глубина очереди, ваш сервер будет видеть более высокие задержки в периоды высокой загрузки. Глубина очереди - это способ хранилища сказать серверу, что нужно ограничить ввод-вывод, позволяя хранилищу наверстать упущенное. 32 - хорошее среднее число, которое будет поддерживаться большинством серверных ОС и большинством устройств хранения, которые я видел. Я также видел более высокую и низкую работу, но если он установлен на 1024 или что-то в этом роде, это может объяснить большое время ожидания. В ситуации, когда глубина очереди очень велика, сервер ставит в очередь все, что он хочет сделать, а затем хранилище делает это так быстро, как если бы глубина очереди была намного меньше. Поскольку сервер измеряет время ожидания с момента, когда что-то поступает в очередь и выходит из нее, время ожидания увеличится.
Наконец, проверьте журналы ошибок для сервера. Убедитесь, что нет проблем с уровнем передачи (таких как тайм-ауты диска или сбои пути). Если есть, вы можете посмотреть на переключатель.
Он измеряется не иначе, чем на сервере: поступает больше запросов ввода-вывода, чем может быть обработано доступными аппаратными ресурсами.
High IO wait as reported by the SAN management software either means SAN hardware can't keep up with the demands of your SAN clients. This is either because your hardware just doesn't have the capacity for your load, or it could be something is failing and under-performing.
A slowly failing drive causing poor performance is actually pretty common, especially in RAID5 setups. Pull the SMART logs for all of your drives and I'll bet you find a drive with a very high number of corrected errors. (Correcting those errors takes time. If an individual error is corrected within a certain amount of time, then the RAID controller does not log an error. But stack up a lot of those errors and that adds up to a lot of time. And that's how you get poor performance.)