-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: active healthcheck increase the response latency #11756
Comments
because we add other feature in our apisix, so we cannot update it to 3.x version. |
in error.log. find that earlier pod ip exist in healthcheck. |
we also find even if we close the healthcheck. use the tcpdump to capture packet, the apisix instance also acting active healthcheck |
I prefer to this is a bug problem |
Description
Hello, APISIX team.
in our prd env, we suffered a very strange scenario.
we have a cluster which have 9 apisix instances.
the upstream is using service discovery, which is eureka.
our microservice is registerd in eureka, it deployed in k8s, use eureka exposed to apisix, the microservice has 150 instances.
we deployed it in July this year, but recently, we find that the latency is increase to 200ms+ (normal latency is about 100ms, but recently some latency is beyond 200ms), when we send a request directly to one of the microservice instance, it latency is about 100ms,but when the request proxy by apisix, it increased.
we opened active healthcheck(use tcp way), when we closed the healthcheck, the latency suddenly recoverd to about 100ms.
also we find the prometheus metrics may have some odd things. the following metrics is 0:
`
`
the shared_dict worker-events and prometheus-metrics both are 10m
I want to know if the above shared_dict used up could result in healthcheck increase the latency.
I tried reopen it in our dev env, but failed, the error log indicate the prometheus has no memory
I find a other issue metioned : but seems no activity. #11345
hope your answer, thanks.
Environment
apisix version
):2.15.3uname -a
):openresty -V
ornginx -V
):curl http://127.0.0.1:9090/v1/server_info
):3.5.0luarocks --version
):The text was updated successfully, but these errors were encountered: