SDK Google Cloud Search содержит несколько предоставленных Google параметров конфигурации, используемых всеми соединителями. Знание того, как настроить эти параметры, может значительно упростить индексацию данных. В этом руководстве перечислено несколько проблем, которые могут возникнуть во время индексирования, а также настройки, используемые для их решения.
Пропускная способность индексирования для FullTraversalConnector низкая.
В следующей таблице перечислены параметры конфигурации для повышения пропускной способности FullTraversalConnector :
Параметр | Описание | По умолчанию | Изменение конфигурации, чтобы попробовать |
---|---|---|---|
traverse.partitionSize | Число ApiOperation() , которое будет обработано в пакетном режиме перед получением дополнительных APIOperation() . SDK ожидает обработки текущего раздела, прежде чем получить дополнительные элементы. Этот параметр зависит от объема доступной памяти. Меньшие размеры разделов, например 50 или 100, требуют меньше памяти, но больше времени ожидания от имени SDK. | 50 | Если у вас много доступной памяти, попробуйте увеличить partitionSize до 1000 или более. |
batch.batchSize | Количество запросов, объединенных вместе. По окончании секционирования SDK ожидает обработки всех пакетных запросов из раздела. Большие партии требуют более длительного ожидания. | 10 | Попробуйте уменьшить размер пакета. |
batch.maxActiveBatches | Количество допустимых одновременно исполняемых пакетов. | 20 | Если вы уменьшите batchSize , вы должны увеличить maxActiveBatches в соответствии с этой формулой: maxActiveBatches = (partitionSize / batchSize ) + 50. Например, если ваш partititionSize равен 1000, а ваш batchSize равен 5, ваш maxActiveBatches должен быть 250. Дополнительные 50 — это буфер для повторных запросов. Это увеличение позволяет соединителю группировать все запросы без блокировки. |
traverse.threadPoolSize | Число потоков, создаваемых соединителем для обеспечения параллельной обработки. Один итератор последовательно извлекает операции (обычно объекты RepositoryDoc ), но API вызывает процесс параллельно, используя количество потоков threadPoolSize . Каждый поток обрабатывает один элемент за раз. Значение по умолчанию, равное 50, будет обрабатывать максимум 50 элементов одновременно, а обработка отдельного элемента (включая запрос на индексирование) занимает около 4 секунд. | 50 | Попробуйте увеличить threadPoolSize кратно 10. |
Наконец, рассмотрите возможность использования метода setRequestMode()
для изменения режима запроса API ( ASYNCHRONOUS
или SYNCHRONOUS
).
Дополнительную информацию о параметрах файла конфигурации см. в разделе Параметры конфигурации, предоставленные Google .
Пропускная способность индексирования для ListTraversalConnector низкая.
По умолчанию соединитель, реализующий ListTraversalConnnector, использует один обходчик для индексации ваших элементов. Чтобы увеличить производительность индексации, вы можете создать несколько обходчиков, каждый со своей собственной конфигурацией, ориентированной на определенные статусы элементов ( NEW_ITEM
, MODIFIED
и т. д.). В следующей таблице перечислены параметры конфигурации для повышения пропускной способности:
Параметр | Описание | По умолчанию | Изменение конфигурации, чтобы попробовать |
---|---|---|---|
repository.traversers = t1, t2, t3, ... | Создает один или несколько отдельных обходчиков, где t1, t2, t3, ... — уникальное имя каждого. У каждого именованного средства обхода есть свой собственный набор настроек, которые идентифицируются по уникальному имени средства пересечения, например, traversers. t1 .hostload и traversers. t2 .hostload | Один траверсер | Используйте этот параметр, чтобы добавить дополнительные траверсы |
traversers. t1 .hostload = n | Определяет количество потоков n , которые будут использоваться для одновременного индексирования элементов. | 5 | Поэкспериментируйте с настройкой n в зависимости от того, какую нагрузку вы хотите загрузить на свой репозиторий. Начните со значений 10 или выше. |
schedule.pollQueueIntervalSecs = s | Определяет количество s ожидания перед повторным опросом. Соединитель содержимого продолжает опрашивать элементы до тех пор, пока API возвращает элементы в ответе на опрос. Если ответ на опрос пуст, соединитель ждет s секунд, прежде чем повторить попытку. Этот параметр используется только ListingConnector. | 10 | Попробуйте снизить до 1. |
traverser. t1 .pollRequest.statuses = status1 , status2 , … | Указывает статусы status1 , status2 , … элементов для индексирования. Например, установка status1 в NEW_ITEM и status2 в MODIFIED дает команду обходчику t1 индексировать только элементы с этими статусами. | Один траверсер проверяет все статусы | Поэкспериментируйте с тем, чтобы разные проходимцы опрашивали разные статусы. |
Дополнительную информацию о параметрах файла конфигурации см. в разделе Параметры конфигурации, предоставленные Google .
Тайм-ауты или прерывания SDK при загрузке больших файлов
Если при загрузке больших файлов у вас возникает тайм-аут SDK или прерывания, укажите больший тайм-аут с помощью traverser.timeout= s
(где s = количество секунд). Это значение определяет, как долго рабочие потоки будут обрабатывать элемент. Тайм-аут по умолчанию в SDK составляет 60 секунд для потоков перемещения. Кроме того, если у вас истекло время ожидания отдельных запросов API, используйте следующие методы, чтобы увеличить значения времени ожидания запроса:
Запросить параметр таймаута | Описание | По умолчанию |
---|---|---|
indexingService.connectTimeoutSeconds | Тайм-аут подключения для индексации запросов API. | 120 секунд. |
indexingService.readTimeoutSeconds | Тайм-аут чтения для индексации запросов API. | 120 секунд. |