Page 2 of 2

Re:OpenKM very slow

PostPosted:Thu Jan 29, 2009 11:28 am
by troyferraris
Yup, I have I am now sure this is the problem. Until the code can be corrected I suggest that either a user is created specifically for importing and once the import is complete not using that username again, or if admin was used, create a new administrative user and stop logging in as admin.

Re:OpenKM very slow

PostPosted:Thu Jan 29, 2009 11:37 am
by jllort
OK,

It\'s a bug on logic, we\'ll made on next release some changes to solve it.

Re:OpenKM very slow

PostPosted:Thu Jan 29, 2009 11:48 am
by alfito
Hum... My problem is that only user admin shows the administration tab. Users created with AdminRol do not show the administration tab... ¿is that correct?

Re:OpenKM very slow

PostPosted:Thu Jan 29, 2009 11:56 am
by jllort
yes it\'s correct,

meanwhile you could try other strategy to importing, divide your 5GB files with 200-300MB zip files and uploading with a new user \"import\", after doing it, you can delete this user, it\'ll be a more tedious importing way, but it\'ll solve this bug.

sorry for the inconvenience.

Re:OpenKM very slow

PostPosted:Thu Jan 29, 2009 2:00 pm
by troyferraris
I have unfortunately taken 2 days to import the filoes and cannot afford to do it again. Is there no way to re-allocate the docs to a new author via a script or change the login name of admin?

Re: OpenKM very slow

PostPosted:Mon May 03, 2010 12:16 pm
by glennm
Hi

I see it's been a while since anybody has posted regarding this issue but recently, I've had a problem with similar symptoms as experiences above:
- Imported large amounts of documents using the admin import utility (+/- 280 GB)
- experienced extremely slow folder list rendering in the UI as well as with webdav (generally dreadful openkm performance :-( )

All my jackrabbit persistence managers (workspace, version and journal) are using postgres with disk based filestores. I have just stumbled upon the solution for my situation - manually create indexes in the postgres databases on the node_id_lo & node_id_hi fields in the default_bundle, version_bundle and version_refs tables.
e.g.
Code: Select all
create index idx_node_id_hi_default on default_bundle(node_id_hi);
vacuum analyse default_bundle;
 
The the folder listings, document listings and property group updates are very rapid indeed.

Hope this helps someone.

Re: OpenKM very slow

PostPosted:Tue May 04, 2010 7:13 am
by jllort
Do you have blobs ( files data ) in your postgreSQL ?

Re: OpenKM very slow

PostPosted:Thu Oct 14, 2010 10:04 am
by glennm
yes - all files ingested into postgres as bytea.

Re: OpenKM very slow

PostPosted:Thu Oct 14, 2010 9:05 pm
by jllort
for repositories greater than 100GB it's really necessary make some tunning.

One of the known problem of the database created by repository ( this operation is made by jackrabbit by default ) is that not creates by default some indexes. You'll need dedicate some time creating them and problem will be solved. Jackrabbit not optimizes by default the database. For this size repositories is good idea trace the queries and analyze them, you'll need some time doing it, but sure to be a good investment.