Page 1 of 2
OpenKM very slow
PostPosted:Mon Jan 26, 2009 4:15 pm
by troyferraris
I successfully installed OpenKM.
I created 10 folders and imported folders containing files into each.
Each of the 10 folders now contain approximately 500 subfolders, each with additional folders and files.
Initially the software worked well but now it is very slow and the server is working overtime. The hard disk is working at almost 100% and the drive light is on perminently.
In the console I see that the server is very busy dong something:
INFO [LRUNodeIDCache ] num=100/10240 hits=200 miss=1309800
INFO [BundleCache ] num=1737 mem=8188K max=8192kavg=4754 hits=1071221 miss=250278
The above (with slightly different values) repeats over and over...
Anyone know what it is doing???
Re:OpenKM very slow
PostPosted:Mon Jan 26, 2009 7:09 pm
by jllort
First one recomendation, about 500 subfolders I don\'t understand if are on the same folder or not, but not for repository performance but for browser - openkm ui - performance I recomend less than 100 folders/ files per directory, because the explorer widget ( folders & documents view ) has slower rendering. I recomend more subfolders structure if you can.
Also it, I think your problem is not on UI, is on jboss service, we need more information:
1- How do you made importing ( by uploading zip or using administration utility ).
2- Which os are you using ?
3- Which application has the top on your server -> jboss/java ?
it could be indexing files, this needs some time to do, specially if you\'ve uploaded pdf. I has occured inmediatly or passed some time.
try-> loging out all users, and take a look a server.log -> what\'s doing ?
if continues, stop jboss service ( shutdown.sh or shutdown.bat ), rename server.log -> server.old ( I don\'t want to lose the log ), restart server, and start again.
Re:OpenKM very slow
PostPosted:Mon Jan 26, 2009 8:14 pm
by troyferraris
I am attaching an extract from the log file (the last hour). Also a screen capture of the console.
I imported using the folder import utility.
I am running on Windows XP
I have installed the stock standard GNU Version.
[file name=logextract.txt size=11045]
http://www.openkm.com/images/fbfiles/fi ... xtract.txt[/file]
Re:OpenKM very slow
PostPosted:Mon Jan 26, 2009 8:15 pm
by troyferraris
Sorry, here is the screen capture
Re:OpenKM very slow
PostPosted:Mon Jan 26, 2009 8:27 pm
by troyferraris
Re:OpenKM very slow
PostPosted:Mon Jan 26, 2009 8:43 pm
by troyferraris
Correction on my earlier statement, I have 10 folders on the root, each with approx 100 folders and each of these folders containing only a few files.
I am sure this cannot be the reason for poor performance and the server being so busy.
If I stop the server and re-boot. The server hard drive is inactive until I log in and then it starts with the same unknown task, which occupied 90% of the hard disk causing the opening of a folder to take 5 to 10 min.
Re:OpenKM very slow
PostPosted:Tue Jan 27, 2009 8:54 am
by pavila
You are right, there is no reason for poor performance. OpenKM performance depends on hardisk performance. Thus, a good SATA (or better) disk improves the system load. Default OpenKM repository configuration may lead on lots of files in the disk, and this is not a good scenario for Windows filesystem. I recommend you a Linux with ext3 filesystem for best performance. In this filesystem there is no file fragmentation and works fine with huge amount of files.
Anyway, the performance of OpenKM also depends in other factors: RAM, CPU, etc. I cannot guess what happens in your computer.
Also you can try to switch to a database-based repository. In this form there are several sample configurations.
Re:OpenKM very slow
PostPosted:Tue Jan 27, 2009 3:32 pm
by alfito
I think maybe it could be related. If not, I will open a new thread.
I am having such kind of performance issue, with heavy hd activity and 100% wait processor. I noticed that this begins as soon I login as admin. If a log on using another user, then, system works fine and there is no HD activity.
¿what do you think?
Re:OpenKM very slow
PostPosted:Tue Jan 27, 2009 9:43 pm
by alfito
Completing the information above.
After a while HD finally finished. ¿are statistics processes depending on admin login?
Re:OpenKM very slow
PostPosted:Wed Jan 28, 2009 8:49 am
by jllort
I\'ve been thinking other possibility. When you made import which user do you used \"admin\" ?
Can you see after login with \"admin\" at bottom right corner the repository size that uses admin ... it appears as others users or you don\'t show it an hd continues with 100% top ?
Which repository size have you imported ?
Re:OpenKM very slow
PostPosted:Wed Jan 28, 2009 10:36 am
by troyferraris
Thanks for this, I have imported using admin.
In an attempt to correct the problem, I have re-setup OpenKM and am busy re-importing again. I should have an answer to your question in a few hours.
Re:OpenKM very slow
PostPosted:Wed Jan 28, 2009 10:52 am
by jllort
I think it could be a problem with one operation I made by each user separatelly when logins, that calculates on real time the user documents size, if you\'ve uploaded so much GB of documents with admin user, could be so much deep query for calculating admin repository size each time admin user logins -> and it could be the reason for this top on your computer.
If it\'s the reason, we\'ll made some mistake on the way to calculate it, and I\'ll need to plan other strategy for next release less instrusive.
Confirm me ...
Re:OpenKM very slow
PostPosted:Wed Jan 28, 2009 11:58 am
by troyferraris
I think you are correcct. I will perform some tests and revert to you asap.
Re:OpenKM very slow
PostPosted:Thu Jan 29, 2009 10:16 am
by alfito
I can confirm that import in my case was also done with user admin. In my case it is about 5Gb repository with 4000 files.
It sounds that probably that process is causing the issue but: once it has finished, if I logout and login again it does not begin again. So, ¿is it run once a day or something like that?
Hope it helps.
Re:OpenKM very slow
PostPosted:Thu Jan 29, 2009 10:55 am
by jllort
No it runs every time. But probably from second xpath query to calculate user repository size is on cache an that could be the reason why is more fast.