YaCy '#[clientname]#': Performance Settings for Memory

#%env/templates/metas.template%# #%env/templates/header.template%# #%env/templates/submenuPerformance.template%#

Performance Settings for Memory

Memory Usage:

Type	After Startup	After Initializations before GC	After Initializations after GC	Now #(gc)#before GC::after GC#(/gc)#	Next Startup	Description
Max	#[memoryMax]# MByte				MByte	maximum memory that the JVM will attempt to use
Available	#[memoryAvailAfterStartup]# MByte	#[memoryAvailAfterInitBGC]# MByte	#[memoryAvailAfterInitAGC]# MByte	#[memoryAvailNow]# MByte		total available memory including free for the JVM within maximum
Total	#[memoryTotalAfterStartup]# KByte	#[memoryTotalAfterInitBGC]# KByte	#[memoryTotalAfterInitAGC]# KByte	#[memoryTotalNow]# MByte	MByte	total memory taken from the OS
Free	#[memoryFreeAfterStartup]# KByte	#[memoryFreeAfterInitBGC]# KByte	#[memoryFreeAfterInitAGC]# KByte	#[memoryFreeNow]# MByte		free memory in the JVM within total amount
Used	#[memoryUsedAfterStartup]# KByte	#[memoryUsedAfterInitBGC]# KByte	#[memoryUsedAfterInitAGC]# KByte	#[memoryUsedNow]# MByte		used memory in the JVM within total amount
Re-Configuration of Startup Paramenters:						Changes take effect after re-start of YaCy this works only on linux/unix systems

RAM Cache for Database Files:

Database

Chunk Size
high/med/low
(bytes)

#Slots

Memory Occupation (KBytes)

Description

Needed
(= DB Size)

Empty

Used
High Prio

Used
Medium Prio

Used
Low Prio

Used Now

Assigned Max

Default Max

Good Max

Best Max

RWI Assortment Cluster

#[chunkRWI]#

#[slreqRWI]#

#[slempRWI]#

#[slhigRWI]#

#[slmedRWI]#

#[sllowRWI]#

#[usedRWI]#

#[dfltRWI]#

#[goodRWI]#

#[bestRWI]#

The Assortment Cluster stores most of the page indexes. Flushing speed of the temporary RWI cache depends on the size of this file cache. Increasing the space of this cache will speed up crawls with a depth > 3.

HTTP Response Header

#[chunkHTTP]#

#[slreqHTTP]#

#[slempHTTP]#

#[slhigHTTP]#

#[slmedHTTP]#

#[sllowHTTP]#

#[usedHTTP]#

#[dfltHTTP]#

#[goodHTTP]#

#[bestHTTP]#

The Response Header database stores the HTTP heades that other servers send when YaCy retrieves web pages during proxy mode, when performing crawls or if it fetches pages for snippet generation. Increasing this cache will be most important for a fast proxy mode.

'loaded' URLs

#[chunkLURL]#

#[slreqLURL]#

#[slempLURL]#

#[slhigLURL]#

#[slmedLURL]#

#[sllowLURL]#

#[usedLURL]#

#[dfltLURL]#

#[goodLURL]#

#[bestLURL]#

This is the database that holds the hash/url - relation and properties regarding the url like load date and server date. This cache is very important for a fast search process. Increasing the cache size will result in more search results and less IO during DHT transfer.

'noticed' URLs

#[chunkNURL]#

#[slreqNURL]#

#[slempNURL]#

#[slhigNURL]#

#[slmedNURL]#

#[sllowNURL]#

#[usedNURL]#

#[dfltNURL]#

#[goodNURL]#

#[bestNURL]#

A noticed URL is one that was discovered during crawling but was not loaded yet. Increasing the cache size will result in faster double-check during URL recognition when doing crawls.

'error' URLs

#[chunkEURL]#

#[slreqEURL]#

#[slempEURL]#

#[slhigEURL]#

#[slmedEURL]#

#[sllowEURL]#

#[usedEURL]#

#[dfltEURL]#

#[goodEURL]#

#[bestEURL]#

URLs that cannot be loaded are stored in this database. It is also used for double-checked during crawling. Increasing the cache size will most probably speed up crawling slightly, but not significantly.

DHT Control

#[chunkDHT]#

#[slreqDHT]#

#[slempDHT]#

#[slhigDHT]#

#[slmedDHT]#

#[sllowDHT]#

#[usedDHT]#

#[dfltDHT]#

#[goodDHT]#

#[bestDHT]#

This is simply the cache for the seed-dbs (active, passive, potential). This cache is divided into three equal parts. Increasing this cache may speed up many functions, but we need to test this to see the effects.

Messages

#[chunkMessage]#

#[slreqMessage]#

#[slempMessage]#

#[slhigMessage]#

#[slmedMessage]#

#[sllowMessage]#

#[usedMessage]#

#[dfltMessage]#

#[goodMessage]#

#[bestMessage]#

The Message cache for peer-to-peer messages. Less important.

Wiki

#[chunkWiki]#

#[slreqWiki]#

#[slempWiki]#

#[slhigWiki]#

#[slmedWiki]#

#[sllowWiki]#

#[usedWiki]#

#[dfltWiki]#

#[goodWiki]#

#[bestWiki]#

The YaCy-Wiki uses a database to store its pages. This cache is divided in two parts, one for the wiki database and one for its backup. Increasing this cache may speed up access to the wiki pages.

News

#[chunkNews]#

#[slreqNews]#

#[slempNews]#

#[slhigNews]#

#[slmedNews]#

#[sllowNews]#

#[usedNews]#

#[dfltNews]#

#[goodNews]#

#[bestNews]#

The News-DB stores property-lists for news that are included in seeds. Increasing this cache may speed up the peer-ping.

robots.txt DB

#[chunkRobots]#

#[slreqRobots]#

#[slempRobots]#

#[slhigRobots]#

#[slmedRobots]#

#[sllowRobots]#

#[usedRobots]#

#[dfltRobots]#

#[goodRobots]#

#[bestRobots]#

The robots.txt DB stores downloaded records from robots.txt files. Increasing this cache may speed up validation if crawling of the URL is allowed.

Crawl Profiles

#[chunkProfiles]#

#[slreqProfiles]#

#[slempProfiles]#

#[slhigProfiles]#

#[slmedProfiles]#

#[sllowProfiles]#

#[usedProfiles]#

#[dfltProfiles]#

#[goodProfiles]#

#[bestProfiles]#

The profile database stores properties for each crawl that is started on the local peer. Increasing this cache may speed up crawling, but not much space is needed, so the effect may be low.

Totals

#[usedTotal]# MB

#[currTotal]# MB

#[dfltTotal]# MB

#[goodTotal]# MB

#[bestTotal]# MB

Sum of memory amounts

Re-Configuration:

these
custom
values

all
default
values

all
recom-
mended values

all
optimum
values

Changes take effect after re-start of YaCy

Write Cache Object Allocation:

#{sizes}# #{/sizes}# #{alive}# #{/alive}# #{heap}# #{/heap}#

Chunk Sizes	#[chunk]#
now alive in write cache	#[count]#
currently held in write buffer heap	#[count]#

#%env/templates/footer.template%#