• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Ошибка: Unable To Extend An Id Table - Insufficient Memory

  • Автор темы Antish
  • Дата начала
A

Antish

Добрый день!
Ошибка возникает при запуске compact или при репликации.
Lotus Domino Server 8.5.1 FP3
база большая 1600000 документов 19ГБ
Подскажите в чем может быть проблема?

Это уже смотрел


compact -с иногда отрабатывает, иногда выдает вышеуказанную ошибку

Что из себя представляет ID table? Какими средствами можно ее увидеть, оценить размер или фрагментированность и т.д.?
 
K

Klido

Antish
по второму линку описано про ID table...
рекомендую как минимум зачистить stubs - слегка должно помочь....

As documents are added and deleted over time the ID table can become very fragmented and eventually will overflow.

Сколько памяти на серваке? какая ОС?
 
A

Antish

всего 1.6ляма доков а ODS какой? :)
ODS version: 48

Добавлено:
Antish
по второму линку описано про ID table...
рекомендую как минимум зачистить stubs - слегка должно помочь....

As documents are added and deleted over time the ID table can become very fragmented and eventually will overflow.

Сколько памяти на серваке? какая ОС?
stubs зачищены (живут 1 день)
24ГБ оперативной памяти ОС Windows 2008 R2
 
K

Klido

как бы не соответствует версии сервера... уж такие базы надо приводить в первую очередь в 51....

если не помогает - не пора ли подумать о декомпозиции базы на риалтайм+архив хотя бы?
 
A

Antish

как бы не соответствует версии сервера... уж такие базы надо приводить в первую очередь в 51....

если не помогает - не пора ли подумать о декомпозиции базы на риалтайм+архив хотя бы?
на другом сервере ODS 51, ситуация та же, данные в архив сбрасываются ежемесячно
 
A

Akupaka

уж такие базы надо приводить в первую очередь в 51
може лучше на старую добрую 43? ))

всего 1.6ляма доков
ууу, какие мы храбрые! )))

Antish
А, если прибить все индексы видов (compact -D -c) и почистить стабы? К стати, то, что они в настройках живут 1 день, не значит, что их нет. Може они застряли? Проверь нотеспиком или подобным софтом. Еще фиксап иногда лечит, иногда калечит... Бэкапы делать не забывай.
 
K

Klido

т.е. есть реплики базы на другом сервере с аналогичной проблемой?
тогда похоже имеет место пресловутое сочетание 100К+ доков, частое обновление доков и достаточно большой размер базы...

несколько лет назад ещё на 6-ке видел похожую проблему на 50К доков и 40Гб базе... но там неоднократный фиксапокомпакт (да - и с прибиением индексов) помог... помню помучались чуть ли не сутки...
 
A

Antish

т.е. есть реплики базы на другом сервере с аналогичной проблемой?
тогда похоже имеет место пресловутое сочетание 100К+ доков, частое обновление доков и достаточно большой размер базы...

несколько лет назад ещё на 6-ке видел похожую проблему на 50К доков и 40Гб базе... но там неоднократный фиксапокомпакт (да - и с прибиением индексов) помог... помню помучались чуть ли не сутки...


Ситуация такая, создаём новую реплику, никаких естественно индексов, никаких стабов (scanEZ), через несколько дней при попытке compact -c
как рекомендует IBM получаем ошибку по ID table.

4 реплики, ошибка на всех появляется почти одновременно, ODS48 -1 шт и ODS51 - 3шт.

Все эти рекомендации не помогают, всё делалось, основной вопрос КАК ПОСМОТРЕТЬ ID TABLE ??? Сторонний софт ? API функции, может у кого есть наработки какие по этому вопросу ?

Наблюдая за Table можно было бы более эффективно найти решение, а не тыкаться по репликам и компактам.

В архиве около 3 000 000 документов, но видимо из-за отсутсвия активной записи/удаления никаких проблем нет.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Antish
очень интересная ситуация, если у вас там так часто меняются доки, может проблема не в базе а в Transactional logging?
он у вас случаем на всех сервера не одинаков, раз так всё одновременно вылазит?
попытка соктарить жизнь стабов с 90 до 10 не помогает?
 
A

Antish

Antish
очень интересная ситуация, если у вас там так часто меняются доки, может проблема не в базе а в Transactional logging?
он у вас случаем на всех сервера не одинаков, раз так всё одновременно вылазит?
попытка соктарить жизнь стабов с 90 до 10 не помогает?

А как это влияет на нашу ситуацию не разьяснишь ?
Transactional logging включен только на одном сервере.

По поводу стабов, с некоторго времени стоит время жизни 1 день.
 
A

Akupaka

КАК ПОСМОТРЕТЬ ID TABLE ??? Сторонний софт ? API функции, может у кого есть наработки какие по этому вопросу ?
По этому поводу, посмотри Lotus C API, но врядли тебе даст что-то описание функций... Я так понимаю, что нотес не может толком построить таблицу идентификаторов из-за проблем работы с памятью...

А даунгрейд до 8.5.1FP2 не пробовал?
 
A

Antish

По этому поводу, посмотри Lotus C API, но врядли тебе даст что-то описание функций... Я так понимаю, что нотес не может толком построить таблицу идентификаторов из-за проблем работы с памятью...

А даунгрейд до 8.5.1FP2 не пробовал?

IBM по этому поводу молчит как рыба. По поводу версии, один из серверов 8.02FP4 с ODS48. Там та же фигня.
Эта внутренняя таблица быстро фрагментируется из-за большого количества создания/удаления документов, и достигая
какого то предела (который не известен) начинает сыпать ошибку.

С оперативкой это точно никак не связано.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
так всё таки интересно в чем трабла то?
 

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
3
IBM по этому поводу молчит как рыба. По поводу версии, один из серверов 8.02FP4 с ODS48. Там та же фигня.
Эта внутренняя таблица быстро фрагментируется из-за большого количества создания/удаления документов, и достигая
какого то предела (который не известен) начинает сыпать ошибку.

С оперативкой это точно никак не связано.

Аналогичная фигня приключилась - за прошедшее время удалось найти решение?
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
поставте время жизни стаба 0 дней, должно помочь
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!