Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[Bug] Limiting memory does not degrade query latency

Aberta
  • Algo errado?
#17,070 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
35/100
Tipo de issue
Bug
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
docker, java, sql
Domínio
databases, performance

Direção de pesquisa

Comece reproduzindo a carga de trabalho relatada do MulletBench usando as configurações de memória do Docker Compose descritas na issue e compare a latência das consultas com o uso de memória do contêiner. Rastreie o comportamento do banco de dados responsável pela latência inalterada entre os limites; considera-se concluído quando a causa for identificada e uma correção for validada em relação às cargas de trabalho de agregação, downsampling e filtragem de outliers.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Search before asking
  • I searched in the issues and found nothing similar.
Version

1.1.3 and 1.3.4 (tested with standalone Docker image)

Describe the bug and provide the minimal reproduce step

While testing IoTDB under limited memory configurations, using docker for that effect, it was found that the database's performance won't drop until the threshold of 4GB of memory is hit, despite it always using the maximum amount of memory allocated for the container.

It was expected that progressively constraining the database's available memory would lead to gradual performance degradation, but instead IoTDB maintains virtually identical query latency across the tested memory limits, despite always consuming the maximum amount of memory available to the container.

Minimal reprodution steps:

  1. Launch IoTDB in standalone mode with constrained memory using Docker Compose
  2. Preload data before executing queries
  3. Execue a query workload, using the same for every memory configuration

The queries follow the following templates:

-- Aggregation
select agg_func(field) from path where time >= start and time <= end

-- Downsampling
select field from path group by ([start, end), step)

-- Outlier-filter
select field from path where time >= start and time <= end and field [>,>=,<,<=] threshold
Image Image
What did you expect to see?

Either performance degradation as memory limits get increasingly smaller, or the container not using all the memory available to it, if it is able to maintain performance with less memory usage.

What did you see instead?

Performance didn't degrade until the 4GB memory limit, remaining similar regardless of the limit used, despite the database always using the maximum memory allocated to it.

Anything else?

The tests were run using MulletBench, as well as plot generation.

Are you willing to submit a PR?
  • I'm willing to submit a PR!
Linguagem predominante
Java
Estrelas
6.4k
Forks
1.2k
Merge médio
1d 20h
PRs com merge (30d)
137

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de apache/iotdb

Todas as issues de apache/iotdb

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.