Genom att använda StackExchange.Redis för att manipulera redis-cachen är felet följande:
StackExchange.Redis.RedisServerException: 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.
Tillfällig lösning, modifiera filen redis.windows.conf,Redis-tjänsten behöver återupptas, sätter enligt följande:
Om du inte vill starta om Redis-tjänsten kan du använda kommandot redis-cli för att ställa in det på följande sätt:
Förklaringen är följande:
# Som standard slutar Redis att acceptera skrivningar om RDB-snapshots är aktiverade
# (minst en sparpunkt) och den senaste bakgrundssparningen misslyckades.
# Detta gör användaren medveten (på ett hårt sätt) om att data inte finns kvar
# på skivan ordentligt, annars är chansen stor att ingen märker det och lite till
# katastrof kommer att inträffa.
#
# Om bakgrundssparningsprocessen börjar fungera igen kommer Redis att göra det
# tillåter automatiskt skrivningar igen.
#
# Men om du har satt upp din korrekta övervakning av Redis-servern
# och persistens, kan du vilja inaktivera denna funktion så att Redis gör det
# fortsätt arbeta som vanligt även om det finns problem med disken,
# tillstånd, och så vidare. Enkelt uttryckt: Redis behöver forka en huvudprocess för att undvika att huvudprocessen fejkar död vid sparning av data på hårddisken, och sedan slutföra processen att spara data till hårddisken i forkprocessen, om huvudprocessen använder 4 GB minne behövs ytterligare 4 GB när fork-delprocessen behövs, då är minnet inte tillräckligt, forken misslyckas och sedan misslyckas även datasparande hårddisken.
För att se redis-loggarna måste du konfigurera redis.windows.conf enligt följande:
# Ange loggfilens namn. Dessutom kan 'stdout' användas för att tvinga fram
# Redis för att logga in på standardutgången.
loggfil "E:/Redis-x64-3.2.100/redis.txt"
Log-undantagen är följande:
[8984] 14 maj 14:05:09.060 * Bakgrundssparning startad av pid 8672
[8672] 14 maj 14:05:09.169 #
Windows-versionen av Redis reserverar heapminne från systemets sidfil.
för delning med den förgrenade processen som används för persistensoperationer. Just nu finns det otillräckligt med sammanhängande ledigt utrymme tillgängligt i
Systemsidningsfil. Du kan öka storleken på systemets sidfil.
Ibland kan en omstart defragmentera systemets sidsökningsfil tillräckligt för att
Denna operation slutfördes framgångsrikt.
Redis kan inte fortsätta. Går ut.
[8984] 14 maj 14:05:09.278 # gaffeloperationen misslyckades
Efter analys visade det sig att problemet med den maximala heapstorleken "maxheap"-konfigurationen berodde på otillräckligt tillgängligt minne.
Lösning
Öppna Redis konfigurationsfil "redis.windows.conf" och hitta följande kodsektion:
# Redis-heapen måste vara större än värdet som anges av maxmemory
# flagga, eftersom heap-allokatorn har sina egna minneskrav och
# Fragmentering av högen är oundviklig. Om bara maxmemory-flaggan är
# specificerat kommer maxheap att sättas till 1,5*maxminne. Om maxheap-flaggan är
# specificeras tillsammans med maxmemory, maxheap-flaggan kommer automatiskt att vara
# ökar om den är mindre än 1,5*maxminne.
#
# maxheap <bytes>
Att lägga till denna inställning är bra,Redis-tjänsten startar inte！！！！！！！
Standardvärdet är: maxheap 10240000000≈976,56M
Jag hittade inte den här kommentaren i konferensfilen, jag hittade något i stil med detta:
# Använd inte mer minne än det angivna antalet bytes.
# När minnesgränsen är nådd kommer Redis att försöka ta bort nycklar
# enligt den valda vräkningspolicyn (se maxmemory-policy).
#
# Om Redis inte kan ta bort nycklar enligt policyn, eller om policyn är
# inställd på 'noeviction', kommer Redis att börja svara med fel på kommandon
# som skulle använda mer minne, som SET, LPUSH och så vidare, och kommer att fortsätta
# för att svara på skrivskyddade kommandon som GET.
#
# Detta alternativ är vanligtvis användbart när man använder Redis som LRU-cache eller för att sätta
# en hård minnesgräns för en instans (med hjälp av 'noeviction'-policyn).
#
# VARNING: Om du har slavar kopplade till en instans med maxmemory aktiverat,
# storleken på de utgångsbuffertar som behövs för att mata slavarna dras av
# från det använda minnesantalet, så att nätverksproblem / omsynkroniseringar kommer
# inte trigga en loop där nycklar kastas ut, och i sin tur utgången
# buffert av slavar är full av DELs av nycklar som utkastats vilket utlöser raderingen
# av fler nycklar, och så vidare tills databasen är helt tömd.
#
# Kort sagt... Om du har slavar fästa rekommenderas det att du sätter en lägre
# gräns för maxminne så att det finns lite ledigt RAM på systemet för slave
# utmatningsbuffertar (men detta behövs inte om policyn är 'noeviction').
#
# VARNING: om du inte sätter maxmemory kommer Redis att avsluta med en
# undantag utanför minnet om heapgränsen nås.
#
# NOTERA: eftersom Redis använder systemets sidfil för att allokera heapminnet,
# minnesanvändningen i arbetssetet visas av Windows Aktivitetshanteraren eller av andra
# verktyg som ProcessExplorer kommer inte alltid att vara exakta. Till exempel, höger
# efter en bakgrundssparning av RDB- eller AOF-filerna, fungerar arbetsmängdsvärdet
# kan sjunka avsevärt. För att kontrollera rätt mängd minne som används
# av redis-servern för att lagra datan, använd INFO-klientkommandot. INFORMATIONEN
# kommando visar bara minnet som användes för att lagra redis-data, inte det extra
# minne som används av Windows-processen för sina egna behov. Th3 extra mängd
# av minne som inte rapporteras av INFO-kommandot kan beräknas genom att subtrahera
# Peak Working Set rapporteras av Windows Aktivitetshanteraren och used_memory_peak
# rapporterat av INFO-kommandot.
#
# maxminne <bytes>
Varning: Om heapgränsen nås kommer utebliven maxminnesinställning att leda till att Redis avslutas med ett minnesutsläpp.
Not: På grund avRedis använder systemsidfiler för att allokera heapminne，
Windows Aktivitetshanteraren eller andra verktyg som ProcessExplorer visar inte alltid korrekt användning av arbetsenhetens minne. Enkelt uttryckt,Minnesanvändningen som visas av Aktivitetshanteraren är inte korrekt！！！
Använd info-kommandot för att fråga enligt följande:
# Minne
used_memory:2011338768
used_memory_human:1,87G
used_memory_rss:2011279992
used_memory_rss_human:1,87G
used_memory_peak:2011338768
used_memory_peak_human:1,87G
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: Ingen vräkning
mem_fragmentation_ratio:1.00
mem_allocator:jemalloc-3.6.0
Inställningarna är följande:
1073741824 byte = 1G
Efter inställningen lägger redis .net-klienten till ett cachefel enligt följande:
OOM-kommandot tillåts inte när minnet används > 'maxmemory'. # MAXMEMORY POLICY: hur Redis väljer vad som ska tas bort när maxmemory
# är nådd. Du kan välja mellan fem beteenden:
#
# flyktig-lru -> ta bort nyckeln med en förfallsmängd med hjälp av en LRU-algoritm
# allkeys-lru -> ta bort vilken nyckel som helst enligt LRU-algoritmen
# flyktig-slumpmässig -> ta bort en slumpmässig nyckel med en förfallsuppsättning
# allkeys-random -> ta bort en slumpmässig nyckel, vilken nyckel som helst
# volatile-ttl -> ta bort nyckeln med närmaste utgångstid (minor TTL)
# Noeviction -> går inte ut alls, bara ett fel vid skrivoperationer
#
# Notera: med någon av ovanstående policyer kommer Redis att returnera ett felmeddelande vid skrivning
# Operationer, när det inte finns några lämpliga nycklar för vräkning.
#
# Vid skrivdatumet är dessa kommandon: set setnx setex append
# Incr decr rpush lpush rpushx lpushx 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
#
# Standarden är:
#
# maxmemory-policy noeviction #MAXMEMORY策略: När MAXMEMORY
#到达. Du kan välja mellan fem beteenden:
#
#volatile använder LRU-> LRU-algoritmen för att ta bort nycklar med utgångsmängder
#allkeys LRU-> radera vilken nyckel som helst enligt LRU-algoritmen
#volatile slumpmässigt – > tar bort slumpmässiga nycklar med utgångna set
#allkeys slumpmässiga > raderar slumpmässiga nycklar, godtyckliga nycklar
#volatile TTL-> Ta bort nyckeln med närmaste utgångstid (Minor TTL)
#noeviction-> går inte ut alls, utan returnerar endast fel i skrivoperationen
#
#注意: För någon av ovanstående strategier returnerar Redis ett fel vid skrivning
#操作, när det inte finns någon lämplig nyckel för vräkning.
#
#在编写之日 är dessa kommandon: set setnx setex append
#递增递减rpush lpushx lpushx linsert lset rpoplpush sadd
#烧结店sunion sunionstore sdiff sdiffstore zadd zincrby
#zunionstore Zinterstore Hset Hsetnx HMSET Hincrby Incrby Decrby
#getset MSetNX exec-sortering
#
#默认值为:
#
#maxmemory策略无效
Standardinställningen för redis är mycket konservativ, det vill säga den lagras inte efter att minnesgränsen överskridits, och policyn kan ändras till LRU-algoritmen (den minst använda algoritmen nyligen) – den nyligen lagrade informationen ersätter den gamla informationen.
Recension:
(Slut)
|
Publicerad den 2021-5-14 21:18:50
|
|
|
|
Hyresvärd|
Publicerad den 2023-7-12 21:08:55
|
