|
|
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Привет всем! Подскажите чайнику, чем может быть ограничена максимальная скорость выполнения бэкапа? Например, скорость работы ontape у IDS 9.30.FC4 на SunOS 5.8? Понимаю, что вопрос несколько расплывчатый, но хочу понять, есть ли ограничения со стороны софта или всё упирается в железо? -- Legions of Informix forever! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 20:54 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Всяко может быть. Если сервер не занят, то скорей всего тормозить будет стриммер (если бэкапить на ленту). В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 21:32 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Теоретически, ограничения со стороны софта, наверное, есть, но практически я встречался только с ограничениями железа, т.е. скорость чтения спейсов и скорость записи. Пример: запись ontape идет на винт (сетевой, на другом компе, сетка 100Мбит), ср. скорость 25Гб в час, т.е. 7Мб в сек. (итоговая скорость). Как по мне, очень неплохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 21:35 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Бекап на ленту делается? Это основной тормоз. Впрочем, ontape тоже имеет свои ограничения, он является однопотоковой тулзой. Использование onbar-a однозначно даст выигрыш в производительности. У меня при прочих равных условиях получился выигрыш где-то 25%. Правда эксперимент делал года 3 назад на IBM-овском 2-ух процессорном серваке с 18-ю дисками в array-e. Informix 9.21 UC2 Solaris X86 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 21:41 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Вот что значит задавать вопросы в конце дня - теперь требуются уточнения. Надо это тоже добавить в ФАК. ;) Бэкап делается с помощью ontape на ленту. Стример внешний Compaq DLT8000. Сервер SunFire 480, внешняя дисковая стойка без рейдов с разными дисками (70 и 140 гиг) -- Legions of Informix forever! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 10:23 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Не сталкивался ли кто с такой проблемой: Используется все та же утилита ontape. Архив создается 28-32 минуты - время устраивает. Чанки расположены на томах VxVM 4.1 Все всех устраивает кроме админа Informix - не получается для вновь добавленных дисков в VxVM менять активный путь. Данная проблема решается установкой соответствующих патчей с MP1, но здесь возникает другая, более "страшная" проблема - через сутки после установки патчей, время выполнения архива увеличивается до 52 минут т.е белее чем на 60% (первый архив после установки патчей создавался в предыдущих временных рамках). Аналогично возросло и время создания распределения. Сравнить статистику работы с дисками до установки патча и после не представляется возможным, так как статистика до установки уже удалена. Значительного роста БД и активности пользователей - не наблюдалось. Бага, где рекомендуется использовать CCFLAG не подходит. Вопрос - сталкивался ли кто с подобными проявлениями при использовании VxVM 4.1 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 10:43 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Вот что значит задавать вопросы в конце дня - теперь требуются уточнения. Надо это тоже добавить в ФАК. ;) Правда, я надеялся получить больше теоретические выкладки. :) Например, что узкое место может быть где-то в железе, типа шины, памяти и т.п. Или ontape при работе делает какие-то "тайные" операции и больше, например, 10 мег в секунду не получится... Для любителей цифирей. Бэкап делается с помощью ontape на ленту. Стример внешний - Compaq DLT8000, 40/80 GB. Код: plaintext Сервер - SunFire 480: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Еще немного параметров: Код: plaintext 1. 2. 3. 4. -- Legions of Informix forever! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 11:01 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
А бы помощью dd if=/dev/zero пробовал померять скорость записи на ленту. ----------------------------------------------------------------------------------------------------------------------------------------- нужно делать то что нужно, а то что не нужно -- делать не нужно (перефразируя В-Пуха). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 11:22 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисА бы помощью dd if=/dev/zero пробовал померять скорость записи на ленту. А от размера блока оно ж тоже вроде зависит... Ладно, стример освободится - попробую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 12:41 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Paul Tatarenko Журавлев ДенисА бы помощью dd if=/dev/zero пробовал померять скорость записи на ленту. А от размера блока оно ж тоже вроде зависит... Ладно, стример освободится - попробую. Имеешь в виду размер блока стримера менять нельзя? dd if=/dev/zero bs=2048 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 13:53 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Да вроде можно, запретов нет. Просто не игрался с этим параметром. И не знаю, нет ли ограничений со стороны железа - прочитается ли потом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 14:27 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Скорость записи завистит от размера блока ленточного устройства. В свое время достигали очень заметного прироста скорости подбором параметра TAPEBLK. Насколько я понимаю не все девайсы понимают изменения размера блока (или не все контроллеры), помню что раньше, когда у нас использовался DDS 3 изменение размера блока не давала результата. Сейчас мы юзаем TANDBERG DATA SLR100. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 21:04 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисА бы помощью dd if=/dev/zero пробовал померять скорость записи на ленту. Только что попробовал. С обычным размером блока 2 Мб (да и 4 Мб тоже) iostat показывает 12-13 тыс. килобайт/сек. При размере блока в 1 Кб скорость упала примерно до 400-600 Кб/сек. Но на наличие/отсутствие ограничений со стороны ontape или Informix это никаким местом не указывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2006, 14:02 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Paul TatarenkoПривет всем! Подскажите чайнику, чем может быть ограничена максимальная скорость выполнения бэкапа? Например, скорость работы ontape у IDS 9.30.FC4 на SunOS 5.8? Понимаю, что вопрос несколько расплывчатый, но хочу понять, есть ли ограничения со стороны софта или всё упирается в железо? -- Legions of Informix forever! Paul, вы несколько странно ставите вопрос. Конечно, никаких специальных ограничений в софте нет. Все ограничения - со стороны железа, естественно. Вопрос в том, где находится боттленек - в процессорах, дисках, сети или стриммере. Чаще всего (если сервер не особо занят), то затык в ленточке. Если сервер под нагрузкой - то боттленек может быть и в процессорах, и в диске. Сетка в данном случае не используется, ее можно в расчет не брать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 19:15 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
ВыбегаллоPaul, вы несколько странно ставите вопрос. Да, это я умею. Этого у меня не отнять. ;) ВыбегаллоКонечно, никаких специальных ограничений в софте нет... Собственно говоря, что-то подобное я и хотел услышать. Просто планируется изменить устройство резервного копирования и у меня возник вот такой глупый вопрос. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 20:38 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Однопоточность ontape на вредить может так: 1. Читаем 1Мб из дибиспейса, ленточка стоит. 2. Пишем 1Мб на ленту, "дибиспейс" стоит. Но если запись на ленту асинхронная, то проблем нет. Как на самом деле я не знаю. ----------------------------------------------------------------------------------------------------------------------------------------- нужно делать то что нужно, а то что не нужно -- делать не нужно (перефразируя В-Пуха). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 09:25 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
В моём случае скорость записи на ленту не достигает потолка (12 Мб/сек) - ontape таки не успевает? Использовать onbar? Но предполагаемого прироста скорости в 25% маловато на таком объёме - количество ленточек не уменьшится (уже 8) и человеческий фактор (смена ленточек) остаётся. -- Legions of Informix forever! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 19:19 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисОднопоточность ontape на вредить может так: 1. Читаем 1Мб из дибиспейса, ленточка стоит. 2. Пишем 1Мб на ленту, "дибиспейс" стоит. Но если запись на ленту асинхронная, то проблем нет. Как на самом деле я не знаю. ----------------------------------------------------------------------------------------------------------------------------------------- нужно делать то что нужно, а то что не нужно -- делать не нужно (перефразируя В-Пуха). ontape ничего не читает. Читает oninit. И передает прочитанные страницы через буфер в памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 21:02 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Paul TatarenkoВ моём случае скорость записи на ленту не достигает потолка (12 Мб/сек) - ontape таки не успевает? Использовать onbar? Но предполагаемого прироста скорости в 25% маловато на таком объёме - количество ленточек не уменьшится (уже 8) и человеческий фактор (смена ленточек) остаётся. купить второй стример и перейти на onbar в параллельном режиме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 21:08 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Выбегаллокупить второй стример и перейти на onbar в параллельном режиме. Никогда не работал с onbar... А может просто сразу другой стример купить? Кстати, с покупкой такого же уже вышел облом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 11:48 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Paul Tatarenko Выбегаллокупить второй стример и перейти на onbar в параллельном режиме. Никогда не работал с onbar... А может просто сразу другой стример купить? Кстати, с покупкой такого же уже вышел облом. Когда-то надо начинать. А второй - не значит идентичный. onbar, в отличии от ontape, позволяет распараллелить архивирование, соответственно уменьшить его время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 19:15 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Интересно, как потом восстанавливаться с кучи стримеров?.. Особенно, если они совсем разные и не совместимые. -- Legions of Informix forever! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 20:04 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
А это уже не твоя забота, а ISM (storage manager)... Но совсем уж несовместимые дивайсы покупать не стОит, мне кажется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 20:29 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Выбегалло купить второй стример и перейти на onbar в параллельном режиме. А я правильно помню, что параллельность будет только при архивировании списка пространств т.н. Storage-Space Backup (onbar -b -L), а при стандартном Whole-System Backup (onbar -b -w) будет последовательное архивирование ? К тому же, нужно помнить, что параллельность хороша при чтении самих dbspaces с разных дисков, а если они все лежат на одном рейде, то ...может параллельность быть и фиктивной (хотя, исходя из того, что диски быстрее лент, польза все равно небольшая будет). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 20:40 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
vasilis Выбегалло купить второй стример и перейти на onbar в параллельном режиме. А я правильно помню, что параллельность будет только при архивировании списка пространств т.н. Storage-Space Backup (onbar -b -L), а при стандартном Whole-System Backup (onbar -b -w) будет последовательное архивирование ? К тому же, нужно помнить, что параллельность хороша при чтении самих dbspaces с разных дисков, а если они все лежат на одном рейде, то ...может параллельность быть и фиктивной (хотя, исходя из того, что диски быстрее лент, польза все равно небольшая будет). Помнишь правильно. Но никто же не заставляет выполнять "стандартный" бэкап, верно? А размер пользы зависит от того, насколько диски быстрее лент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 21:54 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Есть ленточные библиотеки, с кучей ленточек, с несколькими драйвами, со сканерами штрих-кодов (отличать ленточки), с буфером в виде винчестера и озу. Если небольшой на 20 лент да по 100гиг каждая = 2терабайта, не меняя лент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2006, 10:03 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Выбегалло vasilisА я правильно помню, что параллельность будет только при архивировании списка пространств т.н. Storage-Space Backup (onbar -b -L), а при стандартном Whole-System Backup (onbar -b -w) будет последовательное архивирование ? К тому же, нужно помнить, что параллельность хороша при чтении самих dbspaces с разных дисков, а если они все лежат на одном рейде, то ...может параллельность быть и фиктивной (хотя, исходя из того, что диски быстрее лент, польза все равно небольшая будет). Помнишь правильно. Но никто же не заставляет выполнять "стандартный" бэкап, верно? А размер пользы зависит от того, насколько диски быстрее лент. Дибиспейсов там уже пара десятков и каждый квартал добавляется новый - имеем некоторые неудобства :). Но вот скорость точно будет плавать - JBOD с дисками по 73 и по 147 Гиг, на одном диске по несколько дибиспейсов, один дибиспейс может быть на двух дисках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2006, 11:23 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисЕсть ленточные библиотеки, с кучей ленточек, с несколькими драйвами, со сканерами штрих-кодов (отличать ленточки), с буфером в виде винчестера и озу. Если небольшой на 20 лент да по 100гиг каждая = 2терабайта, не меняя лент. Да вот что-то такое, вероятно, и придётся брать. Но вопрос о его скорости остаётся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2006, 11:28 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Добавлю и свое мнение. Вот параметры, которые ограничивают скорость бэкапа: - активность пользователей на сервере чем меньше народа работает во время бэкапа тем лучше - физическая схема размещения пространств если много дисков на которых расположены пространства, то имеется возможность делать параллельный бэкап (onbar) - наличие конкурирующих приложений тут все понятно - размещение архивного носителя и его тип диски быстрее, но не всегда (если используется дисковый пул перед запистью на ленту). С другой стороны некоторые протоколы (lanfree) позволяют писать на ленту очень быстро, в разы быстрее чем через сеть tcp. - способ доставки данных на архивный носитель через сетку или напрямую (быстрее, см. пред. пункт) - параметры софта который производит бэкап как настроим так и поедет. Например onbar позволяет поиграться с размером буфера, числом одновременных процессов. - требования бизнеса к скорости восстановления делаем level-0 или еще инкрементальные после него? Инкрементальные будут идти очень быстро, но время восстановления увеличится. - солнечная активность пришедший с утра админ решит что бэкап должен идти медленно но надежно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 09:57 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
AndronДобавлю и свое мнение. Вот параметры, которые ограничивают скорость бэкапа: - активность пользователей на сервере чем меньше народа работает во время бэкапа тем лучше Практически один. И тот подключается только иногда для выполнения нескольких запросов. Andron- параметры софта который производит бэкап как настроим так и поедет. Например onbar позволяет поиграться с размером буфера, числом одновременных процессов. А у ontape есть параметры, которыми можно играться? Andron- солнечная активность Зашкаливает. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 10:24 |
|
||
|
Максимальная скорость резервного копирования
|
|||
|---|---|---|---|
|
#18+
Paul TatarenkoА у ontape есть параметры, которыми можно играться? Конечно. Загляни в onconfig и все их увидишь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 20:34 |
|
||
|
|

start [/forum/topic.php?all=1&fid=44&tid=1608690]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
82ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
79ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 426ms |

| 0 / 0 |
