Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
Всем привет! У нас проект, в котором основная функция это текстовая индексация. На пустом индексе скорость индексации приемлема, но по мере заполнения индекса скорость индексации падает в 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Гб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2009, 13:31 |
|
||
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
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 использовать пробовали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2009, 17:35 |
|
||
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
Alexey MaslovО каких страницах речь? Опечатка, имел в виду под 8кб кеш, ставил в настройках "Память и старт системы". Значение это в мегабайтах. Да, русский текст обрабатывается классом %Text.Russian. возможно немного тормознуто, т.к. лемматизация на основе словаря, но дело не в этом, самая медленная операция в индексировании - вставка нового слова в индекс с установкой нужного бита в битмап индексе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2009, 23:45 |
|
||
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
ИМХО, все же стоит попробовать уменьшить кэш (до 4Гб) и сравнить результат, ибо больше - не всегда лучше. Вы определили самую медленную операцию с помощью %SYS.MONLBL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2009, 10:12 |
|
||
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
Alexey Maslov Вы определили самую медленную операцию с помощью %SYS.MONLBL? Да, на заполненном индексе это Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. В langI содержится имя текстового индекса. pidchunk,pidoffset это: s pidchunk=newtextid\(64000)+1, pidoffset=newtextid#(64000)+1 где newtextid идентификатор нового текста этот тест делал с кешем в 4Гб ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2009, 14:33 |
|
||
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
Есть ряд рекомендаций, которые дают в таких случаях консультанты ИнтерСистемз, на эту тему есть статья в writeimagejournal (Быстрая загрузка данных в Cache - как-то так). В частности, советуют отключить журналирование текущего процесса, но в вашем случае это едва ли серьезно поможет, т.к. скорость падает по мере заполнения индексного глобала. Вот Вы написали, что его размер - порядка 1Гб. А каков примерный объем "рабочего множества" глобалов с данными, вовлеченных в процесс индексации? Индексация делается одновременно с заполнением глобалов с данными или потом? PS Вы не написали, стало ли быстрее с кэшем 4Гб? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2009, 16:46 |
|
||
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
У нас 10 потоков, которые выполняют индексацию текстов. Индексация выполняется одновременно вместе с другими действиями, в том числе заполнение глобалов другими данными. Не совсем понимаю что имеется в виду под словами авторобъем "рабочего множества" глобалов с данными Мы отмапировали текстовый индекс в другую БД, размер той базы 5Гб а сам текст сохраняется в текущей БД, размер ее 25гб вот тест с 10гб кешем. правда количество файлов отличается, Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. c 10 гбайтами даже хуже. совсем непонятно. и еще, вот так у нас стартует cache с кешем в 10гб: непонятны скачки памяти, из за чего они могут происходить.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2009, 18:15 |
|
||
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
Скачки памяти могут происходить из-за работы с файлом подкачки. То, что с 10Гб кэша работает медленнее, чем с 4Гб, возможно, происходит как раз по этой причине. Посоветовал бы также собирать статистику использования кэша в Cache (^GLOSTAT или в Портале). Большое кол-во параллельных потоков, выполняющих индексирование - тоже не всегда благо. Стоит и здесь поискать оптимум. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2009, 11:54 |
|
||
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
Вроде бы, решил проблему. После мониторинга использования диска(до этого бд, все журналы, индексируемые тексты находились на одном диске), раскидали бд,журналы,WIJ по разным дискам. Самый активный в плане использования диска оказался процесс записи в WIJ. Мне кажется, этот процесс журналирует даже те операции которые не попадут в конечный журнал. И еще, эффективность использования кеша в 10 гб на наших задачах в 2 раза выше чем в 4 гб - ~200 попугаев против ~100 соответственно. Alexey Maslov , спасибо за участие! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2009, 23:50 |
|
||
|
Оптимизация текстовой индексации
|
|||
|---|---|---|---|
|
#18+
LeronСамый активный в плане использования диска оказался процесс записи в WIJ. Мне кажется, этот процесс журналирует даже те операции которые не попадут в конечный журнал. Да, в Cache много читателей БД, один писатель в БД - демон записи (WRTDMN).LeronИ еще, эффективность использования кеша в 10 гб на наших задачах в 2 раза выше чем в 4 гб - ~200 попугаев против ~100 соответственноВсе бы ничего, но этот показатель молчит о том, насколько активно идет Виндовая подкачка, которая если начнется, то придушит всех Кашовых "попугаев". М.б., когда Каше - единственный потребитель ресурсов сервера, стоит попробовать вообще отключить файл подкачки? Так или иначе, можно найти максимальный размер кэша, при котором подкачки не будет (может быть, в вашем случае это 7 или 8 Гб). Меня больше тревожит другое: возможно, в Каше есть внутренний предел размера кэша, начиная с которого увеличение его теряет смысл, т.к. Каше начинает неэффективно с ним работать. Я слышал про 4Гб. Пусть консультанты ИнтерСистемз (или коллеги с бОльшим, чем у меня, опытом конфигурирования 64-битной Каше) меня поправят. Если ошибаюсь - буду только рад. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2009, 12:24 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=35929297&tid=1558523]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
161ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 512ms |

| 0 / 0 |
