|
|
|
ontape сильно тормозит!
|
|||
|---|---|---|---|
|
#18+
Помогите пожалуйста, кто знает. Сервак на SCO UnixWare 7.3 и IDS 7.31 Бэкап IDS делается утилитой ontape -s -L 0, причем в файлы на локальной машине. Потом эти файлы уже другим механизмом переносятся на ленточную библиотеку. Размер каждого файла для бэкапа - 2 GB. Есть так-же скрипт, который после наполнения файла заменяет его пустым для автоматической работы. Все это работает, все прекрасно. Но иногда (неизвестно почему) бэкап не проходит полностью, т.к. оntape вдруг начинает писать очень медленно (если при нормальной скорости один файл набивается порядка 1-2 минут, то здесь доходит до 30-40 минут!!! ). Полный бэкап формирует 14 таких файлов, ну и соответственно до ночной перезагрузки серавка не успевает выполниться. Происходит это, как правило не сразу, а через какое-то время, то бишь 2-3 файла (или больше, когда как) набиваются нормально, а потом начинаются такие вот тормоза. И непонятно почему. Опять же это не всегда, частенько все проходит нормально. После того как начинаются тормоза, в osmlog идут постоянные вопли от seddmail о превышении нагрузки: Apr 26 22:29:44 sendmail[1320]: rejecting connections on daemon Daemon0: load average: 12 Apr 26 22:29:59 sendmail[1320]: rejecting connections on daemon Daemon0: load average: 14 Apr 26 22:30:14 sendmail[1320]: rejecting connections on daemon Daemon0: load average: 17 Apr 26 22:30:29 sendmail[1320]: rejecting connections on daemon Daemon0: load average: 17 Apr 26 22:30:44 sendmail[1320]: rejecting connections on daemon Daemon0: load average: 19 Вот таким макаром. Здесь бэкап начался в 22:20, тормозить начало в 22:29. Сендмейл тут ни при чем, я его пробовал выключать. Также в это время сервак больше ничем не занят, чтобы думать о том, что захлебыватся от нагрузки. С чем это может быть связано и какие пути решения есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 15:03 |
|
||
|
ontape сильно тормозит!
|
|||
|---|---|---|---|
|
#18+
Помню, что на тех версиях был известный баг, который назывался типа "page timestamp bug" или "old pages" bug, который именно и приводил к периодическому резкому замедлению процесса архивирования. При этом сервак должен интенсивно шевелить дисками, так как производится полный апдейт всех страниц. Поищи Гуглем по CDI (UCDI) там наверняка можно найти обсуждения и рекомендации. Вот у себя нашел: ========== Is this a long existing instance that has been upgraded, over time, to 7.31FC6? You may be running into the page timestamp bug which is not fixed until the C8 maintenance release (though you can ask for a back-port patch to FC6 if you have maintenance it is a backward compatible fix. The problem is that there are pages with timestamps so old that the timestamp values are wrapping to negative so to prevent them from wrapping again and overtaking the old pages the engine, during each archive, restamps the oldest pages. Unfortunately it seems that it stops archiving to do this which lets the tape stop and have to be backed up and spun up to speed again. The patch apparently just gathers the pagenumbers that need restamping and batches the updates after the archive is complete or assigns a separate thread to do the job. ========== ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 16:01 |
|
||
|
ontape сильно тормозит!
|
|||
|---|---|---|---|
|
#18+
Могу добавить, что единственный выход - апгрейдится на более свежую версию. У меня к сожалению пока что такой возможности нет и база иногда вместо 2-х часов бекапится 2-е суток. К счастью в выходные у меня нет большой активности и пока что это не критично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 09:37 |
|
||
|
ontape сильно тормозит!
|
|||
|---|---|---|---|
|
#18+
DaugavaМогу добавить, что единственный выход - апгрейдится на более свежую версию. У меня к сожалению пока что такой возможности нет и база иногда вместо 2-х часов бекапится 2-е суток. К счастью в выходные у меня нет большой активности и пока что это не критично. Интересно то, что тормозит не всегда... В какие-то дни бэкап пролетает на ура. По нескольку раз пробовал. Даже при хорошей загрузке сервака. А в какие-то сильно тормозит. Пробовал и перегружать IDS и сам сервак, не помогает. Может быть нужно перед бэкапом какие-то телодвижения с базой проделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 08:42 |
|
||
|
ontape сильно тормозит!
|
|||
|---|---|---|---|
|
#18+
mrbob DaugavaМогу добавить, что единственный выход - апгрейдится на более свежую версию. У меня к сожалению пока что такой возможности нет и база иногда вместо 2-х часов бекапится 2-е суток. К счастью в выходные у меня нет большой активности и пока что это не критично. Интересно то, что тормозит не всегда... В какие-то дни бэкап пролетает на ура. По нескольку раз пробовал. Даже при хорошей загрузке сервака. А в какие-то сильно тормозит. Пробовал и перегружать IDS и сам сервак, не помогает. Может быть нужно перед бэкапом какие-то телодвижения с базой проделать? да. Проапгрейдиться на версию без бага + установить нужную переменную окружения (если мой склероз мне не изменяет) + выполнить бэкап дважды, поскольку первый бэкап после апгрейда ненадежен (см. примечание про склероз). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 08:56 |
|
||
|
ontape сильно тормозит!
|
|||
|---|---|---|---|
|
#18+
1. Версия без бага существует не под все платформы :(. Под Solaris X86 нет. 2. Не переменная окружения, а "CCFLAGS 0x400000" в onconfig. Но играет рояль это для определенных версий, и ставить по идее надо только по совету саппорта. В целом верно, единственный гарантированый вариант - проапгредится до нужной версии. Так как я сделать этого не мог, то регламентными операциями перенес бекап в некритичное для меня время. До автоматизации процесса бекапа приходилось бороться с быстрым загрязнением буфферов и соответственно длинными чекпоинтами путем уменьшения LRU_MAX_DIRTY,LRU_MIN_DIRTY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 10:51 |
|
||
|
ontape сильно тормозит!
|
|||
|---|---|---|---|
|
#18+
Выбегалло mrbob DaugavaМогу добавить, что единственный выход - апгрейдится на более свежую версию. У меня к сожалению пока что такой возможности нет и база иногда вместо 2-х часов бекапится 2-е суток. К счастью в выходные у меня нет большой активности и пока что это не критично. Интересно то, что тормозит не всегда... В какие-то дни бэкап пролетает на ура. По нескольку раз пробовал. Даже при хорошей загрузке сервака. А в какие-то сильно тормозит. Пробовал и перегружать IDS и сам сервак, не помогает. Может быть нужно перед бэкапом какие-то телодвижения с базой проделать? да. Проапгрейдиться на версию без бага + установить нужную переменную окружения (если мой склероз мне не изменяет) + выполнить бэкап дважды, поскольку первый бэкап после апгрейда ненадежен (см. примечание про склероз). May be onmode -F ( free unused pages )? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 10:59 |
|
||
|
ontape сильно тормозит!
|
|||
|---|---|---|---|
|
#18+
SashaLeschinskyMay be onmode -F ( free unused pages )? Не путайте теплое с мягким. "onmode -F " освободит не заюзаную оперативную память. В то время как баг заключается в том, что сервер считает, что страница является очень старой, поэтому ее надо немедленно перезаписать, что создает весьма ощутимую нагрузку на сервер. Возможно, в качестве workaround подойтет какой-нибудь скрипт, типа "update table set a=a", выполненный для всех таблиц, либо какой-нибудь другой способ, который изменит timestamp. Но все это достаточно проблематично, так как не факт, что timestamp поменяется, +триггера, +длинные транзакции и т.д. Вообщем, расход времени на данное мероприятие может оказаться большим, чем "тормозной" ontape. Кстати, если мне память не изменяет onbar тормозит также, по крайней мере нагрузку на сервер создает другая нить, не ontape. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 16:10 |
|
||
|
ontape сильно тормозит!
|
|||
|---|---|---|---|
|
#18+
И проверить, что идёт именно перезапись страниц, можно с помощью onstat -D : при нормальном бэкапе страницы только читаются, при длинном - количество записанных стремится приблизиться к количеству записанных. Или еще вот таким способом. И ничем от него не избавиться. Правда, мне частично помогло одно действие: drop database . :) После переноса базы на другой сервер. ;) -- Legions of Informix forever! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 16:58 |
|
||
|
|
start [/forum/topic.php?fid=44&msg=33749054&tid=1608658]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
| others: | 214ms |
| total: | 380ms |
| 0 / 0 |
