最新消息:20210816 当前crifan.com域名已被污染,为防止失联,请关注(页面右下角的)公众号

【已解决】crifan.com网站又又又又无法登录后台了

redis crifan 1266浏览 0评论
crifan.com后台又无法登录了。
之前已多次遇到了:
【已解决】crifan.com的WordPress无法登录在wp-login登录页死循环
现在去参考之前过程,搞清楚原因。
先用 SecureCRT的ssh登录后台,看看空间是否满了
[root@crifan ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        79G   25G   51G  33% /
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  201M  1.7G  11% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs           379M     0  379M   0% /run/user/0
不是空间满的问题。
看来还是cookie的问题。
去看看之前如何解决的。
参考
【已解决】WordPress的PHP的log日志出现:PHP message RedisException OOM command not allowed when used memory maxmemory in plugins redis-cache
去看看
[root@crifan ~]# redis-cli
127.0.0.1:6379> info memory
# Memory
used_memory:1073741776
used_memory_human:1024.00M
used_memory_rss:1140920320
used_memory_rss_human:1.06G
used_memory_peak:1081140928
used_memory_peak_human:1.01G
used_memory_peak_perc:99.32%
used_memory_overhead:247427190
used_memory_startup:791200
used_memory_dataset:826314586
used_memory_dataset_perc:77.01%
allocator_allocated:1074155680
allocator_active:1109213184
allocator_resident:1147338752
total_system_memory:3973521408
total_system_memory_human:3.70G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:1073741824
maxmemory_human:1.00G
maxmemory_policy:volatile-lru
allocator_frag_ratio:1.03
allocator_frag_bytes:35057504
allocator_rss_ratio:1.03
allocator_rss_bytes:38125568
rss_overhead_ratio:0.99
rss_overhead_bytes:-6418432
mem_fragmentation_ratio:1.06
mem_fragmentation_bytes:67219568
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:49694
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
其中:
  • used_memory_human:1024.00M
    • =1G
      • 是我们设置的最大的缓存的大小
        • 意思是缓存满了
          • 导致cookie无法保存
            • 导致登录是循环,无法进入后台
但是,之前已设置了:缓存策略,是把旧的抛弃的
看来没生效?
去看看配置:
/usr/local/redis/etc/redis.conf
cat /usr/local/redis/etc/redis.conf | grep maxmemory
输出:
[root@crifan ~]# cat /usr/local/redis/etc/redis.conf | grep maxmemory
# according to the eviction policy selected (see maxmemory-policy).
# WARNING: If you have replicas attached to an instance with maxmemory on,
# limit for maxmemory so that there is some free RAM on the system for replica
# maxmemory <bytes>
# maxmemory 473000000
maxmemory 1073741824
# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# maxmemory-policy noeviction
maxmemory-policy volatile-lru
# maxmemory-samples 5
# Starting from Redis 5, by default a replica will ignore its maxmemory setting
# memory than the one set via maxmemory (there are certain buffers that may
# the configured maxmemory setting.
# replica-ignore-maxmemory yes
# 1) On eviction, because of the maxmemory and maxmemory policy configurations,
#  e     Evicted events (events generated when a key is evicted for maxmemory)
# Redis LFU eviction (see maxmemory setting) can be tuned. However it is a good
已经是
maxmemory-policy volatile-lru
感觉没错啊
去搜:
redis maxmemory-policy volatile not work
caching – Will Redis maxmemory-policy volatile-lru evict if nothing is past expired date? – Stack Overflow
If your eviction policy is set to any of the volatile-* policies, when running out of memory and having no volatile keys to evict, Redis will return an OOM error.
如果此处volatile-lru生效了,那么此处redis内存被占用完毕,则说明:
此处的缓存都没过期,所以一直都在,没有被排除驱逐 到。。。
database – Redis MAXMEMORY management volatile-lru vs allkeys-lru – Stack Overflow
memory – Redis ignores maxmemory setting – Stack Overflow
“Do you have expiration settings on all your keys? volatile-ttl will only remove keys with an expiration set. This should be in your info output.
If you don’t have expiration ttls set try allkeys-lru or allkeys-random for your policy.”
估计我这里就是:全部的key都没有设置expired,所以没有缓存被清除掉,一直增长直到现在占用了1G内存
那就去试试人家说的:
allkeys-lru
allkeys-random
先去找找含义
ttl – Which maxmemory policies allow expiration in Redis? – Stack Overflow
“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.
If you keep the policy at the default ‘noeviction’ or if you choose any of the volatile-* ones without actually having expirable keys in the database, the data will remain in Redis indefinitely.”
说的就是我这种情况
没有设置expirable的key,则就一直放着。。。直到用完内存
allkeys-random:随机的话,有点不合理
allkeys-lru:去找找LRU算法含义
lru算法
Least recently used,最近最少使用
根据数据的历史访问记录来进行淘汰数据,其核心思想是“如果数据最近被访问过,那么将来被访问的几率也更高”。 新数据插入到链表头部; 每当缓存命中(即缓存数据被访问),则将数据移到链表头部; 当链表满的时候,将链表尾部的数据丢弃。
缓存淘汰算法–LRU算法 – 知乎
LRU 缓存淘汰算法详解 – 知乎
LRU 缓存淘汰算法就是一种常用策略。LRU 的全称是 Least Recently Used,也就是说我们认为最近使用过的数据应该是是「有用的」,很久都没用过的数据应该是无用的,内存满了就优先删那些很久没用过的数据。
那就LRU吧。
usr/local/redis/etc/redis.conf
# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> Evict using approximated LRU among the keys with an expire set.
# allkeys-lru -> Evict any key using approximated LRU.
# volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
# allkeys-lfu -> Evict any key using approximated LFU.
# volatile-random -> Remove a random key among the ones 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 evict anything, just return an error on write operations.
#
# LRU means Least Recently Used
# LFU means Least Frequently Used
#
# Both LRU, LFU and volatile-ttl are implemented using approximated
# randomized algorithms.
其实都有解释:
  • LRU means Least Recently Used
  • LFU means Least Frequently Used
usr/local/redis/etc/redis.conf
# maxmemory-policy noeviction
# maxmemory-policy volatile-lru
maxmemory-policy allkeys-lru
确保设置好了
[root@crifan etc]# cat /usr/local/redis/etc/redis.conf | grep maxmemory-policy
# according to the eviction policy selected (see maxmemory-policy).
# maxmemory-policy noeviction
# maxmemory-policy volatile-lru
maxmemory-policy allkeys-lru
然后重启redis
service redis-server restart
期间,等待了很多秒才返回。
估计内部在清理无效的cookie?
貌似没问题。
再去看看当前是内存占用
[root@crifan etc]# redis-cli
127.0.0.1:6379> info
# Server
redis_version:5.0.4
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:48970c8b51251fe5
redis_mode:standalone
os:Linux 3.10.0-957.10.1.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:18187
run_id:18d0d71fba9c743d46867110d1fa4c6bdd4894c7
tcp_port:6379
uptime_in_seconds:127
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:13162076
executable:/usr/local/redis/bin/redis-server
config_file:/usr/local/redis/etc/redis.conf


# Clients
connected_clients:1
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0


# Memory
used_memory:1048363672
used_memory_human:999.80M
used_memory_rss:1078218752
used_memory_rss_human:1.00G
used_memory_peak:1060377680
used_memory_peak_human:1011.25M
used_memory_peak_perc:98.87%
used_memory_overhead:247370670
used_memory_startup:791200
used_memory_dataset:800993002
used_memory_dataset_perc:76.46%
allocator_allocated:1048583416
allocator_active:1066369024
allocator_resident:1086386176
total_system_memory:3973521408
total_system_memory_human:3.70G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:1073741824
maxmemory_human:1.00G
maxmemory_policy:allkeys-lru
allocator_frag_ratio:1.02
allocator_frag_bytes:17785608
allocator_rss_ratio:1.02
allocator_rss_bytes:20017152
rss_overhead_ratio:0.99
rss_overhead_bytes:-8167424
mem_fragmentation_ratio:1.03
mem_fragmentation_bytes:29897336
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:49694
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0


# Persistence
loading:0
rdb_changes_since_last_save:1717
rdb_bgsave_in_progress:0
rdb_last_save_time:1606997562
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:18
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:26120192
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
aof_last_cow_size:0


# Stats
total_connections_received:180
total_commands_processed:12978
instantaneous_ops_per_sec:16
total_net_input_bytes:26399488
total_net_output_bytes:84413520
instantaneous_input_kbps:1.65
instantaneous_output_kbps:138.66
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:12224
keyspace_misses:468
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:24467
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0


# Replication
role:master
connected_slaves:0
master_replid:57508adf62f3298cd8c8ad657719e2978bacbcd8
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0


# CPU
used_cpu_sys:1.918026
used_cpu_user:8.740703
used_cpu_sys_children:1.705528
used_cpu_user_children:14.890031


# Cluster
cluster_enabled:0


# Keyspace
db0:keys=4485316,expires=174,avg_ttl=86103394
和:
127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "1073741824"
127.0.0.1:6379> config get maxmemory-policy
1) "maxmemory-policy"
2) "allkeys-lru"
127.0.0.1:6379> config get maxmemory-samples
1) "maxmemory-samples"
2) "5"
其中:
  • used_memory_human:999.80M
    • 没有完全占满1G
      • 说明是刚才重启redis时,根据最新策略allkeys-lru去清理了一部分cookie了
现在再去登录后台,估计就可以了。
果然可以了。
【总结】
此处登录WordPress后台,又在wp-login死循环了。
后来找到原因了:
之前虽然给redis设置了
/usr/local/redis/etc/redis.conf
maxmemory-policy volatile-lru
但是:
此处WordPress产生的所有的cookie,貌似都是没expire方面的值的-》即 都没有过期的设 置 -》 永远不会过期 
导致cookie一直增加,直到占用了所允许的最大内存
注:此处设置是1G
/usr/local/redis/etc/redis.conf
maxmemory 1073741824
解决办法:
把驱逐evict策略改为(不带volatile的)allkeys
  • allkeys-lru
    • Evict any key using approximated LRU
      • LRU=Least Recently Used=最近最少使用
  • allkeys-lfu
    • Evict any key using approximated LFU
  • allkeys-random
    • Remove a random key, any key
具体设置办法:
编辑配置文件:
/usr/local/redis/etc/redis.conf
改为:
maxmemory-policy allkeys-lru
即可。
附录:
(1)redis管理命令
  • 重启
    • service redis-server restart
  • 查看状态
    • service redis-server status
(2)redis相关命令:
  • 进入命令行
    • redis-cli
  • 查看 全部信息
    • info
    • 举例
      • 查看某方面 section的信息
        • 查看内存信息
          • info memory
  • 查看配置信息:
    • config get
    • 举例
      • 最大内存:maxmemory
        • config get maxmemory
      • 最大内存(超过时的)驱逐策略:maxmemory-policy
        • config get maxmemory-policy
      • samples
        • config get maxmemory-samples

转载请注明:在路上 » 【已解决】crifan.com网站又又又又无法登录后台了

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
82 queries in 0.203 seconds, using 22.10MB memory