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

Тема в разделе "Lotus - Программирование", создана пользователем TIA, 19 мар 2010.

  1. TIA

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Проблема:
    С рабочей станции пользователя выполняется 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ки. До апгрейда всё нормально было.

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

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    а локальный клиент какой версии?
    сочитание верси сервер-клиент - тоже может влиять...
     
  3. TIA

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Может. Наблюдается в клиентах и 6-ой, и в 7-ой, и в 8-ой версии.
     
  4. nvyush

    nvyush Lotus team
    Lotus team

    Регистрация:
    22 апр 2009
    Сообщения:
    2.317
    Симпатии:
    0
    Может включено шифрование трафика?
     
  5. Klido

    Klido Гость

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

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Скорее всего проблема на обоих серверах кластера, т.к. пользователи сидят на обоих серверах и виснет у всех.
    Корректно работает на третьем сервере. Т.е. кластер и проблема -- у клиента, а корректно -- у меня.

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

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

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    compact: -D или -С
    или просто компакт?
     
  8. TIA

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Load Updall -R <путь к базе>
    Load Fixup -F -J <путь к базе>
    Load Compact -C <путь к базе>

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

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

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

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    а ежели compact -R (возвратить формат) - изменится поведение?
     
  10. TIA

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Любопыно. Попробуем.
     
  11. Klido

    Klido Гость

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

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Сегодня попробовали поискать по другим базам на том же сервере, где был замечен большой трафик. Трафик нормальный, при таком же числе найденных документов. Потому я склоняюсь к мысли, что дело не в сервере, а в базе данных.
     
  13. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    с ODS игрались (возвращали обратно)?
     
  14. TIA

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Запросил. Вчера должны были попробовать, сегодня жду результатов. Но поиск по другой БД с тем же 48 ODS выполняется нормально.
     
  15. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    судя по нек. воспоминаниям :trash: конвертация ODS, иногда, дает разные побочные эффекты
     
  16. turumbay

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

    TIA :-)
    Lotus team

    Регистрация:
    15 май 2009
    Сообщения:
    790
    Симпатии:
    0
    Откат ODS в данном случае ничего не дал. :(
    Грохнем. Зависимость времени поиска от числа стабов быть должна, но вот в результат они не должны попадать, потому не понятен столь большой объём передаваемой с сервера инфы. Но чем нидус не шутит -- попробуем.

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

    ToxaRat Чёрный маг
    Lotus team

    Регистрация:
    6 ноя 2007
    Сообщения:
    3.046
    Симпатии:
    18
    у меня есть предположение что это из-за большого количества окурков
     
  19. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    эксперимент: 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 )
     
  20. ToxaRat

    ToxaRat Чёрный маг
    Lotus team

    Регистрация:
    6 ноя 2007
    Сообщения:
    3.046
    Симпатии:
    18
    и у меня такое ощущение тоже есть, ведь почти все основные аттрибуты у окурка имеются, и практика когда в базе по 30К окурков и всего 100 доков показывает что тормозит он очень безбожно, пока не удалишь все окурки.
    Тут ощущения мне подсказывают что сервер ищет по всему и лишь на самой последней стадии когда нужно передать доки юзеру он проверяет его на "доступ"
     
Загрузка...

Поделиться этой страницей