OpenKM very slow

[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.

[jllort]

OK,

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

[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?

[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.

[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?

[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.

[jllort]

Do you have blobs ( files data ) in your postgreSQL ?

[glennm]

yes - all files ingested into postgres as bytea.

[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.