Apache OpenOffice (AOO) Bugzilla – Issue 47944
M 95 uses upto 97% cpu
Last modified: 2005-05-19 14:36:14 UTC
M95 with one blank writer doc open uses up to 71% of cpu as shown in the following top() output: top - 16:38:10 up 6 days, 2:35, 6 users, load average: 2.25, 1.95, 1.57 Tasks: 149 total, 4 running, 145 sleeping, 0 stopped, 0 zombie Cpu(s): 79.8% us, 1.7% sy, 0.0% ni, 18.5% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 775436k total, 711292k used, 64144k free, 63768k buffers Swap: 1028152k total, 235832k used, 792320k free, 266864k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7009 gerry 16 0 237m 108m 61m S 70.8 14.4 171:24.16 soffice.bin The above is typical of an idle session. Saving pegs the cpu at near 100% for long periods of time. Far longer than the time required to save a small document in m94. I see this as a regression that should be fixed immediately since it was fixed once before.
I am not able to reproduce this behaviour on Mandrake 10.1 kernel 2.6.8.1-03-NeTraverse-i686-UP-4GB soffice does not even appear on my "top" list on a visible shell window. Russell Butler
Sorry forgto to mention this is Fedora Core 3.
grsingleton, i can confirm that when stracing OOo _m90_ i see a lot of contiuos "gettimeofday" statements when doing just nothing inside the application. Performance on my system is still ok (800Mhz, 128MB RAM), but maybe the FC libraries choke on this "call-flooding". Also it seems possible to me that quering a NTP server under this condition may result in decreased performance..
You mean that because I sync the machines on my system using ntp OOo pegs the cpu? And yes I have straced and seen the gettimeofday calls. THis is not good news as I require ntp to keep my network in sync.
>>You mean that because I sync the machines on my system using ntp OOo pegs the >>cpu? yes, i was indicating this, but don't know at all if this is the real reason or just some side impact..
Do you need access? It can be arranged. I suggest VNC.
i will get myself a m95 first and have a look if i can reprocude on my system (my comments so far were about m90..)
The m95 in question is the one that one can download from the download tab at www.openoffice.org. I downloaded it on the day it was released so check that the date is on or near Apri 21.
Interesting experience. I have recently upgraded to m97 and see that it too uses excessive cpu. From the comment above about ntpd, I diabled this daemon then ran m97. The attached strace.m97 shows that soffice.bin is looping on gettimeofday(). I hope that this trace will enable someone to find out why this occurs as compared to m94 which idled at about 3%.
Created attachment 25673 [details] strace of m97 showing gettimeofday stuff
when running m97 on SuSE 9.3 i can confirm the 'getoftime'-flooding. i doesn't slow down my system, but makes me still wonder what this continuous calls might be good for. grsingleton, i will download an m94 next week and recheck. if this build does not gettimeofday-flood, there would have been a code chance from 94 to 95, if it shows the same behaviour as m97 we would have to investigate further concering your = FC 3 setup.
Created attachment 25698 [details] strace of idle m97 with no document.
The gettimeofday calls are used for OOo's internal timers to check whether a timer has run out and should be handled. They occur basically as often as either an X event occurs or a timer runs out; so that's quite normal. I fear gettimeofday has just proven again that looking at a strace output tells you next to nothing about OOo. The only way this would indicate something interesting would be if someone in OOo sets up a high frequency timer (say a few millicseconds) and then does something time consuming inside the handler. What would seem more promising would be breaking into OOo occasionally with gdb to see what actually is taking so much CPU. I'd do so myself, but an idle writer document takes 0.0% on my machine. Just my 2 cents
I have just tried m99. With the 2.0 User Guide loaded, OOom99 is consuming approximately 33% cpu. This is still high in my reckoning when the suite is idle. However, I have also noted that without this HUGE doc loaded, soffice.bin does not even display in top. So things are improving. pl, you asked about using GDB. Do you have a debug enabled OOo later than m95 that could be tested?
Hi grsingleton, to make task handling easier I set this issue duplicate to issue 47609 ... Both issue handle the same problem... *** This issue has been marked as a duplicate of 47609 ***
closing duplicate...