未解决的问题

persistence-available no  #不用持久化
maxmemory 4gb              #内存限制
maxmemory-policy volatile-lru #内存满时，删除设置了超时时间的那些key的最近最久没有使用的#save 900 1  #还注释了这三行，这是rdb满足什么条件执行持久化，我觉得有上面的配置这个不注释也可以
#save 300 10
#save 60 10000

这样配置会报这样的错误

persistence-available [no]

这样不会报错，但我感觉不应该用中括号？
不过把save注释掉，也就不会执行持久化了。

问题1

以前遇到过一个问题，但redis日志没有记录下来，只有应用程序的日志：

[search-service][ERROR] [2018-02-05 14:24:53] com.pyc.redis.RedisClient.hexists(363) | redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out[search-service][ERROR] [2018-02-05 04:48:32] com.pyc.redis.RedisClient.hgetAll(395) | redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out[search-service][ERROR] [2018-02-05 11:50:30] com.pyc.redis.RedisClient.exists(174) | redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

检查程序发现，jedis实例没有正确关闭导致的。
原来是jedisPool.returnResource(jedis);
后来是jedis.close();

应用程序响应时间特别的慢，redis.conf配置文件中redis.pool.maxWait=3000（单位毫秒）的意思是最大建立连接等待时间。本来没有redis，程序就比较慢，再去建立一个不能响应的连接就更耗时了。

补充一句，如果redis报错，程序会处理这个错误，简单的记录到日志中，所以应用服务会绕过redis缓存，直接操作数据库，应用程序速度会变慢，但不会停止服务。

/*** 判断key值是否存在* @author zhouna* @data 2017年11月20日 上午11:29:01** @param key* @return*/
public static boolean exists(String key) {Jedis jedis = null;try {jedis = jedisPool.getResource();return jedis.exists(key);} catch (Exception e) {logger.error(e+" exists(key:"+key+")", e);return false;} finally {if (jedis != null) { jedis.close(); }}
}

可以通过修改配置文件可以将日志记录下来：
logfile E:/redis-2.4.5-win32-win64/64bit/redis-log.txt
并且在启动redis时带上配置文件名，否则就是默认配置文件，默认配置文件不是当前目录下的配置文件。

问题2

程序错误日志

[search-service][ERROR] [2018-02-18 23:59:59] com.pyc.redis.RedisClient.hset(435) | redis.clients.jedis.exceptions.JedisDataException: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error. hset(key:LIST_PRODUCT_FILTERED_STORE, field:######, value:[com.pyc.search.searchservice.model.Product@3bfa36d4,
....]
redis.clients.jedis.exceptions.JedisDataException: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.at redis.clients.jedis.Protocol.processError(Protocol.java:113)at redis.clients.jedis.Protocol.process(Protocol.java:138)at redis.clients.jedis.Protocol.read(Protocol.java:192)at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:282)at redis.clients.jedis.Connection.getIntegerReply(Connection.java:207)at redis.clients.jedis.Jedis.hset(Jedis.java:585)at com.pyc.redis.RedisClient.hset(RedisClient.java:432)at com.pyc.search.searchservice.core.SearchResult.getResultFromTopDocsFilteredByStore(SearchResult.java:476)

redis窗口

[8288] 28 Feb 10:09:25.406 # fork operation complete
[8288] 28 Feb 10:09:25.855 # Background saving error
[8288] 28 Feb 10:09:25.956 * 1 changes in 3600 seconds. Saving...
[8288] 28 Feb 10:09:26.176 * Background saving started by pid 9148
[9148] 28 Feb 10:09:50.334 # Write error saving DB on disk: No space left on dev
ice
[9148] 28 Feb 10:09:50.608 # rdbSave failed in qfork: No space left on device
[8288] 28 Feb 10:09:50.645 # fork operation complete
[8288] 28 Feb 10:09:51.349 # Background saving error
[8288] 28 Feb 10:09:51.450 * 1 changes in 3600 seconds. Saving...
[8288] 28 Feb 10:09:51.694 * Background saving started by pid 8540
[8540] 28 Feb 10:10:18.171 # Write error saving DB on disk: No space left on dev
ice
[8540] 28 Feb 10:10:18.446 # rdbSave failed in qfork: No space left on device
[8288] 28 Feb 10:10:18.525 # fork operation complete
[8288] 28 Feb 10:10:19.129 # Background saving error
[8288] 28 Feb 10:10:19.231 * 1 changes in 3600 seconds. Saving...
[8288] 28 Feb 10:10:19.468 * Background saving started by pid 7680
[7680] 28 Feb 10:10:47.166 # Write error saving DB on disk: No space left on dev
ice

问题分析：

程序重新启动后，黑窗口的日志显示：

[6820] 28 Feb 10:29:02.913 # Warning: no config file specified, using the defaul
t config. In order to specify a config file use C:\Redis-x64-3.2.100\redis-serve
r.exe /path/to/redis.conf_.__.-``__ ''-.__.-``    `.  `_.  ''-._           Redis 3.2.100 (00000000/0) 64 bit.-`` .-```.  ```\/    _.,_ ''-._(    '      ,       .-`  | `,    )     Running in standalone mode|`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379|    `-._   `._    /     _.-'    |     PID: 6820`-._    `-._  `-./  _.-'    _.-'|`-._`-._    `-.__.-'    _.-'_.-'||    `-._`-._        _.-'_.-'    |           http://redis.io`-._    `-._`-.__.-'_.-'    _.-'|`-._`-._    `-.__.-'    _.-'_.-'||    `-._`-._        _.-'_.-'    |`-._    `-._`-.__.-'_.-'    _.-'`-._    `-.__.-'    _.-'`-._        _.-'`-.__.-'[6820] 28 Feb 10:29:02.921 # Server started, Redis version 3.2.100
[6820] 28 Feb 10:29:02.921 * The server is now ready to accept connections on po
rt 6379
[6820] 28 Feb 10:34:03.039 * 100 changes in 300 seconds. Saving...
[6820] 28 Feb 10:34:03.048 * Background saving started by pid 7904
[6820] 28 Feb 10:34:04.251 # fork operation complete
[6820] 28 Feb 10:34:04.266 * Background saving terminated with success
[6820] 28 Feb 10:39:05.069 * 100 changes in 300 seconds. Saving...
[6820] 28 Feb 10:39:05.081 * Background saving started by pid 6552
[6820] 28 Feb 10:39:06.789 # fork operation complete
[6820] 28 Feb 10:39:06.811 * Background saving terminated with success
[6820] 28 Feb 10:44:07.085 * 100 changes in 300 seconds. Saving...
[6820] 28 Feb 10:44:07.103 * Background saving started by pid 9012
[6820] 28 Feb 10:44:09.307 # fork operation complete
[6820] 28 Feb 10:44:09.332 * Background saving terminated with success
[6820] 28 Feb 10:49:10.054 * 100 changes in 300 seconds. Saving...
[6820] 28 Feb 10:49:10.072 * Background saving started by pid 6560
[6820] 28 Feb 10:49:13.181 # fork operation complete
[6820] 28 Feb 10:49:13.214 * Background saving terminated with success
[6820] 28 Feb 10:54:14.022 * 100 changes in 300 seconds. Saving...
[6820] 28 Feb 10:54:14.041 * Background saving started by pid 7752
[6820] 28 Feb 10:54:17.044 # fork operation complete
[6820] 28 Feb 10:54:17.108 * Background saving terminated with success
[6820] 28 Feb 10:59:18.043 * 100 changes in 300 seconds. Saving...
[6820] 28 Feb 10:59:18.065 * Background saving started by pid 7864
[6820] 28 Feb 10:59:22.486 # fork operation complete
[6820] 28 Feb 10:59:22.515 * Background saving terminated with success
[6820] 28 Feb 11:04:23.039 * 100 changes in 300 seconds. Saving...
[6820] 28 Feb 11:04:23.065 * Background saving started by pid 6120
[6820] 28 Feb 11:04:27.085 # fork operation complete
[6820] 28 Feb 11:04:27.161 * Background saving terminated with success
[6820] 28 Feb 11:09:28.005 * 100 changes in 300 seconds. Saving...

redis客户端执行info命令：

# Persistence
loading:0
rdb_changes_since_last_save:83
rdb_bgsave_in_progress:0
rdb_last_save_time:1519797880
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:15
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

配置文件中关于快照（也是rdb）的配置：

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""save 900 1
save 300 10
save 60 10000# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes# The filename where to dump the DB
dbfilename dump.rdb

关于LIMITS的配置：

################################### LIMITS ####################################
# If Redis is to be used as an in-memory-only cache without any kind of
# persistence, then the fork() mechanism used by the background AOF/RDB
# persistence is unnecessary. As an optimization, all persistence can be
# turned off in the Windows version of Redis. This will redirect heap
# allocations to the system heap allocator, and disable commands that would
# otherwise cause fork() operations: BGSAVE and BGREWRITEAOF.
# This flag may not be combined with any of the other flags that configure
# AOF and RDB operations.
# persistence-available [(yes)|no]# Don't use more memory than the specified amount of bytes.
# When the memory limit is reached Redis will try to remove keys
# according to the eviction policy selected (see maxmemory-policy).
#
# If Redis can't remove keys according to the policy, or if the policy is
# set to 'noeviction', Redis will start to reply with errors to commands
# that would use more memory, like SET, LPUSH, and so on, and will continue
# to reply to read-only commands like GET.
#
# This option is usually useful when using Redis as an LRU cache, or to set
# a hard memory limit for an instance (using the 'noeviction' policy).
#
# WARNING: If you have slaves attached to an instance with maxmemory on,
# the size of the output buffers needed to feed the slaves are subtracted
# from the used memory count, so that network problems / resyncs will
# not trigger a loop where keys are evicted, and in turn the output
# buffer of slaves is full with DELs of keys evicted triggering the deletion
# of more keys, and so forth until the database is completely emptied.
#
# In short... if you have slaves attached it is suggested that you set a lower
# limit for maxmemory so that there is some free RAM on the system for slave
# output buffers (but this is not needed if the policy is 'noeviction').
#
# WARNING: not setting maxmemory will cause Redis to terminate with an
# out-of-memory exception if the heap limit is reached.
#
# NOTE: since Redis uses the system paging file to allocate the heap memory,
# the Working Set memory usage showed by the Windows Task Manager or by other
# tools such as ProcessExplorer will not always be accurate. For example, right
# after a background save of the RDB or the AOF files, the working set value
# may drop significantly. In order to check the correct amount of memory used
# by the redis-server to store the data, use the INFO client command. The INFO
# command shows only the memory used to store the redis data, not the extra
# memory used by the Windows process for its own requirements. Th3 extra amount
# of memory not reported by the INFO command can be calculated subtracting the
# Peak Working Set reported by the Windows Task Manager and the used_memory_peak
# reported by the INFO command.
#
# maxmemory <bytes># MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> remove the key with an expire set using an LRU algorithm
# allkeys-lru -> remove any key according to the LRU algorithm
# volatile-random -> remove a random key with an expire set
# allkeys-random -> remove a random key, any key
# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
# noeviction -> don't expire at all, just return an error on write operations
#
# Note: with any of the above policies, Redis will return an error on write
#       operations, when there are no suitable keys for eviction.
#
#       At the date of writing these commands are: set setnx setex append
#       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
#       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
#       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
#       getset mset msetnx exec sort
#
# The default is:
#
# maxmemory-policy noeviction# LRU and minimal TTL algorithms are not precise algorithms but approximated
# algorithms (in order to save memory), so you can tune it for speed or
# accuracy. For default Redis will check five keys and pick the one that was
# used less recently, you can change the sample size using the following
# configuration directive.
#
# The default of 5 produces good enough results. 10 Approximates very closely
# true LRU but costs a bit more CPU. 3 is very fast but not very accurate.
#
# maxmemory-samples 5

从上面的配置可以看到：
# persistence-available [(yes)|no]可以看出默认是有持久化的。
# maxmemory <bytes>默认是没有指定的，需要注意的是，不指定最大内存，当heap达到最大限制时，会使Redis停止服务，报内存溢出错误。

从以上信息可以看出，redis采用的是默认的rdb持久化方式，300秒内有最少100个key改变就fork一个子进程，保存一个快照。并且stop-writes-on-bgsave-error yes的意思是如果快照保存出错，就不能写了，这样设置是为了让用户能注意到出错了。

现象：
dump.rdb在长时间运行后就会很大，有将近3G，磁盘空间不够，就会报错，这时候redis就不能用了。

问题原因：
redis服务用的是默认的配置，所以会使用rdb的持久化方式，因为保存频繁，所以基本5分钟就执行一次保存快照操作。而且没有指定最大内存，所以内存的数据会不断积累，越来越多。
会导致两种错误：

内存堆满了，redis停止写服务，报内存溢出错误。（对读操作可以响应）；（rdb保存快照的方式是fork一个子进程，将这个子进程内存冻结，将快照保存到磁盘文件。如果内存文件很大，这个过程可能会导致内存不足，不能完成保存快照操作。）
硬盘空间不足，不能完成rdb snapshot操作。

无论哪种错误都会导致rdb保存快照失败，stop-writes-on-bgsave-error yes默认配置就会使redis不能进行写操作了。

解决方法：我的应用需求是将redis作为缓存，提供查询速度，所以不需要持久化。

要修改以下配置：

persistence-available [no]
maxmemory 1gb
maxmemory-policy volatile-lru

LRU参考：http://blog.csdn.net/zdy0_2004/article/details/44685615

问题3

[search-service][ERROR] [2018-03-01 17:06:21] com.pyc.redis.RedisClient.hset(435) | redis.clients.jedis.exceptions.JedisDataException: OOM command not allowed when used memory > 'maxmemory'. hset(key:LIST_PRODUCT_FILTERED_STORE, field:######, value:[com.pyc.search.searchservice.model.Product@65726388, ...])
redis.clients.jedis.exceptions.JedisDataException: OOM command not allowed when used memory > 'maxmemory'.
    at redis.clients.jedis.Protocol.processError(Protocol.java:113)
    at redis.clients.jedis.Protocol.process(Protocol.java:138)
    at redis.clients.jedis.Protocol.read(Protocol.java:192)
    at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:282)
    at redis.clients.jedis.Connection.getIntegerReply(Connection.java:207)
    at redis.clients.jedis.Jedis.hset(Jedis.java:585)

redis配置：

persistence-available [no]  #不用持久化
maxmemory 4gb              #内存限制
maxmemory-policy volatile-lru #内存满时，删除设置了超时时间的那些key的最近最久没有使用的#save 900 1  #还注释了这三行，这是rdb满足什么条件执行持久化，我觉得有上面的配置这个不注释也可以
#save 300 10
#save 60 10000

出错时的redis的状态：

127.0.0.1:6379> info
# Server
redis_version:3.2.100
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:dd26f1f93c5130ee
redis_mode:standalone
os:Windows
arch_bits:64
multiplexing_api:WinSock_IOCP
process_id:6132
run_id:ca69b4642f4943f43dc99f1d7ee0f4adde528038
tcp_port:6379
uptime_in_seconds:138401
uptime_in_days:1
hz:10
lru_clock:10010362
executable:C:\Redis-x64-3.2.100\redis-server.exe
config_file:C:\Redis-x64-3.2.100\redis.windows.conf# Clients
connected_clients:4
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0# Memory
used_memory:4294977896
used_memory_human:4.00G
used_memory_rss:4294939984
used_memory_rss_human:4.00G
used_memory_peak:4323578712
used_memory_peak_human:4.03G
total_system_memory:0
total_system_memory_human:0B
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:4294967296
maxmemory_human:4.00G
maxmemory_policy:volatile-lru
mem_fragmentation_ratio:1.00
mem_allocator:jemalloc-3.6.0# Persistence
loading:0
rdb_changes_since_last_save:30674
rdb_bgsave_in_progress:0
rdb_last_save_time:1519821401
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok# Stats
total_connections_received:1251
total_commands_processed:446556
instantaneous_ops_per_sec:7
total_net_input_bytes:50578259311
total_net_output_bytes:24575616983
instantaneous_input_kbps:641.12
instantaneous_output_kbps:0.07
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:1
evicted_keys:0
keyspace_hits:318536
keyspace_misses:3341
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
migrate_cached_sockets:0# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0# CPU
used_cpu_sys:197.59
used_cpu_user:57.95
used_cpu_sys_children:0.00
used_cpu_user_children:0.00# Cluster
cluster_enabled:0# Keyspace
db0:keys=5,expires=0,avg_ttl=0
127.0.0.1:6379> keys *
1) "IMEIKEYWORDS"
2) "HDIDKEYWORDS"
3) "ACCOUNTIDKEYWORDS"
4) "LIST_PRODUCT_FILTERED_STORE"
127.0.0.1:6379>

原因：
通过keys *查看发现只有4个key值，都是用的hash方式存储的。

其中前三个都设置了过期时间，而且占用内存也不多，配置文件中maxmemory-policy volatile-lru，这样设置的意思是内存满时，删除设置了过期时间的key的最近最久未使用的key。

第四个key值，它占用了大部分的内存。但它没有设置过期时间，内存满了，它不会被删除；

这样用缓存就感觉不合理了。

127.0.0.1:6379> keys *
1) "IMEIKEYWORDS"
2) "HDIDKEYWORDS"
3) "ACCOUNTIDKEYWORDS"
4) "LIST_PRODUCT_FILTERED_STORE"
127.0.0.1:6379>

前三个是一些字典数据，第四个是用户查询的缓存。

解决方法：

可以将”LIST_PRODUCT_FILTERED_STORE”不用hash方式存储，用普通的key-value存储。
还有个问题，缓存中的数据有两种，一种是词典类的数据，这种数据不经常变换，也不很大；另一类是用户查询的数据，这些数据索引变化就需要删除。
原来之所以用hash方式存储用户查询的数据，是因为索引变化时只删除这些数据，词典类的数据不要删除，词典类的数据设置了过期时间。如果索引变化频繁的话，词典数据就要经常加载。
所以要将这两类数据放到不同的数据中。

jedis.flushDB();
jedis.select(index);

参考里面的一句话：http://blog.csdn.net/liqfyiyi/article/details/50894004

redis基本信息：

127.0.0.1:6379> info
# Server
redis_version:3.2.100
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:dd26f1f93c5130ee
redis_mode:standalone
os:Windows
arch_bits:64
multiplexing_api:WinSock_IOCP
process_id:6820
run_id:bc443b186a0cbe385ffd08e92f5426df0984c3c3
tcp_port:6379
uptime_in_seconds:13131
uptime_in_days:0
hz:10
lru_clock:9848633
executable:C:\Redis-x64-3.2.100\redis-server.exe
config_file:# Clients
connected_clients:2
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0# Memory
used_memory:1214067248
used_memory_human:1.13G
used_memory_rss:1214029464
used_memory_rss_human:1.13G
used_memory_peak:1214623376
used_memory_peak_human:1.13G
total_system_memory:0
total_system_memory_human:0B
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.00
mem_allocator:jemalloc-3.6.0# Persistence
loading:0
rdb_changes_since_last_save:83
rdb_bgsave_in_progress:0
rdb_last_save_time:1519797880
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:15
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok# Stats
total_connections_received:71
total_commands_processed:49988
instantaneous_ops_per_sec:8
total_net_input_bytes:4068778490
total_net_output_bytes:3125211763
instantaneous_input_kbps:358.33
instantaneous_output_kbps:325.87
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:38329
keyspace_misses:514
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:90450
migrate_cached_sockets:0# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0# CPU
used_cpu_sys:27.89
used_cpu_user:5.48
used_cpu_sys_children:0.00
used_cpu_user_children:0.00# Cluster
cluster_enabled:0# Keyspace
db0:keys=5,expires=0,avg_ttl=0
127.0.0.1:6379>

REDIS BUG REPORT

=== REDIS BUG REPORT START: Cut & paste starting from here ===
Redis version: 3.2.100
[1540] 27 Feb 15:39:03.707 # --- EXCEPTION_ACCESS_VIOLATION
[1540] 27 Feb 15:39:03.709 # --- STACK TRACE
redis-server.exe!LogStackTrace(c:\release\redis\src\win32_interop\win32_stacktra
ce.cpp:95)(0x000BE1C0, 0x0013FF90, 0x00000001, 0x4013A7F8)
redis-server.exe!UnhandledExceptiontHandler(c:\release\redis\src\win32_interop\w
in32_stacktrace.cpp:185)(0x00000000, 0x00000000, 0x00000000, 0x00000000)
KERNELBASE.dll!UnhandledExceptionFilter(c:\release\redis\src\win32_interop\win32
_stacktrace.cpp:185)(0x00000000, 0xD11B1AA0, 0x00000000, 0x0013FF20)
ntdll.dll!memset(c:\release\redis\src\win32_interop\win32_stacktrace.cpp:185)(0x
000BEDF0, 0x00000000, 0x40140E48, 0x00000000)
ntdll.dll!_C_specific_handler(c:\release\redis\src\win32_interop\win32_stacktrac
e.cpp:185)(0x00000000, 0x000BE330, 0x000BEDF0, 0x000BEDF0)
ntdll.dll!_chkstk(c:\release\redis\src\win32_interop\win32_stacktrace.cpp:185)(0
x00000001, 0xD3BC0000, 0x00000000, 0xD3CF309C)
ntdll.dll!RtlRaiseException(c:\release\redis\src\win32_interop\win32_stacktrace.
cpp:185)(0x00000000, 0x00000000, 0x00000000, 0x00000000)
ntdll.dll!KiUserExceptionDispatcher(c:\release\redis\src\win32_interop\win32_sta
cktrace.cpp:185)(0x80000000, 0x00000000, 0x8D3FFFE9, 0x8D2EEDB0)
redis-server.exe!lzf_compress(c:\release\redis\src\lzf_c.c:206)(0x8C92E5BA, 0x8C
92E5BA, 0x00000073, 0x0013F2E0)
redis-server.exe!rdbSaveLzfStringObject(c:\release\redis\src\rdb.c:282)(0x8C92E5
BA, 0x0013F2E0, 0x12872774, 0x86A04009)
redis-server.exe!rdbSaveRawString(c:\release\redis\src\rdb.c:349)(0x03C07070, 0x
128726FF, 0x5977AB47, 0x0086AEE0)
redis-server.exe!rdbSaveObject(c:\release\redis\src\rdb.c:678)(0x00000002, 0x001
3F2E0, 0x0013F2E0, 0x00000001)
redis-server.exe!rdbSaveKeyValuePair(c:\release\redis\src\rdb.c:721)(0x0013F2E0,0x00000001, 0x0013F2E0, 0x03C07040)
redis-server.exe!rdbSaveRio(c:\release\redis\src\rdb.c:814)(0x40167210, 0x01B000
00, 0x00000005, 0x01F02754)
redis-server.exe!rdbSave(c:\release\redis\src\rdb.c:884)(0x01B00000, 0x01B00000,0x5A97FEC8, 0x00000005)
redis-server.exe!QForkChildInit(c:\release\redis\src\win32_interop\win32_qfork.c
pp:337)(0x00000005, 0x00000000, 0x00266BE0, 0x00000005)
redis-server.exe!QForkStartup(c:\release\redis\src\win32_interop\win32_qfork.cpp
:515)(0x00000006, 0x00000000, 0xFFFF6000, 0x002679F0)
redis-server.exe!main(c:\release\redis\src\win32_interop\win32_qfork.cpp:1240)(0
x00000000, 0x00000000, 0x00000000, 0xFFFF6000)
redis-server.exe!__tmainCRTStartup(f:\dd\vctools\crt\crtw32\startup\crt0.c:255)(
0x00000000, 0x400459C0, 0x00000000, 0x00000000)
KERNEL32.DLL!BaseThreadInitThunk(f:\dd\vctools\crt\crtw32\startup\crt0.c:255)(0x
D1BD13B0, 0x00000000, 0x00000000, 0x00000000)
ntdll.dll!RtlUserThreadStart(f:\dd\vctools\crt\crtw32\startup\crt0.c:255)(0x0000
0000, 0x00000000, 0x00000000, 0x00000000)
ntdll.dll!RtlUserThreadStart(f:\dd\vctools\crt\crtw32\startup\crt0.c:255)(0x0000
0000, 0x00000000, 0x00000000, 0x00000000)
[1540] 27 Feb 15:39:03.753 # --- INFO OUTPUT

redis服务器错误日志分析相关推荐

使用elk+redis搭建nginx日志分析平台（引）
http://www.cnblogs.com/yjf512/p/4199105.html elk+redis 搭建nginx日志分析平台 logstash,elasticsearch,kibana 怎 ...
nginx服务器access_log日志分析及配置详解
本博客转载于:http://www.pythontab.com/html/2013/linuxkaiyuan_0104/96.html nginx的log日志分为access log 和 error ...
ELK+redis搭建nginx日志分析平台
ELK+redis搭建nginx日志分析平台发表于 2015-08-19 | 分类于 Linux/Unix | ELK简介 ELKStack即Elasticsearch + Logs ...
华为服务器提示错误信息,服务器错误日志
服务器错误日志内容精选换一换为加强对数据的容灾管理,云堡垒机支持手动备份和配置日志远程备份,提高审计数据安全性和系统可扩展性.通过手动导出/下载各功能模块数据文件保存在本地,可手动备份日志请参见 ...
Linux与云计算——第二阶段Linux服务器架设第七章：网站WEB服务器架设—日志分析平台...
Linux与云计算--第二阶段Linux服务器架设第七章:网站WEB服务器架设-日志分析平台日志分析:AWstats 安装AWstats分析http日志信息. [1] Install AWstat ...
linux var mqm权限,Linux MQ中间件/var/mqm文件系统结构与错误日志分析
Linux MQ中间件/var/mqm文件系统结构与错误日志分析 Linux MQ中间件/var/mqm文件系统结构与错误日志分析本文转自 http://www.wo81.com/tec/mid/m ...
安装数据库显示参考服务器错误日志,Sql Server安装出错,安装程序配置服务器失败的解决方法小结...
错误重现:首先在控制面板里卸载了sqlserver软件,一切正常,然后重启(一定要重启,否则没法重装),执行sqlserver的安装程序,一切似乎都正常,一路下一步,安装到了最后,突然提示" ...
nginx 错误日志分析
一.Nginx配置和内核优化实现突破十万并发二.一次Nignx的502页面的错误记录 (1)错误页面显示错误日志: 2017/07/17 17:32:57 [error] 29071#0: *9 ...
技术分享 | OceanBase 错误日志分析
作者:操盛春技术专家,任职于爱可生,专注研究 MySQL.Ocean Base 源码. 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源. Ocean ...

redis服务器错误日志分析