Stackexchange.redis timeout performing timeout problem

Recently, I was working on a project using. Net core 2.1 and redis for cache. The cache related encapsulation was written by my colleagues, and the driver was stackexchange. Redis version 2.0.571 . I heard that there was a timeout bug in the case of concurrent driver. After the project was almost developed, I pressed it, Simply simulate that 30 users continuously visit a query interface that is useful for caching. As a result, the timeout exception appears under such a small pressure

Timeout performing GET my_ 141 (5000ms), inst: 30, qu: 0, qs: 20, in: 20320, serverEndpoint: 172.16.3.119:6379, mgr: 10 of 10 available, clientName: s-119, IOCP: (Busy=0,Free=1000,Min=1,Max=1000), WORKER: (Busy=120,Free=32747,Min=1,Max=32767), v: 2.0.571.20511(Please take a look at this article for some common client-side issues that can cause timeouts:https ://stackexchange.github.io/StackExchange.Redis/Timeouts))

After that is the stack information

Egg pain for a long time, search a lot of articles, get the following

Solutions

1. Replace it and don’t use this driver (see the recommendation of. Net core redis driver. Why don’t you use stackexchange. Redis)

2. The redis operation is changed to all asynchronous & amp& amp; ThreadPool.SetMinThreads(200, 200);

I use the second method to solve the problem, the main driver may also encounter pit; There is also the problem of time cost

A brief analysis of the causes

We can see the following paragraph in the above exception information:

IOCP: (Busy=0,Free=1000,Min=1,Max=1000),

WORKER: (Busy=120,Free=32747,Min=1,Max=32767),

This means that there are currently 120 busy worker threads, and the system “the minimum number of new worker threads to be created by the thread pool as needed.”, That is to say, the number of working threads created by the system is not enough to meet the needs of busy threads of redis get operation, resulting in the thread blocking and timeout of some get operations

So we change “minimum thread worker threads” to 200 to solve the problem

200 is my estimation of the server setting in the production environment. Unreasonable setting of this value may lead to performance problems

Similar Posts: