Если OutOfMemoryError указывает небольшой размер кучи или нет, если да, как ограничить скорость, если нет, что это значит?
Да, кучи недостаточновыделить всю память, необходимую приложению для работы.Мы не видим этого очень часто, и оператор подавления является новым, поэтому я с подозрением отношусь к этому, но хорошо иметь в виду, что в принципе любая структура данных в вашем приложении может быть ответственной.
Лучший способ диагностировать нехватку памяти - сделать «дамп кучи».Это в основном копирует всю память вашей JVM в файл, так что вы можете анализировать его содержимое с помощью программы, такой как https://www.eclipse.org/mat/.Это будет немного кривой обучения, но я думаю, вы обнаружите, что какое-то средство с анализом использования памяти в целом очень удобно.
Вы можете запустить дамп кучи в любое время (естьнесколько способов сделать это, вам придется исследовать лучший способ для вас).Но я думаю, что вы захотите использовать изящную опцию Java, чтобы сделать дамп кучи, когда он получает ошибку нехватки памяти.Таким образом, вы с большей вероятностью определите виновника.См. https://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/clopts.html#gbzrr или аналогичный для вашей JVM.
Я могу предположить причину сброса кучи, но я боюсь, что могу просто сбить вас с толку и потратить ваше время.Как только у вас появятся результаты дампа, я думаю, вам следует открыть отчет об ошибках в трекере проблем Кафки: https://issues.apache.org/jira/projects/KAFKA.Затем мы можем помочь выяснить, как обойти эту ошибку, чтобы она снова заработала, а также как ее исправить в будущих выпусках.
На самом деле, я предложу одно предположение ... Возможно, вы 'Вы видите результат этой ошибки: https://github.com/apache/kafka/pull/6536 (https://issues.apache.org/jira/browse/KAFKA-7895). Если ваш OOME пропадает, когда вы удаляете оператор подавления, вы можете оставить его на время. Как только мы объединяемИсправьте, я буду запрашивать выпуск исправления, и вы можете попробовать еще раз, чтобы увидеть, решена ли проблема.
Ключ для KTABLE-SUPPRESS-STATE-STORE определяется тем, каким API, каким образом илиДолжен ли я контролировать это?
К счастью, у этого есть более простой ответ. Ключ, на который вы смотрите - это бинарная версия ключа записи и метка времени окна. Этот ключявляется результатом использования windowBy. В Java вы можете видеть, что результатом агрегирования является KTable<Windowed<String>, ...> и что Suppress не меняет тип ключа или значения. Другими словами, вы смотрите насериализованная версияна ключ (Windowed<String>).
Оставляя подавление в стороне на секунду;Допустим, у вас есть два серийных номера, «asdf» и «zxcv».Допустим, ваш размер окна составляет один час.Ваше приложение группирует события для каждого этих серийных номеров (независимо) в каждый час дня.Таким образом, существует агрегация для всех записей «asdf» с 9:00 до 10:00, а также есть одна для всех записей «zxcv» с 9:00 до 10:00.Таким образом, общее количество ключей в оконной таблице KTable составляет key space x number of windows being retained.
Оператор подавления не влияет на количество ключей в таблице KTable.Его целью является подавление обновлений для этих клавиш в течение определенного времени (timeToWait).Например, без подавления, если вы получите 3 обновления записи «asdf» в период с 9:00 до 10:00, оконная агрегация будет выдавать обновленный результат для (asdf, 9:00) каждый раз, поэтому для 3 событий в, вы видите 3Результаты обновления выходят.Оператор Suppress просто запрещает эти обновления результатов до тех пор, пока не пройдет timeToWait, а когда он пройдет, он выдаст только самое последнее обновление.
Таким образом, количество ключей в буфере подавления в любое время меньшечем общее количество ключей в восходящем KTable.Он просто содержит ключи, которые были обновлены за последний timeToWait период времени.
Помогает ли это?