On redis I have around 1.2M json documents,
- 1st namespace: com.test.api.redis.model.document.PRedis:* around 700K
json keys - 2nd nemespace: com.test.api.redis.model.document.SRedis:*
around 550K json keys
every 1 hour for each namespace a job is run that will update all json keys, create new ones and delete the not updated ones. The jobs are for each namespace 30 minute apart from each other.
Usually the job takes 2 minutes.
I observed that the command in slowlog:
FT.SEARCH com.test.api.redis.model.document.PRedisIdx ( -@jobId:[1.731591900002E12 1.731591900002E12]) NOCONTENT LIMIT 0 10000 DIALECT 1
that I use to find the not updated keys during the job, over time gradually increases on same load.
For example first time after redis is started it will run in 30ms, after 1 days it gets to 1 second, after a week 10 seconds, etc..
If I restart the docker container for redis this times again go back to normal 30ms and than again gradually start to increase.
Same issue working with latest images:
redis/redis-stack-server:7.2.0-v13 and
redis/redis-stack-server:7.4.0-v1
Anyone have idea what can be the cause for this performance degradation ?
I have tried memory purge, active defrag, kill clients, increase time between jobs to 5 hours, but the performance is still going down over time…
During job runs the cpu usage goes 99%, but between jobs its less than 1%.
Anyone have some suggestions what could be the culprit for this redis behaviour ?
Info about jobId: is a current time milis of when job is run:
defined with redis om spring in document entity as:
@Indexed
private Long jobId;
this translates to attribute in the index:
18) 1) "identifier"
2) "$.jobId"
3) "attribute"
4) "jobId"
5) "type"
6) "NUMERIC"
2
Answers
Seems like the issue in my case was the negation -@jobId, NOT operator seems is not utilizing the index efficiently.
Used @jobId:[0 jobId-1] instead solved the performance issues >10ms.
In the upcoming major release of redisearch, you could keep the performance of the wildcard and not iterators consistently good on the expense of some additional memory consumption: https://github.com/RediSearch/RediSearch/pull/4869