Слишком большой трафик при Dbsearch

[TIA]

Проблема:
С рабочей станции пользователя выполняется NotesDatabase.Search по серверной БД. Выполняется он слишком долго и порождает странно большой трафик от сервера.
Протокол NRPC показывает, что трафик от сервера 5MB, хотя общий размер всех документов в БД всего 3Mb.

(374-71 [374]) SEARCH: 6313 ms. [198+5169562=5169760]
(375-77 [375]) OPEN_NOTE(REPC3257305:00306BAE-NT0000094A,07400002): 62 ms. [48+53579=53627]
(376-77 [376]) OPEN_NOTE(REPC3257305:00306BAE-NT000009B2,07400002): 94 ms. [48+56940=56988]
(377-77 [377]) OPEN_NOTE(REPC3257305:00306BAE-NT00000BBE,07400002): 78 ms. [48+62184=62232]
(378-77 [378]) OPEN_NOTE(REPC3257305:00306BAE-NT00000C56,07400002): 203 ms. [48+52660=52708]
(379-77 [379]) SEARCH: 6031 ms. [194+5169432=5169626]
(380-83 [380]) OPEN_NOTE(REPC3257305:00306BAE-NT00000CEA,07400002): 63 ms. [48+53286=53334]
(381-83 [381]) OPEN_NOTE(REPC3257305:00306BAE-NT00000CEE,07400002): 62 ms. [48+62698=62746]
(382-83 [382]) OPEN_NOTE(REPC3257305:002FE95F-NT0000019E,07400002): 16 ms. [48+2790=2838]

Исследование:
В базе данных около 300 документов. Находится 3-4 документа размером по 30-60кб. Никаких ограничений по доступу к документам. На рабочую станцию обычно передаются только NoteID найденных документов. Поэтому 5MB никак не получается.
Когда БД скопировали через файловую систему на другой сервер, время поиска стало 16 мс и трафик 198 байт. Т.е. как и положено.

[08B8:0002-0FCC] (97-93 [244]) SEARCH: 16 ms. [196+198=394]

Пытались удалить реплику БД и создать репликацией повторно -- не помогло. Поиск с другой рабочей станции, приводит к такому же результату. Проблемный сервер в кластере из 2х серверов.

База данных на сервере Domino 8.x с 48 ODS. Был апгрейд сервера с 6ки. До апгрейда всё нормально было.

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

 

[lmike]

а локальный клиент какой версии?
сочитание верси сервер-клиент - тоже может влиять...

 

[TIA]

а локальный клиент какой версии?
сочитание верси сервер-клиент - тоже может влиять...

Может. Наблюдается в клиентах и 6-ой, и в 7-ой, и в 8-ой версии.

 

[nvyush]

Может включено шифрование трафика?

 

[Klido]

Проблемный сервер в кластере из 2х серверов.

а проверяли как надо на том что в кластере или на отдельном?

 

[TIA]

а проверяли как надо на том что в кластере или на отдельном?

Скорее всего проблема на обоих серверах кластера, т.к. пользователи сидят на обоих серверах и виснет у всех.
Корректно работает на третьем сервере. Т.е. кластер и проблема -- у клиента, а корректно -- у меня.

Про шифрование трафика узнаю.

Updall, Fixup, Compact выполняли.

 

[lmike]

...
Updall, Fixup, Compact выполняли.

compact: -D или -С
или просто компакт?

 

[TIA]

или просто компакт?

Load Updall -R <путь к базе>
Load Fixup -F -J <путь к базе>
Load Compact -C <путь к базе>

Добавлено:

Может включено шифрование трафика?

Вроде нет, в notes.ini сервера и клиента у порта либо 12288, что есть 0x3000, либо ничего:
TCPIP=TCP,0,15,0,,12288,

При включённом шифровании должен был бы флаг 0x8000 установлен.

Ещё инфа: в базе 95000 стабов, но они не должны влиять на поиск.

 

[lmike]

а ежели compact -R (возвратить формат) - изменится поведение?

 

[TIA]

а ежели compact -R (возвратить формат) - изменится поведение?

Любопыно. Попробуем.

 

[Klido]

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

 

[TIA]

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

 

[lmike]

с ODS игрались (возвращали обратно)?

 

[TIA]

с ODS игрались (возвращали обратно)?

Запросил. Вчера должны были попробовать, сегодня жду результатов. Но поиск по другой БД с тем же 48 ODS выполняется нормально.

 

[lmike]

судя по нек. воспоминаниям :trash: конвертация ODS, иногда, дает разные побочные эффекты

 

[turumbay]

Проблема:
С рабочей станции пользователя выполняется NotesDatabase.Search по серверной БД. Выполняется он слишком долго и порождает странно большой трафик от сервера.
Протокол NRPC показывает, что трафик от сервера 5MB, хотя общий размер всех документов в БД всего 3Mb.
Исследование:
В базе данных около 300 документов. Находится 3-4 документа размером по 30-60кб. Никаких ограничений по доступу к документам. На рабочую станцию обычно передаются только NoteID найденных документов. Поэтому 5MB никак не получается.
Вопрос:
Собственно, какого х...? Что могло случиться с базой или сервером? Какие гипотезы, предположения?

предположение: грохните стабы.
была похожая проблема. 2 БД на одном сервере с одинаковым дизайном и сравнимым числом документов. Поиск по одинаковой формуле, различия по времени выполнения ~деситикратное.( только сам поиск, без обхода коллекции )
случайно обнаружили зависимость времени поиска от кол-ва стабов в бд. причем даже незначительное их количество мрачно тормозило поиск, т.е. зависимость была нелинейная. глубинных причин искать не стали, похоже на детали работы nsfsearch.
P.S. ну и снифером посмотреть, что там внутре этих 5mb. Если полезной инфы всего 240К( 60кб*4документа ) - то локализовать "лишнюю" инфу будет несложно.

 

[TIA]

с ODS игрались (возвращали обратно)?

Откат ODS в данном случае ничего не дал.

грохните стабы.

Грохнем. Зависимость времени поиска от числа стабов быть должна, но вот в результат они не должны попадать, потому не понятен столь большой объём передаваемой с сервера инфы. Но чем нидус не шутит -- попробуем.

Со снифером посложнее -- надо учить им клиента пользоваться. Но чувствую, дело и до него дойдет.

 

[ToxaRat]

у меня есть предположение что это из-за большого количества окурков

 

[turumbay]

эксперимент: db.search( {form="forStubTest"} , Nothing , 0 )

1.чистая(свежесозданная) бд.
снифер: 4 пакета, 610байт. collection.count = 0
2.создаем 10 документов form="forStubTest"
снифер: 5 пакетов, 1174байт. collection.count = 10
3.валим все документы.
снифер: 5 пакетов, 1174байт. collection.count = 0
4.валим стабы:
снифер: 4 пакета, 610байт. collection.count = 0

вывод каждый сделает сам, но у меня складываеца ощущение, что для db.search - окурок являеца полноценным документом и попадает в результаты поиска. и исчезают они оттуда только при клиенской обработке результатов.
походу в ls( db.search ) криво обернули апишный nsfsearch.
З.Ы. Насчет кривизны db.search: известно, что параметр maxDocs% у NotesDatabase.search не влияет на результат, кот. возвращает сервер.
Т.е. если под условие попали 100 документов, а мы просили вернуть только 10 - сервер все равно вернет 100. А вот когда на клиента будет собрана коллекция из ответа сервера - в ней будет 10 документов( если получать их через getFirst/getNext )

 

[ToxaRat]

но у меня складываеца ощущение, что для db.search - окурок являеца полноценным документом

и у меня такое ощущение тоже есть, ведь почти все основные аттрибуты у окурка имеются, и практика когда в базе по 30К окурков и всего 100 доков показывает что тормозит он очень безбожно, пока не удалишь все окурки.
Тут ощущения мне подсказывают что сервер ищет по всему и лишь на самой последней стадии когда нужно передать доки юзеру он проверяет его на "доступ"