Sidfel är ett utbrett fel som oftast uppstår i en stor applikation som involverar stora data. Det sker när MongoDB-databasen läser data från fysiskt minne snarare än från virtuellt minne. Sidfelsfel uppstår i det ögonblick som MongoDB vill hämta data som inte är tillgängligt i databasens aktiva minne och tvingas därför läsa från disken. Detta skapar en stor latens för genomströmningsoperationer som gör att frågor ser ut som om de släpar efter.
Justering av prestanda för MongoDB genom justering är en viktig komponent som optimerar exekvering av en applikation. Databaser har förbättrats för att fungera med information som finns på disken, men den cachelagrar vanligtvis stora mängder data i RAM-minnet i ett försök att komma åt disken. Det är dyrt att lagra och komma åt data från databasen, därför måste informationen först lagras på disken innan applikationer får tillgång till den. På grund av det faktum att diskar är långsammare jämfört med RAM-datacache, kräver processen en betydande mängd tid. Därför är MongoDB utformad för att rapportera förekomst av sidfel som en sammanfattning av alla incidenter på en sekund
Datarörelsetopologin i MongoDB
Data från klienten flyttas till det virtuella minnet där sidcache läser den när den skrivs, data lagras sedan på disken som visas i diagrammet nedan.
Hur man hittar MongoDB-sidafel
Sidfel kan upptäckas genom låsprestanda som säkerställer datakonsistens i MongoDB. När en given operation står i kö eller körs under lång tid försämras MongoDB-prestanda och operationen saktar ner medan den väntar på låsning. Detta leder till en avmattning eftersom låsrelaterade förseningar är sporadiska och ibland påverkar applikationens prestanda. Lås påverkar prestandan för en applikation när lås är uppdelade (locks.timeAcquiringMicros av locks.acquireWaitCount), detta ger den genomsnittliga tiden att vänta på ett givet låsläge. Locks.deadLockCount ger summan av alla låsförvärv som upplevts. Med tanke på att globalLock.totalTime är harmoniskt hög finns det många förfrågningar som förväntar sig ett lås. När fler förfrågningar väntar på lås förbrukas mer RAM och detta leder till sidfel.
Du kan också använda mem.mapped som gör det möjligt för utvecklare att granska det totala minnet som mongod använder. Mem.mapped är en serveroperatör för att kontrollera mängden minne i megabyte (MB) i en MMAPv1-lagringsmotor. Om mem.mapped-operatorn visar ett värde som är större än den totala mängden systemminne uppstår ett sidfel eftersom en så stor mängd minnesanvändning kommer att leda till ett sidfel i databasen.
Hur sidfel uppstår i MongoDB
Hämtning av sidor i MongoDB beror på tillgängligheten av ledigt minne, i händelse av att det saknar ledigt minne måste operativsystemet:
- Leta efter en sida som databasen har slutat använda och skriv sidan på minnesdisken.
- Ladda in den begärda sidan i minnet efter att ha läst den från disken.
Dessa två aktiviteter äger rum när sidor laddas och förbrukar därför mycket tid jämfört med läsning i ett aktivt minne, vilket leder till att sidfel uppstår.
Lösa MongoDB-sidafel
Följande är några sätt genom vilka man kan lösa sidfel:
- Skala vertikalt till enheter med tillräckligt med RAM eller skala horisontellt: När det inte finns tillräckligt med RAM för en given datamängd är det korrekta tillvägagångssättet att öka RAM-minnet genom att skala vertikalt till enheter med mer RAM för att lägga till mer resurser till servern. Vertikal skalning är ett av de bästa och enkla sätten att öka MongoDB-prestanda genom att inte sprida belastningen mellan flera servrar. Eftersom skalning vertikalt lägger till mer RAM-minne, möjliggör skalning horisontellt tillägg av fler skärvor till ett splittrat kluster. Enkelt uttryckt är horisontell skalning där databasen delas upp i olika bitar och lagras på flera servrar. Horisontell skalning gör det möjligt för utvecklaren att lägga till fler servrar i farten och detta ökar databasprestandan avsevärt eftersom det inte medför noll stilleståndstid. Vertikal skalning och horisontell skalning minskar lösa förekomsten av sidfel genom att öka minnet som man arbetar med när man arbetar med databasen.
- Indexera data korrekt: Användning av lämpliga index för att säkerställa att det finns effektiva frågor som inte orsakar insamlingsgenomsökningar. Korrekt indexering säkerställer att databasen inte itererar över varje dokument i en samling och löser därmed eventuella sidfelsfel. Samlingsskanning orsakar ett sidfel eftersom hela samlingen inspekteras av frågemotorn när den läses in i RAM-minnet. De flesta dokumenten i samlingsskanningen returneras inte i appen och orsakar därmed onödiga sidfel för varje efterföljande förfrågan som inte är lätt att undvika. Dessutom kan överskott av index också leda till ineffektiv användning av RAM, vilket kan leda till sidfel. Därför är korrekt indexering av största vikt om en utvecklare har för avsikt att lösa sidfel. MongoDB erbjuder hjälp med att bestämma de index som man bör använda när man använder databasen. De erbjuder både Slow Query Analyzer som ger nödvändig information om hur man indexerar för användare och delade användare.
- Migrerar till den senaste versionen av MongoDB och flyttar sedan programmet till WiredTiger. Detta är nödvändigt om du tänker undvika att uppleva sidfel eftersom sidfel endast är vanliga i MMAPv1-lagringsmotorer till skillnad från nyare versioner och WiredTiger. MMAPv1-lagringsmotorn har fasats ut och MongoDB stöder den inte längre. WiredTiger är den nuvarande standardlagringsmotorn i MongoDB och den har MultiVersion Concurrency Control som gör den mycket bättre jämfört med MMAPv1-lagringsmotorn. Med WiredTiger kan MongoDB använda både filsystemcache och WiredTiger intern cache som har en mycket stor storlek på antingen 1GB (50% 0f (RAM - 1GB)) eller 256 MB.
- Håll reda på det totala RAM-minnet som är tillgängligt för användning i ditt system. Detta kan göras genom att använda tjänster som New Relic monitoring Google Cloud Monitoring. Dessutom kan BindPlane användas med de nämnda molnövervakningstjänsterna. Att använda ett övervakningssystem är en proaktiv åtgärd som gör att man kan motverka sidfel innan de inträffar istället för att reagera på uppkommande sidfel. BindPlane låter monitorn ställa in konstanta varningar för uppkomst av sidfel, varningarna gör också en medveten om antalet index, indexstorlek och filstorlek.
- Se till att data konfigureras i den rådande arbetsuppsättningen och inte kommer att använda mer RAM än vad som rekommenderas. MongoDB är ett databassystem som fungerar bäst när ofta åtkomna data och index kan passa perfekt i det tilldelade minnet. RAM-storleken är en viktig aspekt när man optimerar prestandan för databasen, därför måste man se till att det alltid finns tillräckligt med RAM-minne innan appen distribueras.
- Fördelning av belastning mellan mongod-instanser genom att lägga till shards eller distribuera ett sharded kluster. Det är av avgörande betydelse att möjliggöra skuggning där den riktade samlingen finns. Anslut först till mongos i mongo-skalet och använd metoden nedan.
-
sh.shardCollection()
Skapa sedan ett index med den här metoden.
Det skapade indexet stöder shard-nyckeln, det vill säga om den skapade samlingen redan hade tagit emot eller lagrat en del data. Men om samlingen inte har några data (tom) använd metoden nedan för att indexera den som en del av ssh.shardCollection: sh.shardCollection()db.collection.createIndex(keys, options)
- Detta följs av någon av de två strategierna som tillhandahålls av mongoDB.
- Hashad skuggning
sh.shardCollection("<database>.<collection>", { <shard key field> : "hashed" } )
- Omfångsbaserad skuggning
sh.shardCollection("<database>.<collection>", { <shard key field> : 1, ... } )
- Hashad skuggning
-
Hur man förhindrar MongoDB-sidfel
- Lägg till shards eller distribuera sharded kluster för att fördela belastningen
- Ha tillräckligt med RAM-minne för din applikation innan du distribuerar den
- Flytta till MongoDB nyare versioner och fortsätt sedan till WiredTiger
- Skala vertikalt eller horisontellt för en enhet med mer RAM
- Använd Rekommenderat RAM-minne och håll reda på använt RAM-utrymme
Slutsats
Några antal sidfel (enbart) tar kort tid, men i en situation där det finns många sidfel (sammanlagt) är det en indikation på att databasen läser ett stort antal data i disken. När aggregering sker kommer det att finnas fler MongoBD-läslås som leder till ett sidfel.
När du använder MongoDB kan storleken på RAM-minnet för systemet och antalet frågor i hög grad påverka applikationens prestanda. Prestandan för en applikation i MongoDB är mycket beroende av tillgängligt RAM-minne på det fysiska minnet, vilket påverkar den tid det tar för applikationen att göra en enda fråga. Med tillräckligt med RAM-minne minskas förekomsten av sidfel och applikationsprestanda förbättras.