Adobe Experience Manager med MongoDB aem-with-mongodb

Den här artikeln syftar till att förbättra kunskapen om de uppgifter och överväganden som är nödvändiga för att distribuera AEM (Adobe Experience Manager) med MongoDB.

Mer distributionsrelaterad information finns i avsnittet Distribuera och underhålla i dokumentationen.

När MongoDB ska användas med AEM when-to-use-mongodb-with-aem

MongoDB används vanligtvis för att stödja AEM författardistributioner där något av följande villkor uppfylls:

Kriterierna ovan gäller bara för författarinstanserna och inte för publiceringsinstanser som ska vara TjärMK-baserade. Antalet användare refererar till autentiserade användare, eftersom författarinstanser inte tillåter oautentiserad åtkomst.

Om villkoren inte uppfylls rekommenderar vi en aktiverings-/standby-distribution för att åtgärda tillgängligheten. Vanligtvis bör MongoDB övervägas i situationer där skalningskraven är mer än vad som kan uppnås med en enda maskinvaruartikel.

Minimal MongoDB-distribution för AEM minimal-mongodb-deployment-for-aem

Nedan visas en minimal distribution för AEM på MongoDB. För enkelhetens skull har SSL-terminering och HTTP-proxykomponenter generaliserats. Den består av en enda MongoDB-replikuppsättning, med en primär och två sekundära.

En minimal distribution kräver tre mongod-instanser konfigurerade som en replikuppsättning. En instans har valts som primär och de andra instanserna är sekundära, med markeringen hanterad av mongod. Kopplade till varje instans är en lokal disk. Klustret kan alltså hantera belastningen, och en minsta genomströmning på 12 MB per sekund med mer än 3 000 I/O-åtgärder per sekund (IOPS) rekommenderas.

De AEM författarna är anslutna till mongod-instanserna, där varje AEM författare ansluter till alla tre mongod-instanserna. Skrivningar skickas till det primära och läsningar kan läsas från någon av instanserna. Trafiken distribueras baserat på belastningen från en Dispatcher till någon av de aktiva AEM författarinstanserna. Oak datalager är en FileDataStore och MongoDB-övervakning tillhandahålls av MMS eller MongoDB Ops Manager beroende på platsen för distributionen. Operativsystemnivå och loggövervakning tillhandahålls av tredjepartslösningar som Splunk eller Ganglia.

I den här distributionen krävs alla komponenter för en lyckad implementering. Om en komponent saknas blir implementeringen icke-funktionell.

Operativsystem operating-systems

En lista över vilka operativsystem som stöds för AEM 6 finns på sidan Tekniska krav.

Miljö environments

Virtualiserade miljöer stöds förutsatt att det finns god kommunikation mellan de olika tekniska team som kör projektet. Det här stödet omfattar det team som kör AEM, det team som äger operativsystemet och det team som hanterar den virtualiserade infrastrukturen.

Det finns specifika krav som omfattar I/O-kapaciteten för MongoDB-instanserna som måste hanteras av det team som hanterar den virtualiserade miljön. Om projektet använder en molndistribution, som Amazon Web Services, måste instanser etableras med tillräcklig I/O-kapacitet och konsekvens för att stödja MongoDB-instanserna. Annars fungerar MongoDB-processerna och Oak-databasen otillförlitligt och felaktigt.

I virtualiserade miljöer kräver MongoDB specifika I/O- och VM-konfigurationer för att säkerställa att lagringsmotorn i MongoDB inte har någon VMWare-resursallokeringsprinciper. En framgångsrik implementering säkerställer att det inte finns några hinder mellan de olika teamen och att alla är registrerade för att leverera de prestanda som krävs.

Maskinvarufrågor hardware-considerations

Lagring storage

För att uppnå läs- och skrivgenomströmning för bästa prestanda utan behov av för tidig horisontell skalning, kräver MongoDB vanligtvis SSD-lagring eller lagring med prestanda som motsvarar SSD.

RAM ram

MongoDB version 2.6 och 3.0 som använder MMAP-lagringsmotorn kräver att databasens arbetsuppsättning och dess index passar i RAM-minnet.

Otillräckligt RAM-minne ger en avsevärd prestandaförsämring. Storleken på arbetsuppsättningen och databasen är mycket programberoende. Även om vissa uppskattningar kan göras, är det mest tillförlitliga sättet att fastställa mängden RAM-minne som krävs att bygga AEM och testa det.

För att underlätta inläsningstestningsprocessen kan följande förhållande mellan arbetsuppsättningens och databasens totala storlek antas:

Dessa proportioner innebär att för SSD-distributioner krävs 200 GB RAM för en databas på 2 TB.

Även om samma begränsningar gäller för lagringsmotorn WiredTiger i MongoDB 3.0, är korrelationen mellan arbetsmängden, RAM och sidfel inte så stark. WiredTiger använder inte minnesmappning på samma sätt som MMAP-lagringsmotorn.

Datalager data-store

På grund av begränsningarna i MongoDB-arbetsuppsättningen rekommenderas att datalagret upprätthålls oberoende av MongoDB. I de flesta miljöer bör en FileDataStore som använder en NAS som är tillgänglig för alla AEM instanser användas. För situationer där Amazon Web Services används finns det också en S3 DataStore. Om datalagret av någon anledning bevaras i MongoDB, bör datalagrets storlek läggas till i den totala databasstorleken och arbetsmängdsberäkningarna justeras på rätt sätt. Den här storleksändringen kan innebära att mer RAM-minne etableras för att upprätthålla prestanda utan sidfel.

Övervakning monitoring

Övervakning är nödvändigt för ett framgångsrikt genomförande av projektet. Med tillräcklig kunskap går det att köra AEM på MongoDB utan övervakning. Denna kunskap finns dock normalt hos tekniker som är specialiserade för varje del av driftsättningen.

Denna specialkunskap innefattar normalt en FoU-tekniker som arbetar på Apache Oak Core och en MongoDB-specialist.

Utan övervakning på alla nivåer krävs detaljerade kunskaper om kodbasen för att kunna diagnostisera problem. Med övervakning på plats och lämplig vägledning om huvudstatistiken kan genomförandegrupper reagera på avvikelser på lämpligt sätt.

Det går att använda kommandoradsverktyg för att få en snabb ögonblicksbild av driften av ett kluster, men det är nästan omöjligt att göra det i realtid över många värdar. Kommandoradsverktyg ger sällan historisk information längre än några minuter och tillåter aldrig korrelation mellan olika typer av mätvärden. En kort period av långsam bakgrundssynkronisering mongod kräver en betydande manuell insats för att korrelera mot I/O Wait eller överdrivet skrivande till en delad lagringsresurs från en till synes oansluten virtuell dator.

MongoDB Cloud Manager mongodb-cloud-manager

MongoDB Cloud Manager är en kostnadsfri tjänst som erbjuds av MongoDB som tillåter övervakning och hantering av MongoDB-instanser. Den ger en översikt över prestanda och hälsa för MongoDB-klustret i realtid. Den hanterar både molninstanser och privata värdinstanser förutsatt att instansen kan nå Cloud Manager övervakningsserver.

Det kräver en agent som är installerad på MongoDB-instansen som ansluter till övervakningsservern. Det finns tre nivåer av agenset:

Även om det är enklare att använda Cloud Manager för underhållsautomatisering av ett MongoDB-kluster är många av rutinuppgifterna inte nödvändiga, och inte heller används de för säkerhetskopiering. Övervakning krävs dock när du väljer en Cloud Manager som ska övervakas.

Mer information om MongoDB Cloud Manager finns i MongoDB-dokumentationen.

Ops-hanteraren för MongoDB mongodb-ops-manager

MongoDB Ops Manager är samma programvara som MongoDB Cloud Manager. När Ops Manager har registrerats kan det laddas ned och installeras lokalt i ett privat datacenter eller på en annan bärbar eller stationär dator. Den använder en lokal MongoDB-databas för att lagra data och kommunicera på samma sätt som Cloud Manager med de hanterade servrarna. Om du har säkerhetsprofiler som förbjuder en övervakningsagent bör MongoDB Ops Manager användas.

Övervakning av operativsystem operating-system-monitoring

Övervakning på operativsystemnivå krävs för att köra ett AEM MongoDB-kluster.

Ganglia är ett bra exempel på ett sådant system och ger en bild av hur omfattande och detaljerad information som krävs utöver grundläggande hälsomått som CPU, genomsnittlig belastning och ledigt diskutrymme. För att kunna diagnostisera problem krävs information på lägre nivå, t.ex. entropingpoolnivåer, CPU I/O Wait, socketar i FIN_WAIT2-läge.

Loggaggregering log-aggregation

Med ett kluster av flera servrar är central loggaggregering ett krav för ett produktionssystem. Programvara som Splunk har stöd för loggaggregering och gör det möjligt för team att analysera beteendemönster i programmet utan att behöva samla in loggarna manuellt.

Checklistor checklists

I det här avsnittet behandlas olika åtgärder som du bör vidta för att se till att dina AEM- och MongoDB-distributioner är korrekt konfigurerade innan du implementerar ditt projekt.

Nätverk network

AEM aem-configuration

Konfiguration av nodarkiv node-store-configuration

AEM instanser måste konfigureras att använda AEM med MongoMK. Basen på mongoMK-implementeringen i AEM är Document Node Store.

Mer information om hur du konfigurerar nodarkiv finns i Konfigurera nodarkiv och datalager i AEM.

Nedan visas ett exempel på Document Node Store-konfiguration för en minimal MongoDB-distribution:

# org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config
#MongoDB server details
mongodburi=mongodb://aem:aempassword@mongodbserver1.customer.com:27000,mongodbserver2.customer.com:27000

#Name of MongoDB database to use
db=aem

#Store binaries in custom BlobStore for example, FileDataStore
customBlobStore=true

cache=2048
blobCacheSize=1024

Var:

Konfiguration av datalager data-store-configuration

Datalagret används för att lagra filer som är större än ett tröskelvärde. Under det tröskelvärdet lagras filer som egenskaper i Document Node Store. Om MongoBlobStore används skapas en dedikerad samling i MongoDB för att lagra blobbarna. Den här samlingen bidrar till arbetsuppsättningen för instansen mongod och kräver att mongod har mer RAM-minne för att undvika prestandaproblem. Av den anledningen rekommenderas att konfigurationen undviker MongoBlobStore för produktionsdistributioner och använder FileDataStore som stöds av en NAS som delas av alla AEM instanser. Eftersom cacheminnet på operativsystemnivå är effektivt vid filhantering bör den minsta storleken för en fil på disken ställas in på nära diskens blockstorlek. Om du gör det kan du vara säker på att filsystemet används effektivt, och många små dokument bidrar inte så mycket till mongod-instansens arbetsuppsättning.

Här är en typisk datalagerkonfiguration för en minimal AEM med MongoDB:

# org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
# The minimum size of an object that should be stored in this data store.
minRecordLength=4096
path=/datastore
maxCachedBinarySize=4096
cacheSizeInMB=128

Var:

Inaktivera frågetipset disabling-the-query-hint

Du bör inaktivera frågetipset som skickas med alla frågor genom att lägga till egenskapen -Doak.mongo.disableIndexHint=true när du startar AEM. På så sätt ser du till att MongoDB beräknar det lämpligaste indexvärdet baserat på intern statistik.

Om frågetipset inte är inaktiverat påverkar prestandajusteringen av index inte AEM prestanda.

Aktivera beständig cache för MongoMK enable-persistent-cache-for-mongomk

Vi rekommenderar att en beständig cachekonfiguration aktiveras för MongoDB-distributioner för att maximera hastigheten i miljöer med höga I/O-läsprestanda. Mer information finns i Jackrabbit Oak-dokumentationen.

Optimering av operativsystemet MongoDB mongodb-operating-system-optimizations

Stöd för operativsystem operating-system-support

MongoDB 2.6 använder en minnesmappad lagringsmotor som är känslig för vissa aspekter av operativsystemets nivåhantering mellan RAM och disk. Fråge- och läsprestanda för MongoDB-instansen använder sig av att undvika eller eliminera långsamma I/O-åtgärder som ofta kallas sidfel. Dessa problem är sidfel som i synnerhet gäller för mongod-processen. Blanda inte ihop detta med sidfel på operativsystemnivå.

För snabb åtgärd bör MongoDB-databasen bara komma åt data som redan finns i RAM-minnet. De data som de måste komma åt består av index och data. Den här samlingen med index och data kallas för arbetsuppsättningen. Om arbetsuppsättningen är större än den tillgängliga RAM MongoDB måste skicka in data från disken till en I/O-kostnad, och andra data som redan finns i minnet raderas. Om avlägsnandet medför att data läses in på nytt från disken, dominerar sidfelen och prestandan försämras. Om arbetsuppsättningen är dynamisk och variabel uppstår fler sidfel som stöd för åtgärder.

MongoDB kan köras i flera operativsystem, bland annat en mängd olika Linux®-versioner, Windows och macOS. Mer information finns på https://docs.mongodb.com/manual/installation/#supported-platforms. Beroende på vilket operativsystem du väljer har MongoDB olika rekommendationer på operativsystemnivå. Dokumentationen finns på https://docs.mongodb.com/manual/administration/production-checklist-operations/#operating-system-configuration och sammanfattas här.

Linux® linux

Windows windows

WiredTiger wiredtiger

Från och med MongoDB 3.2 är standardlagringsmotorn för MongoDB lagringsmotorn WiredTiger. Den här motorn har en del robusta och skalbara funktioner som gör den mycket bättre lämpad för allmänna databasarbetsbelastningar. I följande avsnitt beskrivs dessa funktioner.

Samtidighet på dokumentnivå document-level-concurrency

WiredTiger använder samtidighetskontroll på dokumentnivå för skrivåtgärder. Det innebär att flera klienter kan ändra olika dokument i en samling samtidigt.

För de flesta läs- och skrivåtgärder använder WiredTiger en optimistisk samtidighetskontroll. WiredTiger använder endast intent-lås på global nivå, databas- och samlingsnivå. När lagringsmotorn upptäcker konflikter mellan två åtgärder uppstår en skrivkonflikt som gör att MongoDB försöker utföra åtgärden igen. För vissa globala åtgärder, vanligtvis kortvariga åtgärder som omfattar flera databaser, krävs fortfarande ett globalt "instansövergripande" lås.

Vissa andra åtgärder, till exempel att släppa en samling, kräver fortfarande ett exklusivt databaslås.

Fixeringar och kontrollpunkter snapshots-and-checkpoints

WiredTiger använder MultiVersion Concurrency Control (MVCC). I början av en åtgärd ger WiredTiger en ögonblicksbild av data som skickas till transaktionen. En ögonblicksbild ger en enhetlig vy över data i minnet.

När WiredTiger skriver till disk, skrivs alla data i en ögonblicksbild på ett konsekvent sätt över alla datafiler. Nu- varaktiga-data fungerar som en kontrollpunkt i datafilerna. Kontrollpunkten ser till att datafilerna är konsekventa till och med den sista kontrollpunkten. Det innebär att kontrollpunkter kan fungera som återställningspunkter.

MongoDB konfigurerar WiredTiger för att skapa kontrollpunkter (d.v.s. skriva ögonblicksbildsdata till disk) med 60 sekunders intervall eller 2 GB journaldata.

När en ny kontrollpunkt skrivs är den föregående kontrollpunkten fortfarande giltig. Även om MongoDB avbryter eller stöter på ett fel när en ny kontrollpunkt skrivs kan MongoDB återställas från den senaste giltiga kontrollpunkten när den startas om.

Den nya kontrollpunkten blir tillgänglig och permanent när metadatatabellen i WiredTiger uppdateras automatiskt för att referera till den nya kontrollpunkten. När den nya kontrollpunkten är tillgänglig frigör WiredTiger sidor från de gamla kontrollpunkterna.

Med WiredTiger kan MongoDB återställas från den senaste kontrollpunkten, även utan journalföring. Om du vill återställa ändringar som gjorts efter den senaste kontrollpunkten kör du med journaling.

Journal journal

WiredTiger använder en transaktionsinloggningskombination för write-ahead med kontrollpunkter för att säkerställa datalagring.

WiredTiger-journalen består av alla dataändringar mellan kontrollpunkterna. Om MongoDB avslutas mellan kontrollpunkter används journalen för att spela upp alla data som ändrats sedan den senaste kontrollpunkten. Information om hur ofta MongoDB skriver journaldata till disk finns i Journalföringsprocess.

WiredTiger-journalen komprimeras med komprimeringsbiblioteket snappy . Om du vill ange en alternativ komprimeringsalgoritm eller ingen komprimering använder du inställningen storage.wiredTiger.engineConfig.journalCompressor .

Se Journalföring med WiredTiger.

Komprimering compression

Med WiredTiger stöder MongoDB komprimering för alla samlingar och index. Komprimering minimerar användningen av lagringsutrymme på bekostnad av ytterligare CPU.

Som standard använder WiredTiger blockkomprimering med komprimeringsbiblioteket snappy för alla samlingar och prefix-komprimering för alla index.

För samlingar är blockkomprimering med zlib också tillgängligt. Om du vill ange en alternativ komprimeringsalgoritm eller ingen komprimering använder du inställningen storage.wiredTiger.collectionConfig.blockCompressor .

Om du vill inaktivera prefixkomprimering för index använder du inställningen storage.wiredTiger.indexConfig.prefixCompression .

Komprimeringsinställningarna kan även konfigureras per samling och per index när du skapar samlingar och index. Se Ange lagringsmotoralternativ och alternativet db.collection.createIndex() storageEngine .

För de flesta arbetsbelastningar balanserar standardkomprimeringsinställningarna lagringseffektivitet och bearbetningskrav.

Journalen WiredTiger komprimeras också som standard. Mer information om journalkomprimering finns i Journal.

Minnesanvändning memory-use

Med WiredTiger använder MongoDB både det interna WiredTiger-cacheminnet och filsystemets cache.

Från och med 3.4 används som standard det interna cache-minnet för WiredTiger det större av antingen:

Som standard använder WiredTiger blockkomprimering för Snappy för alla samlingar och prefixkomprimering för alla index. Komprimeringsstandardinställningarna kan konfigureras på global nivå och kan även ställas in per samling och per index när du skapar samlingar och index.

Olika representationer används för data i det interna WiredTiger-cacheminnet jämfört med i formatet på disken:

Index som läses in i det interna WiredTiger-cacheminnet har en annan datarepresentation än formatet på disken, men kan ändå utnyttja indexprefixkomprimering för att minska RAM-användningen.

Vid komprimering av indexprefix dupliceras vanliga prefix från indexerade fält.

Samlingsdata i det interna WiredTiger-cacheminnet är okomprimerade och använder en annan representation än i formatet på disken. Blockkomprimering kan ge avsevärda besparingar på disken, men data måste vara okomprimerade för att kunna hanteras av servern.

Via filsystemets cache använder MongoDB automatiskt allt ledigt minne som inte används av WiredTiger-cachen eller av andra processer.

Information om hur du justerar storleken på det interna WiredTiger-cacheminnet finns i storage.wiredTiger.engineConfig.cacheSizeGB och —wiredTigerCacheSizeGB. Undvik att öka den interna cachestorleken för WiredTiger över standardvärdet.

NUMA numa

NUMA (Non-Uniform Memory Access) gör att en kärna kan hantera hur minne mappas till processorkärnorna. Även om den här processen försöker göra minnesåtkomsten snabbare för kärnor som ser till att de kan komma åt de data som krävs, så stör NUMA MMAP införandet av ytterligare latens eftersom läsningar inte kan förutsägas. Därför måste NUMA inaktiveras för processen mongod på alla operativsystem som kan användas.

I ett NUMA-arkitekturminne är alltså anslutet till CPU:er och CPU:er är anslutna till en buss. I en SMP- eller UMA-arkitektur är minnet anslutet till bussen och delas av CPU:er. När en tråd allokerar minne på en NUMA-processor allokeras den enligt en princip. Standardinställningen är att tilldela minne som är kopplat till trådens lokala CPU, såvida det inte finns något ledigt utrymme, och då används minne från en ledig CPU till en högre kostnad. När minnet har tilldelats flyttas det inte mellan CPU:er. Allokeringen utförs av en princip som ärvs från den överordnade tråden, vilket i slutändan är den tråd som startade processen.

I många databaser som ser datorn som en enhetlig minnesarkitektur med flera kärnor leder detta scenario till att den första CPU:n blir full först och den sekundära CPU-fyllningen senare. Det är särskilt sant om en central tråd ansvarar för allokering av minnesbuffertar. Lösningen är att ändra NUMA-principen för huvudtråden som används för att starta mongod-processen genom att köra följande kommando:

numactl --interleaved=all <mongod> -f config

Den här principen tilldelar minne i en runda robat över alla processornoder, vilket ger en jämn fördelning över alla noder. Den ger inte tillgång till minne med högsta prestanda, som i system med flera CPU-maskinvara. Ungefär hälften av minnesåtgärderna är långsammare och ligger över bussen, men mongod har inte skrivits för att nå NUMA på ett optimalt sätt, så det är en rimlig kompromiss.

NUMA-problem numa-issues

Om processen mongod startas från en annan plats än mappen /etc/init.d är det troligt att den inte har startats med rätt NUMA-princip. Beroende på vilken standardprincip som används kan problem uppstå. Orsaken är att de olika installationsprogrammen för Linux® Package Manager för MongoDB även installerar en tjänst med konfigurationsfiler i /etc/init.d som utför det steg som beskrivs ovan. Om du installerar och kör MongoDB direkt från ett arkiv ( .tar.gz) måste du manuellt köra pengar under numactl-processen.

MongoDB-processen fungerar på olika sätt med olika allokeringsprinciper:

Vissa principer kan resultera i att mindre än allt tillgängligt RAM-minne ges till processen mongod. Till skillnad från MySQL undviker MongoDB aktivt sidindelning på operativsystemnivå, och därför kan mongod-processen få mindre minne som verkar tillgängligt.

Byter swapping

På grund av databasernas minneskrävande natur måste byte på operativsystemnivå inaktiveras. Med MongoDB-processen undviker du att byta design.

Fjärrfilsystem remote-filesystems

Fjärrfilsystem som NFS rekommenderas inte för MongoDB:s interna datafiler (enkelprocessdatabasfiler) eftersom de orsakar för mycket latens. Blanda inte ihop med det delade filsystem som krävs för lagring av Oak Blob's (FileDataStore), där NFS rekommenderas.

Läs framåt read-ahead

Trimma lästipset så att onödiga block inte läses från disken när en sida växlas in med en slumpmässig läsning. Sådana resultat innebär onödig användning av I/O-bandbredd.

Linux®-krav linux-requirements

Lägsta kernel-versioner minimum-kernel-versions

Rekommenderade inställningar för databasdiskar recommended-settings-for-database-disks

Inaktivera tid

Vi rekommenderar att atime inaktiveras för diskarna som innehåller databaserna.

Ange NOOP-diskschemaläggaren

Gör följande:

Kontrollera först i/O-schemaläggaren som är inställd genom att köra följande kommando:

cat /sys/block/sdg/queue/scheduler

Om svaret är noop finns det inget mer du måste göra.

Om NOOP inte är den inställda I/O-schemaläggaren kan du ändra den genom att köra:

echo noop > /sys/block/sdg/queue/scheduler

Justera värdet för read ahead

Vi rekommenderar att du använder värdet 32 för de diskar där MongoDB-databaser körs. Värdet är 16 kB. Du kan ställa in den genom att köra följande:

sudo blockdev --setra <value> <device>

Aktivera NTP enable-ntp

Kontrollera att NTP är installerat och igång på datorn som är värd för MongoDB-databaserna. Du kan till exempel installera det med hjälp av Yum Package Manager på en CentOS-dator:

sudo yum install ntp

När NTP-daemon har installerats och startats kan du kontrollera om körningsfilen innehåller serverns tidsförskjutning.

Inaktivera genomskinliga stora sidor disable-transparent-huge-pages

Red Hat® Linux® använder en minneshanteringsalgoritm som kallas för Transparent Huge Pages (THP). Vi rekommenderar att du inaktiverar det om du använder operativsystemet för databasarbetsbelastningar.

Du kan inaktivera det genom att följa nedanstående procedur:

Inaktivera NUMA disable-numa

I de flesta installationer där NUMA är aktiverat inaktiveras det automatiskt av MongoDB daemon om det körs som en tjänst från mappen /etc/init.d.

Om så inte är fallet kan du inaktivera NUMA per processnivå. Om du vill inaktivera det kör du följande kommandon:

numactl --interleave=all <path_to_process>

Där <path_to_process> är sökvägen till monteringsprocessen.

Inaktivera sedan zonåteranvändning genom att köra:

echo 0 > /proc/sys/vm/zone_reclaim_mode

Justera de högsta tillåtna inställningarna för monteringsprocessen tweak-the-ulimit-settings-for-the-mongod-process

Linux® ger konfigurerbar kontroll över resursallokeringen med hjälp av kommandot ulimit. Den här konfigurationen kan göras per användare eller process.

Vi rekommenderar att du konfigurerar en övre gräns för montageprocessen enligt MongoDB Recommended Ulimit Settings.

Testa MongoDB I/O-prestanda test-mongodb-i-o-performance

MongoDB har ett verktyg med namnet mongoperf som är utformat för att testa I/O-prestanda. Vi rekommenderar att du använder den för att testa prestanda för alla dina MongoDB-instanser som utgör din infrastruktur.

Mer information om hur du använder mongoperf finns i MongoDB-dokumentationen.

Testa läsprestanda på de virtuella datorer som ingår i distributionen

När du har installerat verktyget växlar du till databaskatalogen MongoDB för att köra testerna. Starta sedan det första testet genom att köra mongoperfmed den här konfigurationen:

echo "{nThreads:32,fileSizeMB:1000,r:true}" | mongoperf

De önskade utdata bör vara upp till två gigabyte per sekund (2 GB/s) och 500 000 IOPS med 32 trådar för alla MongoDB-instanser.

Kör ett andra test, den här gången med minnesmappade filer, genom att ange parametern mmf:true:

echo "{nThreads:32,fileSizeMB:1000,r:true,mmf:true}" | mongoperf

Utdata från det andra testet bör vara betydligt högre än det första, vilket indikerar minnesöverföringsprestanda.

Testa skrivprestanda för den primära MongoDB-instansen

Kontrollera sedan I/O-skrivprestanda för den primära MongoDB-instansen genom att köra mongoperf från MongoDB-databaskatalogen med samma inställningar:

echo "{nThreads:32,fileSizeMB:1000,w:true}" | mongoperf

Önskat utvärde bör vara 12 megabyte per sekund och nå cirka 3 000 IOPS, med liten variation mellan antalet trådar.

Steg för virtualiserade miljöer steps-for-virtualised-environments

VMWare vmware

Om du använder WMWare ESX för att hantera och driftsätta dina virtualiserade miljöer måste du utföra följande inställningar från ESX-konsolen för att kunna utföra MongoDB-åtgärden:

Amazon Web Services amazon-web-services

Mer information om hur du konfigurerar MongoDB med Amazon Web Services finns i artikeln Konfigurera AWS-integrering på MongoDB-webbplatsen.

Säkra MongoDB före distribution securing-mongodb-before-deployment

Se det här inlägget på distribuerar MongoDB säkert för råd om hur du skyddar konfigurationen av dina databaser före distributionen.

Dispatcher dispatcher

Välja operativsystem för Dispatcher choosing-the-operating-system-for-the-dispatcher

För att din MongoDB-distribution ska fungera på rätt sätt måste operativsystemet som är värd för Dispatcher köra Apache httpd version 2.4 eller senare.

Se även till att alla bibliotek som används i ditt bygge är uppdaterade för att minimera säkerhetsriskerna.

Dispatcher Configuration dispatcher-configuration

En typisk Dispatcher-konfiguration fungerar mellan tio och 20 gånger så mycket som genomströmningen för en enda AEM.

Eftersom Dispatcher är tillståndslöst kan det enkelt skalas vågrätt. I vissa distributioner måste författare hindras från att komma åt vissa resurser. Vi rekommenderar att du använder en Dispatcher med författarinstanserna.

För att köra AEM utan Dispatcher krävs att SSL-avslutning och belastningsutjämning utförs av ett annat program. Det är obligatoriskt eftersom sessioner måste ha tillhörighet till den AEM instansen som de skapas i, ett koncept som kallas klibbiga anslutningar. Orsaken är att uppdateringarna av innehållet har minimal fördröjning.

Läs Dispatcher-dokumentationen om du vill ha mer information om hur du konfigurerar den.

Ytterligare konfiguration additional-configuration

Fästiga anslutningar sticky-connections

Antikiga anslutningar säkerställer att personaliserade sidor och sessionsdata för en användare består av samma instans av AEM. Dessa data lagras på instansen, så efterföljande begäranden från samma användare återgår till samma instans.

Vi rekommenderar att klisterlappande anslutningar aktiveras för alla inre lagers routningsbegäranden till AEM instanser, vilket uppmuntrar efterföljande begäranden att nå samma AEM. Om du gör det minimeras fördröjningen som annars syns när innehållet uppdateras mellan olika instanser.

Långt förfallodatum long-expires

Som standard har innehåll som skickas ut från en AEM Dispatcher rubriker Senaste ändring och Etag utan någon indikation på innehållets förfallodatum. Det här flödet ser till att användargränssnittet alltid får den senaste versionen av resursen. Det innebär också att webbläsaren utför en GET-åtgärd för att se om resursen har ändrats. Det kan därför resultera i flera begäranden som HTTP-svaret är 304 (inte ändrat), beroende på sidinläsningen. Om du anger ett förfallodatum för resurser och tar bort rubrikerna Last-Modified och ETag, kommer innehållet att cachelagras. Inga fler uppdateringsbegäranden görs förrän datumet i huvudet Förfaller är uppfyllt.

Men om du använder den här metoden finns det inget rimligt sätt att låta resursen förfalla i webbläsaren innan rubriken Förfaller förfaller. För att minimera arbetsflödet kan HtmlClientLibraryManager konfigureras att använda oföränderliga URL:er för klientbibliotek.

Dessa URL:er ändras garanterat inte. När innehållet i resursen som finns i URL-adressen ändras, återspeglas ändringarna i URL-adressen så att webbläsaren begär rätt version av resursen.

Standardkonfigurationen lägger till en väljare i HtmlClientLibraryManager. Resursen är en väljare och cachas i Dispatcher med väljaren intakt. Den här väljaren kan också användas för att säkerställa korrekt förfallobeteende. Standardväljaren följer mönstret lc-.*?-lc. Följande httpd-konfigurationsdirektiv för Apache säkerställer att alla begäranden som matchar mönstret hanteras med lämplig förfallotid.

Header set Expires "Tue, 20 Jan 2037 04:20:42 GMT" "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header set Cache-Control "public, no-transform, max-age=267840000" "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset ETag "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset Last-Modified "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"
Header unset Pragma "expr=(%{REQUEST_STATUS} -eq 200) && (%{REQUEST_URI} =~ /.*lc-.*?-lc.*/)"

Ingen sniff no-sniff

Där innehåll skickas ut utan innehållstyp försöker många webbläsare att gissa vilken typ av innehåll det är genom att läsa de första byten i innehållet. Den här metoden kallas för "sniffing". Sniffing öppnar en säkerhetsrisk eftersom användare som kan skriva till databasen kan överföra skadligt innehåll utan innehållstyp.

Därför är det tillrådligt att lägga till en no-sniff-rubrik till resurser som hanteras av Dispatcher. Dispatcher cache-lagrar emellertid inte rubriker. Det innebär att innehåll som hanteras från det lokala filsystemet har sin innehållstyp som bestäms av tillägget, i stället för att den ursprungliga innehållstypsrubriken från den ursprungliga AEM.

Inga kodavsnitt kan aktiveras på ett säkert sätt om webbprogrammet är känt för att aldrig hantera cachelagrade resurser utan filtyp.

Du kan aktivera Ingen signatur:

Header set X-Content-Type-Options "nosniff"

Den kan också aktiveras selektivt:

RewriteCond %{REQUEST_URI} \.(?:js|jsonp)$ [OR]
RewriteCond %{QUERY_STRING} (callback|jsonp|cb)=\w+
RewriteRule .* - [E=jsonp_request:1]
Header set X-Content-Type-Options "nosniff"  env=jsonp_request
Header setifempty Content-Type application/javascript env=jsonp_request

Skyddsprincip för innehåll content-security-policy

Dispatcher standardinställningar tillåter en öppen säkerhetsprincip för innehåll, som även kallas CSP. Med de här inställningarna kan en sida läsa in resurser från alla domäner som omfattas av standardreglerna i webbläsarsandlådan.

Det är önskvärt att begränsa varifrån resurser kan läsas in för att undvika att läsa in kod till JavaScript-motorn från otillförlitliga eller overifierade externa servrar.

Med CSP kan du finjustera principer. I ett komplext program måste emellertid CSP-huvuden utvecklas med försiktighet eftersom för restriktiva profiler kan bryta delar av användargränssnittet.

Storleksändring sizing

Mer information om storleksändring finns i Riktlinjerna för maskinvarustorlek.

Prestandaoptimering för MongoDB mongodb-performance-optimization

Mer allmän information om MongoDB-prestanda finns i Analyserar MongoDB-prestanda.

Kända begränsningar known-limitations

Samtidiga installationer concurrent-installations

MongoMK stöder samtidig användning av flera AEM-instanser med en databas, men inte samtidiga installationer.

För att lösa problemet måste du först köra installationen med en enda medlem och lägga till de andra efter att den första installationen är klar.

Sidnamnslängd page-name-length

Om AEM körs på en MongoMK persistence Manager-distribution är sidnamnen begränsade till 150 tecken.