powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Оптимизация текстовой индексации
10 сообщений из 10, страница 1 из 1
Оптимизация текстовой индексации
    #35928212
Leron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем привет!
У нас проект, в котором основная функция это текстовая индексация. На пустом индексе скорость индексации приемлема, но по мере заполнения индекса скорость индексации падает в 3-4 раза. Мы используем битовый индекс, и все индексированные слова хранятся в одном индексе. Специально для ускорения поставили 64-битную Windows 2008, выделили буфер-пул 10000 страниц, но это мало помогло. Самое обидное, что два процессора с тактовой 3 Гц и четырьмя ядрами простаивают. Загрузка 20-25%. Raid на 8 дисков по нашим оценкам тоже не загружен. Есть несколько предположений, как повысить скорость индексации:
1) Создать несколько индексов, и каждый индекс будет отвечать за некоторый диапазон начальных букв индексируемого слова. Т.е:
^TextIndexAE(“AUTO”)= <биты>
^TextIndexAE(“EURO”)= <биты>
^TextIndexFL(“FRUIT”)= <биты>
AE, FL – диапазон начальных символов слов, которые хранит индекс.
Это позволит проводить параллельное индексирование и поиск.
Или же самое, но хранить все в одном индексе:
^TextIndex(“AE”,“AUTO”)= <биты>
^TextIndex(“AE”, “EURO”)= <биты>
^TextIndex(“FL”,“FRUIT”)= <биты>
2) Текстовый индекс хранить в памяти (CacheTemp), все операции проводить с ним, и иногда синхронизировать его с тем, что находится на диске.
3) Отмапировать текстовый индекс в другую базу данных и перенести ее на другой физический диск.


Может есть другие варианты оптимизации?

З.ы. Размер индекса может достигать 1Гб.
...
Рейтинг: 0 / 0
Оптимизация текстовой индексации
    #35928672
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leron2) Текстовый индекс хранить в памяти (CacheTemp), Не совсем так. В БД CacheTemp тоже хранятся глобалы, и тоже на диске :), отличие от "обычных" глобалов лишь в том, что они никогда не журналируются (даже в транзакциях), ну и БД очищается при рестарте Cache.
Leron2)буфер-пул 10000 страницО каких страницах речь? Если имелись в виду блоки БД (8Кб), то ~ 80Мб кэша явно мало.
Если имелись в виду 2Мб-страницы (Windows large pages), то 20Гб - возможно многовато; в кулуарах последней конференции звучало, что 4Гб - предел даже на 64-битной платформе. Кроме того, учитывали ли Вы накладные расходы на размещение PTE (ищите поиском по док-ии "Use Large Page Size for Shared Memory")?

Советовать сложно, не зная задачи и Вашей ситуации. Но напрашивается наивный вопрос: класс %Text.Russian использовать пробовали?
...
Рейтинг: 0 / 0
Оптимизация текстовой индексации
    #35929297
Leron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexey MaslovО каких страницах речь?
Опечатка, имел в виду под 8кб кеш, ставил в настройках "Память и старт системы". Значение это в мегабайтах.

Да, русский текст обрабатывается классом %Text.Russian. возможно немного тормознуто, т.к. лемматизация на основе словаря, но дело не в этом, самая медленная операция в индексировании - вставка нового слова в индекс с установкой нужного бита в битмап индексе.
...
Рейтинг: 0 / 0
Оптимизация текстовой индексации
    #35929706
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО, все же стоит попробовать уменьшить кэш (до 4Гб) и сравнить результат, ибо больше - не всегда лучше.
Вы определили самую медленную операцию с помощью %SYS.MONLBL?
...
Рейтинг: 0 / 0
Оптимизация текстовой индексации
    #35930786
Leron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexey Maslov
Вы определили самую медленную операцию с помощью %SYS.MONLBL?
Да, на заполненном индексе это

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
201       11670   1.307556   1.307556  		s word = $o(words(""))								
202       11670   0.028793   0.028793  		while word'="" {						
203     2653219   6.397159   6.397159  			if $e(word)'="#" {
204     2631291   6.324210   6.324210  				if ($l(word)>=2)&&($l(word)<=30)
205           0   0          0         				{
206     2580387 2033.0392492033.070535 					Set $bit(@langI@("TextIndex",$zcvt(word,"U"),pidchunk),pidoffset)=1
207           0   0          0         				}
208           0   0          0         			}									
209     2653218   7.780849   7.780849  			s word = $o(words(word))
210     2653215   6.382673   6.382670  		}

В langI содержится имя текстового индекса.

pidchunk,pidoffset это:
s pidchunk=newtextid\(64000)+1, pidoffset=newtextid#(64000)+1
где newtextid идентификатор нового текста

этот тест делал с кешем в 4Гб
...
Рейтинг: 0 / 0
Оптимизация текстовой индексации
    #35931250
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть ряд рекомендаций, которые дают в таких случаях консультанты ИнтерСистемз, на эту тему есть статья в writeimagejournal (Быстрая загрузка данных в Cache - как-то так).
В частности, советуют отключить журналирование текущего процесса, но в вашем случае это едва ли серьезно поможет, т.к. скорость падает по мере заполнения индексного глобала. Вот Вы написали, что его размер - порядка 1Гб. А каков примерный объем "рабочего множества" глобалов с данными, вовлеченных в процесс индексации? Индексация делается одновременно с заполнением глобалов с данными или потом?

PS Вы не написали, стало ли быстрее с кэшем 4Гб?
...
Рейтинг: 0 / 0
Оптимизация текстовой индексации
    #35931543
Leron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
У нас 10 потоков, которые выполняют индексацию текстов. Индексация выполняется одновременно вместе с другими действиями, в том числе заполнение глобалов другими данными.
Не совсем понимаю что имеется в виду под словами авторобъем "рабочего множества" глобалов с данными
Мы отмапировали текстовый индекс в другую БД, размер той базы 5Гб
а сам текст сохраняется в текущей БД, размер ее 25гб

вот тест с 10гб кешем. правда количество файлов отличается,
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
200        6991   0.019587  12.074619  			Set batch=$zu(68,25) Do:batch=0 $zu(68,25,1)			
201        6991   0.851304   0.851304  			s word = $o(words(""))								
202        6991   0.016733   0.016733  			while word'="" {						
203     1716059   3.987575   3.987576  				if $e(word)'="#" {
204     1702122   4.048979   4.048979  					if ($l(word)>=2)&&($l(word)<=30)
205           0   0          0         					{
206     1669698 3189.8749923190.434626 						Set $bit(@langI@("TextIndex",$zcvt(word,"U"),pidchunk),pidoffset)=1
207           0   0          0         					}
208           0   0          0         				}									
209     1716047   4.986210   4.986210  				s word = $o(words(word))
210     1716048   3.966772   3.966772  			}
213        6981   0.021279   0.021279  			Do:batch=0 $zu(68,25,0)

c 10 гбайтами даже хуже. совсем непонятно.

и еще, вот так у нас стартует cache с кешем в 10гб:

непонятны скачки памяти, из за чего они могут происходить..
...
Рейтинг: 0 / 0
Оптимизация текстовой индексации
    #35932731
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скачки памяти могут происходить из-за работы с файлом подкачки. То, что с 10Гб кэша работает медленнее, чем с 4Гб, возможно, происходит как раз по этой причине.
Посоветовал бы также собирать статистику использования кэша в Cache (^GLOSTAT или в Портале).
Большое кол-во параллельных потоков, выполняющих индексирование - тоже не всегда благо. Стоит и здесь поискать оптимум.
...
Рейтинг: 0 / 0
Оптимизация текстовой индексации
    #35934756
Leron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вроде бы, решил проблему. После мониторинга использования диска(до этого бд, все журналы, индексируемые тексты находились на одном диске), раскидали бд,журналы,WIJ по разным дискам.
Самый активный в плане использования диска оказался процесс записи в WIJ. Мне кажется, этот процесс журналирует даже те операции которые не попадут в конечный журнал.
И еще, эффективность использования кеша в 10 гб на наших задачах в 2 раза выше чем в 4 гб - ~200 попугаев против ~100 соответственно.
Alexey Maslov , спасибо за участие!
...
Рейтинг: 0 / 0
Оптимизация текстовой индексации
    #35935701
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeronСамый активный в плане использования диска оказался процесс записи в WIJ. Мне кажется, этот процесс журналирует даже те операции которые не попадут в конечный журнал.
Да, в Cache много читателей БД, один писатель в БД - демон записи (WRTDMN).LeronИ еще, эффективность использования кеша в 10 гб на наших задачах в 2 раза выше чем в 4 гб - ~200 попугаев против ~100 соответственноВсе бы ничего, но этот показатель молчит о том, насколько активно идет Виндовая подкачка, которая если начнется, то придушит всех Кашовых "попугаев". М.б., когда Каше - единственный потребитель ресурсов сервера, стоит попробовать вообще отключить файл подкачки?
Так или иначе, можно найти максимальный размер кэша, при котором подкачки не будет (может быть, в вашем случае это 7 или 8 Гб). Меня больше тревожит другое: возможно, в Каше есть внутренний предел размера кэша, начиная с которого увеличение его теряет смысл, т.к. Каше начинает неэффективно с ним работать. Я слышал про 4Гб. Пусть консультанты ИнтерСистемз (или коллеги с бОльшим, чем у меня, опытом конфигурирования 64-битной Каше) меня поправят. Если ошибаюсь - буду только рад.
...
Рейтинг: 0 / 0
10 сообщений из 10, страница 1 из 1
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Оптимизация текстовой индексации
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]