průběžná aktualizace počtu indexovaných dokumentů během indexace

[GoogleCodeExporter]

K4.5.0, solr 3.5
Při přechodu na solr 3.5 se změnil soubor solrconfig.xml. V předchozí 
verzi byl zapnut autocommit po přidání každého dokumentu nebo po uplynutí 
1 ms (prakticky tedy po každém přídání).
<autoCommit>
<maxDocs>1</maxDocs>
<maxTime>1<maxTime>
</autoCommig>
To je dost neefektivní a myslím, že je dobře, že už to tak není. Na 
druhou stranu úplné vypnutí autocommitu (jak je to teď) mi taky nepříjde 
v pořádku. Pokud probíhá dlouhá indexace, tak se výsledky v Krameriu 
projeví až po (úspěšném) skončení procesu. Tím, že se projeví 
výsledky myslím to, že se provede solr COMMIT a indexované věci se 
zobrazí v Krameriu (facety, vyhledávání).
Což u indexace celého modelu trvá hodiny až dny, samozřejmě záleží na 
objemu dat. Vzhledem k tomu, že všechny instalované instance Krameria 4.4 
budou při  přechodu na vyšší verzi nuceny znovu vygenerovat index, dá se 
předpokládat, že budou spouštět indexaci všech dokumentů vybraného typu 
současně. 
Asi by bylo vhodné zvážit, jak ten autoCommit nastavit. Já jsem si nastavil 
100 dokumentů nebo 60 sekund, ale moc netuším, jak by to mělo být 
optimálně.
<autoCommit>
<maxDocs>100</maxDocs>
<maxTime>60000<maxTime>
</autoCommig>

Druhá věc, která s tím nejspíš souvisí jsou dlouho trvající operace 
solr update. Používáme modul apache mod_proxy_ajp a zjistil jsem, že 
defaultní timeout je 5 minut, cože je pro solr update často málo. Nastavil 
jsem to na 15 minut, ale netuším, jestli to bude vždy stačit.
Jednalo se o tenhle dokument (zde v K4.4, indexace ale probíhala na 
neveřejné instanci K4.5 napojené na stejnou Fedoru):
http://kramerius.mzk.cz/search/handle/uuid:acb18a96-a082-4a43-8952-fc1a674384b0
(pokud se nezobrazují obrázky, je to asi nesouvisející problém s image 
serverem)

Po zapnutí autocommitu stejně poslední operace update trvala asi 9 minut. 
Proč to, když ostatní updaty trvají asi 2 ms? Nevolá se tam optimize? 
Pokud ano, tak to je zbytečné. Chápu, že se dá "synchronizace indexu" 
zapnout při indexaci jednoho dokumentu přes jeho menu. Při indexaci přes 
globální menu a "indexace procesů" by to ale mělo být vypnuto. Je to 
náročná operace, která trvá desítky minut a je zbytečné ji při 
hromadné indexaci opakovat pro každý dokument. Stejně tak pro "indexace 
vybraného modelu".
Ten dokument jsem odstranil z indexu a potom spustil novou indexaci (tentokrát 
již s timeout 10 minut). Viz přílohy solrUpdate.apache.log a stout.log

Poslední věc související s indexací je to, že se během indexace (ale i 
dotazů) objevuje v logu tomcatu "line 1:2: unexpected token: }". Nevím, o co 
jde, ale vypadá to, že se něco indexuje špatně. Viz příloha 
unexpected_token

Original issue reported on code.google.com by Martin.R...@gmail.com on 16 Mar 2012 at 1:15

Attachments:

• unexpected_token
• solrUpdate.apache.log
• stout.out

[GoogleCodeExporter]

Btw při "indexace modelu" se asi nejprve spustí OPTIMIZE (podle délky 
trvání první operace solr update). Což mimochodem způsobí to, že než to 
doběhne (9 minut při 400 000 zaindexovaných objektech), tak ve správci 
procesů to vypadá, že proces běží. Ale oba dva logy jsou prázdné. Pokud 
je nutné tam tu operaci nechat, tak by bylo vhodné něco zalogovat třeba 
"synchronizing index". Teď tam je tohle:
Mar 16, 2012 1:12:18 PM cz.incad.kramerius.utils.conf.KConfiguration 
findAllConfigurations
INFO: Replacing configuration file name from 'indexer-4.5.0-SNAPSHOT' to 
'indexer.properties'
Mar 16, 2012 1:12:18 PM cz.incad.kramerius.utils.conf.KConfiguration 
findAllConfigurations
INFO: Replacing configuration file name from 'common-4.5.0-SNAPSHOT' to 
'configuration.properties'
Mar 16, 2012 1:12:18 PM cz.incad.kramerius.utils.conf.KConfiguration 
findAllConfigurations
INFO: Replacing configuration file name from 'import-cmdtool-4.5.0-SNAPSHOT' to 
'migration.properties'
Mar 16, 2012 1:12:18 PM cz.incad.kramerius.indexer.Main main
INFO: process args: [krameriusModel, monograph, monograph]
Mar 16, 2012 1:12:18 PM cz.incad.kramerius.processes.impl.ProcessStarter 
updateName
INFO: requesting url 
:http://10.2.201.104/search//lr?action=updateName&uuid=f7e119bc-019c-46a7-bd2e-5
a60dc9af451&name=Indexace+dokumentu%3A+monograph
Mar 16, 2012 1:12:18 PM cz.incad.kramerius.indexer.Indexer <init>
INFO: Indexer initialized
Mar 16, 2012 1:12:18 PM cz.incad.kramerius.indexer.Indexer run
INFO: Current index time: 3/16/12 1:12 PM
Mar 16, 2012 1:12:18 PM cz.incad.kramerius.indexer.Indexer update
INFO: Update index...
Mar 16, 2012 1:12:18 PM cz.incad.kramerius.indexer.FedoraOperations updateIndex
INFO: updateIndex action=krameriusModel value=monograph
Mar 16, 2012 1:12:18 PM org.nsdl.mptstore.core.BasicTableManager mapTableExists
INFO: Found pre-existing map table
Mar 16, 2012 1:12:18 PM org.nsdl.mptstore.core.BasicTableManager loadMapTable
INFO: Loading map table
Mar 16, 2012 1:21:26 PM cz.incad.kramerius.indexer.SolrOperations krameriusModel
INFO: Indexing from kramerius model: monograph

Moc nechápu, jak to funguje. Samotný log se objevil asi v těch 13:21, 
ačkoliv proces začal v 13:12 a něco se už v 13:12 logovalo. Jakoby ten 
obsah logu čekal v nějakém bufferu. Pokud ano, tady by se hodil flush.

Original comment by Martin.R...@gmail.com on 16 Mar 2012 at 1:35

[GoogleCodeExporter]

Pak ještě k tomu optimize 
"An optimize is like a hard commit except that it forces all of the index 
segments to be merged into a single segment first. Depending on the use cases, 
this operation should be performed infrequently (like nightly), if at all, 
since it is very expensive and involves reading and re-writing the entire 
index. Segments are normally merged over time anyway (as determined by the 
merge policy), and optimize just forces these merges to occur immediately."
Indexace 777 stránkového dokumentu trvala 13 minut, z čehož optimize 
zabralo 9 minut. S větším indexem tenhle zbytečný overhead ještě 
poroste. Jaký je důvod k vynucení mergování po každé indexaci? A volá 
se to docela často.
http://code.google.com/codesearch#3mxf-JGxK3E/trunk/indexer/src/cz/incad/krameri
us/indexer/SolrOperations.java
a navíc s dost matoucím logem
logger.log(Level.FINE, "indexDoc=\n{0}", sb.toString());

Original comment by Martin.R...@gmail.com on 16 Mar 2012 at 2:12

[GoogleCodeExporter]

This issue was updated by revision r3491.

Original comment by pavel.st...@gmail.com on 20 Mar 2012 at 8:16

[GoogleCodeExporter]

This issue was updated by revision r3493.

Original comment by alberto....@gmail.com on 20 Mar 2012 at 9:13

[GoogleCodeExporter]

Volání příkazu optimize je teď možno při hromadné indexaci vypnout 
nastavením property indexer.runOptimize=false (defaultní hodnota je true) v 
souboru indexer.properties.  Jinak je optimalizace volána po každé 
jednotlivé indexaci, protože to je asi jediný způsob, jak zaručit, ež se 
efekt (re)indexace optavdu okamžitě projeví.

Original comment by vlah...@gmail.com on 20 Mar 2012 at 12:26

• Changed state: Fixed

[GoogleCodeExporter]

Myslím, že optimize nemá s projevením změn v indexu nic společného. Je 
to operace na vynucení mergování segmentů indexu. Což se provádí i tak a 
jak často se to dějě se dá ovlivnit parametrem mergefactor. Je určená pro 
optimalizaci vyhledávání v dále relativně neměnném indexu, což vůbec 
není náš případ.
http://wiki.apache.org/solr/SolrPerformanceFactors#Optimization_Considerations

Změny v indexu se projeví po commitu. Když jsem si povolil autocommit, tak 
se mi změny projevovaly okamžitě (resp. po indexaci 10 stránek) v průběhu 
indexace jedné monoografie.

Original comment by Martin.R...@gmail.com on 20 Mar 2012 at 12:59

[GoogleCodeExporter]

Ano, je to přesně tak, jak říká Martin Řehánek. Pro projevení změn v 
indexu slouží příkaz commit, použití optimize je nežádoucí a protahuje 
neúměrně dobu indexace.

Original comment by xrose...@gmail.com on 20 Mar 2012 at 1:14

[GoogleCodeExporter]

This issue was updated by revision r3497.

Original comment by alberto....@gmail.com on 20 Mar 2012 at 2:27

[GoogleCodeExporter]

Ano, máte samozřejmě pravdu, omlouvám se za zmatek. V r3497 je volání 
optimize nahrazeno voláním commit. Pomocí změny property 
indexer.isSoftCommit na true můžete indexaci ještě zrychlit, změnou 
defaultního hardCommit na softCommit. 

Original comment by vlah...@gmail.com on 20 Mar 2012 at 3:41

[GoogleCodeExporter]

Moc bych prosil, aby, když do .properties přidáte nějaké nové nastavení, 
jste toto přímo na místě náležitě okomentovali. Kdo toto issues nečte, 
nemá moc naději pochopit o co jde. Moc bych prosil, kdyby se to stalo věcí 
automatickou.

Original comment by Martin.B...@nkp.cz on 21 Mar 2012 at 10:14