Redis Performance Tuning: Save the effect of SNAPSHOT on performance, redissnapshot

Redis Performance Tuning: Save the effect of SNAPSHOT on performance, redissnapshot

Some time ago, the Development Environment reported that access to the Redis server was very slow, and each request took several seconds. 2 ~ This will happen again in three days.

I checked the Linux performance and there is no problem. Pass

# Redis-cli -- latency

It is found that accessing Redis is really slow. It takes several seconds to execute info. There are tens of thousands of clients connected with a parameter.

Redis> client list

We can see that many clients have a large age and have never been released. So I suspect it is related to this. Because the version is 2.8.6, I cannot kill all connections at once through the client. I can only write one program and kill it one by one (

CLIENT KILL addr:port). However, the problem persists.

So I further checked the configuration file and found that SHNAPSHOT is enabled by default,

Save 900 1

Save 300 10

Save 60 10000

Because the cache is used for Session storage, it is not recommended to store snapshots, especially when Redis is a VM machine, which has a great impact on the overall performance.So refer to our Manual notes:

################################ Snapshot ####### ##########################

# Save data to the disk in the following format:

# Save <seconds> <changes>

# Indicates how long and how many update operations are performed, and the data is synchronized to the data file rdb.

# It is equivalent to triggering snapshot capturing by conditions, which can be used with multiple conditions

# For example, three conditions are set in the default configuration file.

# Save 900 1 900 seconds at least one key is changed

# Save 300 10 300 seconds at least 300 keys are changed

# Save 60 10000 at least 10000 keys are changed within 60 seconds

# Comments to all Session cache servers that do not use snapshots

# Save 900 1

# Save 300 10

# Save 60 10000

After restarting Redis, I watched for a month and did not report any performance problems.

In addition, if the PUB/SUB of the client is not used, we recommend that you refer to the following parameters to set the client connection timeout. If this parameter is not used after 300 milliseconds, the server will automatically close the connection, release resources. Disabled by default.

# Set the timeout time for client connection, in seconds. When the client does not send any commands during this period, close the connection.

#0: disable this setting.

#5 minutes are recommended.

Timeout 300

# TCP keepalive

# In Linux, the specified value (in seconds) is used to send ACKs. Note that closing the connection takes double time. The default value is 0.

# Recommended 60.

Tcp-keepalive 60

Note:

Redis 2.8.12 can kill all related connections at one time through the client type.

Introduction to SQL server 2005 badly needed

1. Service enhancements;
2. Database Engine enhancements;
3: Enhanced database access interfaces;
4: Enhanced Functions of Analysis Services;
5. Enhanced Functions of Integration Services;
6: full-text search enhancements;
7. Enhanced Functions of Notification Services;
8: enhanced replication;
9: Enhanced Functions of Reporting Services;
10: Enhanced Functions of tools and tools;

How can flask optimize sqlite performance when writing intensive data?

Not limited to flask. Many applications require such optimization.
1. Use logs instead of databases. For example, use empty_gif of nginx, record a large number of logs, use scripts to import the database in batch or calculate the results, and store the results to the database.
If your data volume is large enough, you should have more than one web server. You need to batch process logs on several machines.
You can save the raw data on s3 and use it as a data warehouse later.
2. memory usage. The memory solution like the queue server or redis is also batch processing data and writing scripts. However, this is subject to the memory size limit, which is expensive and requires frequent execution of scripts.